http://forums.leaflabs.com/topic.php?id=638 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:06:59 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=638#post-3668 Fri, 18 Feb 2011 17:02:31 +0000 x893 3668@http://forums.leaflabs.com/ <p>May be not for this thread - but i work now on .NET for STM32 (not CBT but start from RET) and see more PCB on AT91SAM7X and LPC - it's incredible. Last brilliant as i see - top layer = VCC (3.3V) :), i resolve problem with serial bootloader (only need one maple serial driver in windows - w/o separate DFU driver. Protocol stk500 and i use avrdude to program. Flash as disk still in dev stage but not think that it complete anytime (not need for mee in a real). As for me i use only one time upload software and later update code over GPRS or RF link. With a STM32 only one not a helpfull - no way to define MCU iinside code (may be it's a new feature from ST :)). </p> http://forums.leaflabs.com/topic.php?id=638#post-3662 Fri, 18 Feb 2011 16:03:53 +0000 gbulmer 3662@http://forums.leaflabs.com/ <p>x893 -<br /> <blockquote>... USB (and other) support can be place in bootloader section and not duplicate in user flash. </p></blockquote> <p>that was what I had hoped too. </p> <p>Use a 'trap' (like a real operating system) to 'call' the USB code, then the user application wouldn't need to know the address of the I/O entry points. </p> http://forums.leaflabs.com/topic.php?id=638#post-3648 Wed, 16 Feb 2011 21:18:39 +0000 x893 3648@http://forums.leaflabs.com/ <p>What a main idea to use separate hard coded bootloader and not use libmaple library ?<br /> With optimization bootloader size ~ 6-7K (not 15K w/o optimization). As benefit - USB (and other) support can be place in bootloader section and not duplicate in user flash. </p> http://forums.leaflabs.com/topic.php?id=638#post-3626 Sun, 13 Feb 2011 13:39:12 +0000 gbulmer 3626@http://forums.leaflabs.com/ <p>Poslathian</p> <blockquote><p>Regardless of the bootloader interface (USART,USB,Magick, whatever), Why did we choose to branch off of the STK500 command set for our experimental bootloader rather than branch of the command set provided by ST in this document ..? </p></blockquote> <p>Yes, that is <strong>exactly</strong> my question!</p> <p>Thank you for the thorough, clear answer.</p> <p>As you say, it might not be the answer I'd have wanted, but the rationale is clear.<br /> Key differences between your criteria and mine are:<br /> a) LeafLabs consideration for expansion, e.g. to support Oak,<br /> b) I'd like to make it easy to bring up 'raw' STM32F's using a common toolchain (so reflashing to 'raw' would only need a USB to USART cable and a jumper setting if the loader used the same protocol as the built-in USART loader)<br /> c) Your point about debugging is a very good one.<br /> I had resigned myself to using JTAG for debugging, and hadn't given alternatives much thought.</p> <p>Thank you for taking the time to explain, GB-)</p> <p>(Very interesting point about mbed, I had not realised it was bought in. That explains why it wasn't/isn't available) </p>