Yup, one needs to get acquainted with a new environment to feel self-confid=
ent
when using it. I guess I have to get more familiarity with the compiler, I =
think
the PIC32 hardware is great anyway, and well worth doing many compromises.


At 14.05 2011.11.06, you wrote:
>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 declarat=
ion
>> 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 stuf=
f
>> 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 bootloade=
r.
>
>In C it is the same.
>
>
>
>> When C gets in, things look much more complicated (at least right now th=
ey
>> do to me): initialization of bss and data sections, etc.. how do I handl=
e
>> them? Should the crt0.s code belong to my bootloadable application, or t=
o
>> 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 keepi=
ng
>> the C system is certainly useful) is e.g. that I want to devote a CPU re=
g
>> as SFR base, at least for my inline asm (or asm external sources) use. B=
ut
>> will the compiler overwrite that reg?
>
>Let the compiler worry about that. Having a base register always=20
>loaded is not that important. You could load that base register at the=20
>start of each assembly section, it's just one more instruction to be execu=
ted.
>
>
>
>> 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 an=
d
>> 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

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.