http://forums.leaflabs.com/topic.php?id=941 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:06:58 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=941#post-6179 Thu, 01 Sep 2011 17:50:41 +0000 ianmga 6179@http://forums.leaflabs.com/ <p>Ohhhhhhh. Makes a lot of sense. Thx Uhrheber </p> http://forums.leaflabs.com/topic.php?id=941#post-5840 Tue, 02 Aug 2011 12:34:58 +0000 poslathian 5840@http://forums.leaflabs.com/ <p>This was certainly considered in the beginning. However, a mass storage based approach does not solve the core problem - switching between two different USB device types, CDC/ACM (serial) and DFU (or mass storage as the case may be). We couldnt do compound USB devices because of windows/mac incompatibility issues. </p> <p>I think the best option for the future is to have a second chip that presents a single serial port interface that is always on, ala arduino uno. and bootload over serial with the second chip. </p> http://forums.leaflabs.com/topic.php?id=941#post-5838 Tue, 02 Aug 2011 09:53:57 +0000 Uhrheber 5838@http://forums.leaflabs.com/ <p>AFAIK, these mass storage device bootloaders work a little bit different.<br /> They just pretend to be a disk drive, but in fact they are not.<br /> They send a fake FAT back to the OS that never changes.<br /> You can copy a hex file to the drive, but it is actually never written<br /> to a file system, instead it is parsed and the parsed date is<br /> written to flash.<br /> When you read the drive, it shows only a text file with zero bytes length.<br /> The name of the file show the status (READY.TXT/OK.TXT/ERROR.TXT)</p> <p>One example of an implementation is here:<br /> <a href="http://www.freescale.com/files/microcontrollers/doc/app_note/AN3927.pdf" rel="nofollow">http://www.freescale.com/files/microcontrollers/doc/app_note/AN3927.pdf</a> </p> http://forums.leaflabs.com/topic.php?id=941#post-5833 Mon, 01 Aug 2011 17:07:03 +0000 ianmga 5833@http://forums.leaflabs.com/ <p>Haaahaaa "after some beer - this forum looks funny". Hilarious.</p> <p>I'm interested in this idea but I have some doubts. How would you find the fw.bin in flash? How do you ensure it's in the memory area that you want? (say, for the interrupt table). How do you ensure that it's a continuous area of memory? (if you're using a regular filesystem on flash there's no guarantee)</p> <p> Ian </p> http://forums.leaflabs.com/topic.php?id=941#post-5803 Fri, 29 Jul 2011 18:18:26 +0000 x893 5803@http://forums.leaflabs.com/ <p>Some weeks i think about why need special bootloader ?Why not use NXp method as flash = usb disk. Some man try make it but no RTU project for stm32 - only for nxp chip. after 2 weeks i make simplest way to map internal flash to ext disk. copy file with a name fw.bin - it's flash to flash. file with name ramfw.bin to device - copy soft to ran and execute. it's the same as dfu - buy dfu need drivers/ this schema not need any.</p> <p>Question to map guru - why you not realize this simplest way (for customer) and use unworking code for bootloader ?</p> <p>Second quenstion more difficult<br /> in all your code you use gpio, pin but in real (if you see disasm) only 2-5 bits used. for code economy (if any knowns it) better use all bits for reduce code size. i say about that enough one u32 for exactly define port and pin.</p> <p>May be my q stupid - but with this suggestions i reduce code size from 18KB to 7KB.</p> <p>Of course - i undersand than 99% super developers (which no more than only blink a led) say me that this no need.</p> <p>After some beer - this forum looks funny</p> <p>And my own opinion - 99% prof developers not understand how it works. only beginners read DS and not ask a stupid Q/ i i prefer beginners (who read DS) and not a profi (who ask Q before read).</p> <p>This is my opinion and not as not related to Leaflabs </p>