bdwyer

Member Since: October 5, 2009

Country: United States

Profile

Bio

Electrical Engineer/Enthusiast

Programming Languages

C++, VHDL

Universities

CMU, Oakland University

Expertise

Microcontrollers / Sensors

Websites

http://ohmwardbond.blogspot.com

Publications

http://blog.makezine.com/archive/2010/07/2d_light_follower_uses_wiimote_infr.html

  • Was interested until I saw the price :0(

  • You could also run android on a virtual machine on any computer you own with wifi and install the app, if the app really is the only or best way to configure the device.

  • This idea should win :0)

    Aside from dogs delivering pizzas, I’d like to see how this could benefit those who use seeing eye dogs…

  • Of course this is quicker, thus the article. However, the point to be made is that the actual programmed flash is not being verified at any level of the bootloader. Any failed-write (which is absolutely possible) will go unnoticed, because it is not being “Verified” by the verification option. Don’t get me wrong, they put that check-box in there for a reason right? (don’t want to verify your upload? Live on the edge and uncheck the box :0p

    I think the bigger picture here is what kind of embedded programmers to promote; those who get in the habit of cutting corners to save literally only seconds per upload, or those who can understand and appreciate the pitfalls of memory failures and robust verification processes to combat them.

  • After checking ‘STK500boot.c’ - There are no CRCs performed…I did notice an xor checksum routine which the bootloader does perform on received packets. Keep in mind, XOR checksums are not very robust and they are NOT CRCs (CRCs are much more robust, but they are not perfect).

    The Optiboot bootloader doesn’t seem to perform any checksums/crcs at all…

    Maybe not verifying correct flash upload is not such a great idea (on paper)?

  • I think this is a great post (comments included), not in the fact that people will begin to bypass the flash verification; but this should motivate those involved into learning how the bootloader works. By the way, you should be able to browse the bootloader source code to figure it out.

    Quoting the article: “It’s still unlikely an error will slip through the CRCs…”

    Try to figure out if the bootloader actually performs Cyclic Redundancy Checks (CRCs) on the written flash vs. data to be written to flash. I don’t know, but I don’t think it would perform it on the written flash…but let’s just find out for ourselves?

  • Sparkfun internship program: “ABCs and PCBs”

  • Another product sparkfun could sell: Panavise (not Jr.). It’s nice to have a vise with enough weight that it does not need to suction-cup to a desk (especially for me when I have to solder around things it cannot suction too).

    http://www.alliedelec.com/search/productdetail.aspx?SKU=70200031

  • I’d like to see more with Xilinx Zynq (FPGA + dual-core ARM on one chip). Search: Zybo

  • Haa…Too bad it’s NOT an ARM…cus that was clever