Microchip AVR-IoT WG Dev Board - Review

Table of contents

RoadTest: Microchip AVR-IoT WG Dev Board

Author: iexpress

Creation date: 4 Jan 2019

Evaluation Type: Workshop Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?:

What were the biggest problems encountered?: My computer died right what I inserted the device into my computer. I lost 4 versions of Windows and over 500 GB of data.

Detailed Review:

Perhaps a device like this had been released way too early without undergoing sufficient testing to assure future users their success with the operation of the device.

Sadly, I felt the device did not perform to the standard operation outlined in it's specifications which resulted in the device functioning somewhat differently other than what was specified.

While I intended to use MPLAB X along with Atmel Studio 7 to create new programs for the device, my computer died right when I plugged the device into my USB port.

With a dead computer, I lost over 500 GB in data along with 4 versions of Windows which left me struggling for an additional four hours trying to find a solution.

I ended up installing Debian Stretch with Raspberry Pi Desktop for x86 from a CD onto a 64 GB Sandisk Cruzer Fit USB Flash Drive that is working for the minute.

After careful review of the filesystem of the Curiosity drive in Linux, it was discovered that the mass storage device had a hidden Autorun file on it that ran another program that killed my computer.

It should also be noted that the device arrived with the packaging pre-opened. Someone had access to the device before it was shipped.

With that said, I would appreciate it if someone could send me another 2.5" internal SATA hard drive to replace the one that was fried by the Curiosity drive's software.

In Debian 9, the device showed up as /dev/sdb1 and was mounted successfully to folder /media/pi/CURIOSITY and showed the drive was 1.1 MB n size when I ran "df -h" in the Terminal of Debian 9. I would have at least given the Mass Storage device a 64 Mbit Flash Chip which might be possible when using the SPI Port of the device if one can reprogram the device to use a filesystem on a SPI Flash Chip over the SPI bus.

Exploring the drive further showed that it's proper contents were present along with HTML files that redirect the user to another page across the internet to see results of data being sent to a Google Cloud Sandbox account from the AVR-IoT WG Board.

Initially, the device gave continuous errors while enumerating it's red LED to indicate there was an error.

After establishing an internet connection through Debian 9, I opened the Click_Me.html file from the Curiosity drive that redirected me to another webpage across the internet to fill out a form which asked for the SSID, Password, and the encryption type for my internet modem.

It then asked me to download the form data into a configuration file that was dragged and dropped into the Curiosity drive. Sadly, it took it three times of doing that for it to register or acknowledge the file was added as it kept disappearing from the curiosity drive each time I tried to put the configuration file in the Curiosity drive.

After successfully connecting to the webpage again with the Click_Me.html file, the unit showed no errors and a blue LED came on to show WiFi data was being sent to the Google Cloud without any errors.

I was ready to create a new project at that time, but when I clicked on the Build it Now button in the Build Your Sensor Node section that was listed in the What's Next portion of the webpage in order to start a new project, I was redirected to another webpage that only offered additional downloads that were needed in order to work with the hardware. That, and the downloads were only available for Windows environments. With excitement, I was hoping to see that the ability to create projects for the device online would have been possible. I can see how a web program can let users select which sensor modules they are adding to the board from a web page, but sadly this option to program the device wirelessly this way is just not possible with the current implementation though correcting it to allow this method of programming the device wirelessly would be very easy.

An additional search using Apt-Get in Linux for MPLAB X and Atmel Studio 7 returned 0 results which left me unable to program the device as I was intending to with those two IDE's.

I did find an Arduino IDE in the repository, so if the Arduino team made their software available for Linux, it is only logical that Microchip and Atmel would follow suit doing the same.

There is a lack in the ability to program the device natively which I felt is something that should have been considered when designing the software for the Curiosity drive.

More so, I highly believe choosing the Mass Storage Class for interacting with the AVR-IoT WG Board was a bad idea and think they should have used a better alternative such as USB CDC for serial COM Port communications while creating a PC program that could control all aspects of the USB device by sending chars from the PC and using select case statements in the device firmware to select appropriate functions based on which incoming chars matched any chars in a predefined list of chars of the select case statement.

I found it trivial and pointless to redirect users to another webpage across the internet from a local HTML file. HTML files should keep the users local for their safety and retrieve data from across the internet automatically to display any results inside an iframe instead.

Another alternative could be using a PC program made with Visual Basic.net or ASP.net to send and receive data to and from the device over the internet. I would highly recommend using the USB CDC method to control all aspects of the device's hardware. At least with a PC program, users could then select which sensors are attached to the board, and then let the board do the rest of the work of providing data back to the user inside the PC program. Perhaps they could even let a user specify the frequency of the data transmission from every minute, to every second to continuous operation of the device. Controlling the device with a PC program using USB CDC is key in getting the most out of any attached hardware in my opinion and is only triggered one per button press before closing it's COM Port communication channel. This would also provide security to the end user.

At the very least, any local HTML page for the Curiosity drive should give the option to set variables for settings of the device and submit that variable data to a server which could then send results back to the end users in the very same local HTML webpage.

Additionally, I did not see a way to view individual variables so customizing usage of any incoming data is not possible. There is no way to use variable data other than viewing it in a webpage they send you to. The entire operation of the device is controlled and heavily supervised, but the concept of sending data to the Google Cloud is interesting, but I feel they should aim their focus on making byte streams available in real time. Reading variable data bytes from any device in the sandbox account as needed from the Google Cloud instead of being continuously transmitted 24/7 would make a better alternative. It would also be more secure as the device would not be on continuously and would then prolong the device's life expectancy..

In conclusion, trying to get the device up and running might take an average user around 30 minutes. Personally, I wouldn't really recommend the use of this device to others. Overall, I highly felt that sending bytes to the cloud from a device only for the same data to be returned to the very same device is pointless when users can't do anything with the incoming data in variables outside of the demo program.

Thank you for reading