Microchip AVR-IoT WG Dev Board - Review

Table of contents

RoadTest: Microchip AVR-IoT WG Dev Board

Author: iexpress

Creation date:

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

Anonymous
Parents
  • ***!  that sounds horrible, thank you for warning.

    Most of all, I feel sorry for the loss of your computer.

    Forgive my inquisitivity, but as I understood the issue, the AVR-IoT performs dangerous modifications on the disk filesystem.

    I wonder if it was  just bad luck with your board

    or the problem is general and all AVR-IoT users are in danger (using Windows systems)

    As I remember from "quick start" instruction from Microchip,

    the launch of the board should be extremely quick and easy:

    • 1Connect the AVR-IoT board to your laptop using a standard micro-USB cable
    • 2Open the “CURIOSITY” drive
    • 3Click on “CLICK-ME.HTM”

    There is no remarks concerning OS

     

    I wish you success in happy solving the issue.
    Maybe you also recover data from the disk.

    Marek

  • Hi Marek,

     

    On the AVR-IoT-WG Development Board User Guide, it describes how to connect the board to the PC (below). As you can see,  indeed there is no difference in the procedure, regardless which OS you are using.

     

    And it looks like the picture on the page is taken on a Windows system...

     

    Fabio

     

     

    image

  • Fabio, your document shows that there is no autorun command in that file system.

    I have doubts that there is some autorun related issue that happened to Jason. A hardware defect maybe?

  • you can see it here:

    DS50002805A-page 10  (http://ww1.microchip.com/downloads/en/DeviceDoc/AVR-IoT0WG-Technical-Summary-50002805A.pdf )

    4.1.2.1 Mass Storage Device

     

    By default the CURIOSITY drive contains several read-only files for generating icons as well as reporting

    status and linking to further information:

    • AUTORUN.ICO - Icon file for the Microchip logo.

    • AUTORUN.INF - System file required for Windows Explorer to show the icon file.

    • CLICK-ME.HTM - Redirect to the AVR-IoT WG web demo application.

    • KIT-INFO.HTM - Redirect to the development board web site.

    • KIT-INFO.TXT - Text file containing details about the kit firmware, name, serial number, and device.

    • PUBKEY.TXT - Text file containing the public key for data encryption.

    • STATUS.TXT - Text file containing the programming status of the board.

  • Reprogramming the device with MPLAB X or Atmel Studio 7 though requires a Windows environment. I only have Linux after the USB device fried my computer right after I plugged it into my computer.

  • Hi Jason,

     

    I have used MPLAB X on Debian, and works OK, so while waiting for the disk, maybe you could give the Linux version a go.

     

    Fabio

  • I haven't had any luck finding it for this Linux version yet. It keeps saying no results were found, even through the package manager.

    image

  • Hi Jason,

     

    I believe the Linux version  is available only via Microchip website, but I'm not sure it will work on Raspberry PI Desktop, as I only tried on a amd64 Debian 9. If it is for x86 it might still work, the only way to find out is to download and try installing. I'll be curious to know if it does work on a x86 Raspberry PI Desktop with Debian 9 though.

     

    Fabio

  • I'll definitely do a search for it. Looking at Atmel Start, it doesn't appear to let users enter in their hardware components they want to attach to the board. It only offers software drivers of data buses, like SPI or UART.

Comment
  • I'll definitely do a search for it. Looking at Atmel Start, it doesn't appear to let users enter in their hardware components they want to attach to the board. It only offers software drivers of data buses, like SPI or UART.

Children
No Data