Hi, I don't really get it, why You trying (so hard) use a bootloader which won't fit in boot block, so what? Bootloader can be with any size, just move user code to location after bootloader (to first free block of flash erase boundary). If size of user code+bootloader won't fit into device - choose another pic with bigger flash or choose a compiler which produce smaller code - what is the problem? Currently I'm using own usbbootloader with xtea encrytption, which takes about 10kB in size and I'm pretty happy with it. Writing such bootloader is trivial job and it takes a couple of minutes. I think You wasted more time trying to find solution how to fit it than trying to write a new, custom bootloader, which meets all Your requirements.
Other question is about extended instruction set and which compiller is better. As someone mention before even Microchip abandoned support of extended instruction set, so it's not worth to use it. XC8 is a huge, bloated compiler which takes ages to compile even a small code. If Your project has many files You working on - compiling time matter. As a Linux user SDCC was my first compiler for pics, but now I preffer C18, it produce 50% smaller code than sdcc and it works under wine. If You need join banks for big tables or bigger stack sdcc don't supprt this (as far I know) but C18 does. But I still miss sdcc's compiling time, C18 is a bit slower (under wine) but not so much. ml 2015-01-29 21:09 GMT+01:00, Kustaa Nyholm <kustaa.nyh...@planmeca.com>: > Hi, > > I'm at cross roads, should I go on with SDCC (which I'm happy > with and familiar) or move to MPLAB X compilers... > > The dilemma: > > I'm planning to use the Diolan bootloader which uses extended > instructions set. That bootloader is very nice as it is in > asm and fits (just!) into the boot block and offers encryption > for the firmware to be bootloaded. > > Problem is that code compiled with SDCC does not work with > the extended instruction set enabled and as this [extended > instruction set mode] cannot be changed at run time this > combination [SDCC and diolan] does not work. > > I converted the diolan bootloader to 'legacy' mode, but > of course it did not fit. So I've optimised it and now it > fits and runs, but the encryption does not work properly, > obviously some of optimisations or conversion broke something. > > I'm working on fixing that but the big question is, if I > would be better of with MPLABX compilers in the long run... > > In theory the MPLABX compiler with the extended instruction > set enabled should produce better and faster code so in > that respect the answer is obvious ... why go through all > the trouble making the diolan work with SDCC... OTH > emigrating to a new compiler is bound incur some pain and > a learning curve. Also my own USB stack optimised for SDCC > is half size of the (Free) USB M-stack (not to mention > Microchip's own stack) ... at least when compiled with > the free MLABX C-compiler. > > As this is a free as beer project I don't feel like paying > for the compiler ... though I could afford it. > > So any on going work on SDCC to support extended instruction > set? > > I could live with code generation that does not take advantage > of the extended instruction set as long as the generated code > would be compatible with it. > > This document (at the end) mentions that it is possible to > write code like that with some 'hacks' > > diolan plus readme.zip > <http://dangerousprototypes.com/forum/download/file.php?id=5934&sid=783f188 > 28453f727272fbda73537545d> > > I'm not familiar with SDCC code generation or PIC assembly > so I can't evaluate if it would realistic to do something like > that. > > cheers Kusti > > > > > > This e-mail may contain confidential or privileged information. If you are > not the intended recipient (or have received this e-mail in error) please > notify the sender immediately and destroy this e-mail. Any unauthorized > copying, disclosure or distribution of the material in this e-mail is > strictly forbidden. We will not be liable for direct, indirect, special or > consequential damages arising from alteration of the contents of this > message by a third party or as a result of any virus being passed on or as > of transmission of this e-mail in general. > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
