Em 6/11/2011 07:47, Electron escreveu: > At 00.19 2011.11.06, you wrote: >> I am pretty new to C and to the PIC32, but just a suggestion that may >> nudge you in the right direction: >> >> Will the the compiler allow you to create a function to a pointer to >> an absolute address? >> I have used this in the past in GCC to reset a MCU, but haven't tried >> it on a PIC32: >> void(* resetFunc) (void) =3D 0; > well, it should, and if it doesn't, then you can put *resetFunc declarati= on > into a union with something else (e.g. a int), and set to 0 the other. > > To Harold: do you know this doc by Microchip? It might be useful to you: > > Use PIC32 Boot Flash to Expand Program Memory > > document # 93015A (no B, C.. version yet) > > link: > http://ww1.microchip.com/downloads/en/DeviceDoc/93015A.pdf > > I too will begin next week to work on a bootloader for the PIC32. But > there are still obscure stuff about it in my mind, as crt0.s copies stuff > around, but also: do any of the PIC32 library functions make use of the > heap? etc.. Certainly, but not all. You can choose only the ones that don't use it. It seems that you are worrying too much about this. > I'd like to be as low level as possible even in C, without an > OS (or pseudo OS) on top of me. For example if I get my bootloader into > the bootloader flash memory space, can I use the whole program space for > my own (bootloadable) programs? Yes. > And how will the initialization of vars, > etc.. will be done then? They are embedded in the HEX file together with the rest of the application code and will be boot-loaded without the boot-loader even knowing it. > When doing it in asm, it's easy. You just dump to a file the HEX of the > program you created, and then send it back to the chip via the bootloader= .. In C it is the same. > When C gets in, things look much more complicated (at least right now the= y > do to me): initialization of bss and data sections, etc.. how do I handle > them? Should the crt0.s code belong to my bootloadable application, or to > the bootloader? Each one must have its own instance of the crt0. Remember, when the application starts, the boot-loader is not running anymore, and when the boot-loader is called it is the only code running, the application is aborted and can only be restarted by the initialization code. > Clearly, there are parts of crt0.s that seem to (logically > at least) belong to the app and others to a initialization phase that is > relative to the bootloader only. The application and the boot-loader must be completely independent of each other. After a reset, usually the boot-loader starts running, is initialized and checks if there's a valid application and if it is not necessary to load a new one. If there's a valid application and it is not necessary to load a new one, then the boot-loader jumps to the start of the application. The application has its own initialization code and runs as if the processor had just reset. > Is there any "minimalistic" PIC32 bootloader source I can take a look at? > > Another thing that annoys me of the C stuff on the PIC32 (although keepin= g > the C system is certainly useful) is e.g. that I want to devote a CPU reg > as SFR base, at least for my inline asm (or asm external sources) use. Bu= t > will the compiler overwrite that reg? Let the compiler worry about that. Having a base register always loaded is = not that important. You could load that base register at the start of each = assembly section, it's just one more instruction to be executed. > C and asm integration doesn't look too good. If I had to choose, I'd go > for asm, but C is useful as well. I may even use asm as main language and > call C functions, The opposite is more feasible. The C language has more strict calling conventions than assembly and you would need to keep a C-compatible environment all the time. And there=B4s a lot of things that must be kept in such environment. > yeah, but would it work if some C library function call > malloc, for example? A big crash. And a lot of other library functions would do the same. > Confused? A bit for sure, yeah, I guess I have to spend a lot of time on > the disassembly window. > > But if anyone knows a "minimalistic" PIC32 bootloader source I can peek > at, I'd appreciate to know. Microchip probably has something worth looking at. But even if not, you could adapt one of the available for the PIC24/dsPICs. Isaac --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .