http://forums.leaflabs.com/topic.php?id=59 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:20:32 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=59#post-360 Fri, 25 Jun 2010 19:18:28 +0000 poslathian 360@http://forums.leaflabs.com/ <p>Currently, user code and bootloader code are completely isolated. That is, USB is torn down in the bootloader before jumping to user code. Its setup again in your sketches via SerialUSB, but you can change this by adjusting the init function to not include calls to setupUSB. The virtual com used in user code (SerialUSB) does not use FTDI, rather windows built in usbser.sys, and default system drivers in linux and mac. There is that maple_serial.inf that needs to be installed, but all that does is point windows to the existing usbser. </p> http://forums.leaflabs.com/topic.php?id=59#post-358 Fri, 25 Jun 2010 18:36:46 +0000 gbulmer 358@http://forums.leaflabs.com/ <p>I don't use Windows, but I've had folks with Windows laptops at my Arduino workshops trying to install the FTDI drivers, and it has taken 20+ minutes, and some have given up. It appears that they have some sort of conflict with something relatively common, i.e. about 1 in 15-20 have a problem, and have to run install a few times, about 1 in 30+ have something more serious.</p> <p>I had previously believed the FTDI drivers were 'rock solid', but a few workshops where we suffered those bad experiences has caused me to look for 'driverless' USB, i.e. use the USB drivers already installed. Obviously a user-level program can be used for upload, but I'd like a two way serial connection (or something a terminal emulator thinks is a serial connection) so that I can talk straight to the board, e.g. for python-on-a-chip.</p> <p>As you say, there's also a need for folks to implement their own USB devices too. Having a version of a bootloader which doesn't start USB might be handy for those folks. They could link to that, and boot into it. Maybe booting into SRAM might help them do initial development too. </p> http://forums.leaflabs.com/topic.php?id=59#post-275 Mon, 21 Jun 2010 17:34:39 +0000 bnewbold 275@http://forums.leaflabs.com/ <p>Hey gbulmer! Great questions that we don't have great answers for...</p> <p>First off, I can't remember if we updated the bootloader docs with our final-final Maple rev3 restart procedure: we now look for a magic ASCII string ("1EAF") coming in a single USB packet straight after the falling edge of DTR. </p> <p>What a horrible ugly hack! </p> <p>Our original plan seemed the most elegant to me: a CDC device for doing serial comms and a DFU device for flashing new firmware, both of which are the appropriate generic USB class device types, and thus should have been supported on any modern operating system. The DFU code would sit in the background; when upload activity started on that device the background code would stop CDC, clear the usercode stack, and enter the bootloader routines. However, turns out neither Mac OSX nor Windows seem to implement the USB spec completely, especially these class devices. Ironically (given the history of device drivers on open source operating systems) this scheme, and all the others we tried, worked just fine on Linux. Sigh. If I remember correctly the particular problem was that windows doesn't support multi-device USB configurations without some special driver hackery. The most recent magic string hackery was required because Mac OSX doesn't handle control over the RTS/DTR lines correctly from userspace.</p> <p>To get back to your question, DFU was a much simpler protocol to implement, and thus the bootloader code size can in theory be much smaller. I think it can also upload code much faster, and in general is just "the right tool for the job". We also (still) would like to have the option not to compile in USB support in usercode because it takes a lot of memory and the frequent interrupts disrupt timing dependent code; when this is done users have to manually enter perpetual bootloader mode to upload new code. </p> <p>To summarize, you can certainly could implement a "bootloader" like the one you describe above: it would have to be compiled in to every user program (like ours is now, unfortunately, but just the auto-reset part), and the out of band signals would be very hard to get right on all 3 platforms, and users would not have the option of implementing USB device types other than CDC (eg HID or mass storage). But in the end maybe those restrictions are better than the dfu/cdc headache.</p> <p>There are other solutions too: I love the simplicity of the mbed's mass storage upload, and the HalfKay protocol implemented by Teensy (which uses generic HID) definitely makes me curious though it's implementation is somewhat controversial (see <a href="http://www.pjrc.com/teensy/halfkay_protocol.html" rel="nofollow">http://www.pjrc.com/teensy/halfkay_protocol.html</a> and <a href="http://fourwalledcubicle.com/blog/archives/617" rel="nofollow">http://fourwalledcubicle.com/blog/archives/617</a> ). Emulating FTDI is also something I think about a lot: there are popular, stable, well supported drivers that can be installed (or are bundled) for every platform.</p> <p>[sorry about the wandering structure of this post, i'm kind of sleep deprived ;) ] </p> http://forums.leaflabs.com/topic.php?id=59#post-266 Fri, 18 Jun 2010 18:20:51 +0000 gbulmer 266@http://forums.leaflabs.com/ <p>First let me say, I am thrilled with the progress you folks have made with the Maple board, but most especially the IDE and libraries.</p> <p>I read the documentation about the bootloader, and I have a few questions. Again, let me complement you here too. You tried to do the same plan as I had (DFU+CDC) in version 1, and I think you've overcome problems that I would have struggled with.</p> <p>After all of the problems, and the difficulty of getting DFU and CDC to co-exist, would you please explain why the bootloader implements both a USB DFU device and a CDC device? I am probably missing something, but it was my fall-back plan, so I'd like to understand why you didn't go that way.</p> <p>My thought was for a bootloader which only implements a USB serial interface (e.g. CDC):<br /> 1. After reset, enter bootloader as an Arduino does, waiting for some serial bytes, and if nothing happens jump into the user program.<br /> 2. Once in the user program, the CDC device would underpin the Serial.xxx libraries.<br /> 3. The board could be 'auto-reset', like an Arduino, using a combination of DTS/RTS/... out-of-band signalling, so no need for any in-band bytes to tell the USB what is happening.<br /> 4. AFAIK the existing stm32loader.py would work over a serial port. </p> <p>So, I apologise if this is a dumb question, but why did you not do everything, upload and Serial.xxx comms, over a USB serial, and avoid the DFU device completely?</p> <p>TIA<br /> GB-) </p>