Searching \ for '[PIC] Is this correct code? - and absolute code' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Is this correct code? - and absolute code'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Is this correct code? - and absolute code'
2011\11\05@183637 by Harold Hallikainen

face
flavicon
face
I'm mostly doing PIC32 stuff now with C32, the linker, etc. I do a little
assembly for it, but very little. I find linker scripts very cryptic. It'd
sure be nice if they were commented a bit more. It'd also be nice to
easily define the address where a function is to be placed. The new
version of C32 has an attribute that allows this, but it appears there are
various issues with this new version (especially in printf).

In my bootloader, I'd like to have a jump table at a specific address that
does not move as I make code changes. I see how I could do it in assembly
(including use of org, which, it appears, is based on the section start,
not the absolute address), but it'd be nice to be able to do it in C.
Something like:

org SomeAbsoluteVirtualAddress
function1: goto LocalFunction1;
Function2: goto LocalFunction2;
Function3: goto LocalFunction3;

The "LocalFunctions" would still do all the stack operations (getting
parameters, allocating local variables, cleaning up the stack, etc.). The
jump table would just provide a fixed address to access the function.

I did this on the PIC24, building my own interrupt jump table since the
PIC24 places the interrupt vector table in the boot section. I just had
all those original interrupt vectors point into my jump table, which then
pointed to the actual interrupt function. I THINK I did it in C (I'll have
to look at the code), but MAY have done it in assembly.

I tried the above stuff (
function1: goto LocalFunction1;
Function2: goto LocalFunction2;
Function3: goto LocalFunction3;
), but the C32 compiler did not like it. I don't think it liked the labels
(expecting a return value type instead). For now, I've put functions that
call local functions at the top of the section, but that uses more stack
space and is pretty inefficient.

So... how do I do a jump table in C32? Or do I go back to assembly?

THANKS!

Harold


-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\11\05@190625 by Isaac Marino Bavaresco

flavicon
face
Em 5/11/2011 20:36, Harold Hallikainen escreveu:
{Quote hidden}

First, you have to deal with linker-scripts to be able to put your jump
table at the fixed and predefined position, creating a named section
with 'protected' attribute.
Then you have to use function-pointers, which is the C way of calling
functions by pointer.

Example:
int (*fp1)( int a, int b, int c );    // fp1 is a function-pointer
variable that may point to a function returning int and taking 3 ints as
arguments.
void (*fp2)( void );    // fp2 is a function-pointer that points to a
function returning void and taking no arguments.

fp1 = LocalFunction1;    // Please not the lack of parenthesis and
arguments. You are taking the address of the function.
fp2 = LocalFunction2;

x = fp1( 1, 2, 3 );
fp2();

fp1 = LocalFunction3;
y = fp1( 4, 5, 6 );


ALTERNATIVE ( build-time table creation):


typedef int (*functionpointer_t)( int a, int b, int c );

functionpointer_t    FunctionTable[NUMBER_OF_ENTRIES] = { lf1, lf2, lf3,
.... };

x = FunctionTable[i]( a, b, c );    // Call function number 'i' with
arguments 'a', 'b', 'c'.


Best regards,

Isaac

2011\11\05@191940 by Chris Roper

picon face
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) = 0;

Cheers
Chri

2011\11\05@192246 by Chris Roper

picon face
Isaac posted whilst I was typing, but it looks like I was on the right track :

2011\11\05@193642 by Harold Hallikainen

face
flavicon
face
Thanks for the pointers! It really seems like this is easier to do in
assembly. I could just define a jump table section in the boot flash in
the linker script at some fixed location, then fill that with my jumps to
various functions. As I mentioned, the new compiler allows an attribute
that sets the absolute function address in the virtual memory map. So,
that's another possibility without having to deal with arrays of function
pointers.

I really got used to jump tables back in 1980 or so when I licensed a
Basic interpreter from Microsoft. They added several keywords for me and
pointed them to a jump table in my section of the eprom. My code went out
from there. This was all MC6800 assembly.

Again, thanks for the pointers!

Harold


-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\11\06@050100 by Electron

flavicon
face
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) = 0;

well, it should, and if it doesn't, then you can put *resetFunc declaration
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.. 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? And how will the initialization of vars,
etc.. will be done then?

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.

When C gets in, things look much more complicated (at least right now they
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? 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.

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 keeping
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. But
will the compiler overwrite that reg?

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, yeah, but would it work if some C library function call
malloc, for example?

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.

Greets,
MarI/O

2011\11\06@080556 by Isaac Marino Bavaresco

flavicon
face
Em 6/11/2011 07:47, Electron escreveu:
{Quote hidden}

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 they
> 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 keeping
> 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. But
> 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´s 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

2011\11\06@102235 by Electron

flavicon
face

Yup, one needs to get acquainted with a new environment to feel self-confident
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:
{Quote hidden}

>

2011\11\06@132401 by Harold Hallikainen

face
flavicon
face
..
>>
>> 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:
>> ww1.microchip.com/downloads/en/DeviceDoc/93015A.pdf
>>

I had not seen that. Interesting document.

I did my PIC32 bootloader about 2 or 3 years ago. I went to a trade show
to set up a demo of a product I was responsible for, then went back to the
hotel room and spent a couple days running the simulator and studying the
linker.

>From what I recall, the normal linker script places the startup code and
the application in the application area of flash (not the boot area). The
linker puts a jump to the start of the application startup at the reset
address.

In my bootloader, people can update through an HPPT post, USB, TCP, or
RS232. The application program has code that receives the hex file and
writes it as a series of bytes to external SPI flash. The application then
calls a function in boot flash that copies the external flash to internal
flash and resets the system. That's the basics of it. Note that since the
application startup code is in the application area of flash, the compiler
modifies it as the main program is changed. This works out fine.

To allow for a recovery from a bad bootload, a small C program was put in
the boot section that checks for front panel button presses. If the proper
set of buttons are down, code from another section of external flash is
copied to internal flash. This "small C program" has its own small startup
code. I disassembled a minimal startup, modified it, then put it in the
boot section with it jumping to the button check code.

Two very important items:

1. The CopyExtFlashToPicFlash function must always be at the same address.
If it moves, the application will jump to the new address while the
bootloader in an old unit will have the code at the old address.

2. There is a requirement for a 6us delay for the LVD power up in the
program internal flash routine. This was not shown in the previous version
of the Family Reference Manual. It is now shown in the pseudocode, but not
in sample code. Without the delay, it still worked on B4 silicon, but
fails on B6 silicon. I found that it would erase the internal flash, but
not program a row. Instead, it would return with the low voltage error bit
set.

Harold



-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\11\06@152601 by Electron

flavicon
face

I was thinking that the crt0.s startup code was in the bootstrap flash memory,
while instead it is in the normal program memory, together with main() and all.

That makes things much easier to understand and to implement!



At 19.23 2011.11.06, you wrote:
{Quote hidden}

>

2011\11\06@154851 by Harold Hallikainen

face
flavicon
face

>
> I was thinking that the crt0.s startup code was in the bootstrap flash
> memory,
> while instead it is in the normal program memory, together with main() and
> all.
>
> That makes things much easier to understand and to implement!
>

Yes, that does make it much easier. That lets a normal compile of the
application include the appropriate startup code. I discussed my custom
startup code that jumps to my restore code in the boot section in an
earlier post today.

Harold


-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\11\07@063039 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu] On
Behalf
> Of Harold Hallikainen
> Sent: 05 November 2011 22:36
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] Is this correct code? - and absolute code
>
> I'm mostly doing PIC32 stuff now with C32, the linker, etc. I do a
little
> assembly for it, but very little. I find linker scripts very cryptic.
It'd
> sure be nice if they were commented a bit more. It'd also be nice to
> easily define the address where a function is to be placed. The new
> version of C32 has an attribute that allows this, but it appears there
are
> various issues with this new version (especially in printf).
>
> In my bootloader, I'd like to have a jump table at a specific address
that
> does not move as I make code changes. I see how I could do it in
assembly
> (including use of org, which, it appears, is based on the section
start,
> not the absolute address), but it'd be nice to be able to do it in C.
> Something like:
>
> org SomeAbsoluteVirtualAddress
> function1: goto LocalFunction1;
> Function2: goto LocalFunction2;
> Function3: goto LocalFunction3;
>
> The "LocalFunctions" would still do all the stack operations (getting
> parameters, allocating local variables, cleaning up the stack, etc.).
The
> jump table would just provide a fixed address to access the function.
>
> I did this on the PIC24, building my own interrupt jump table since
the
> PIC24 places the interrupt vector table in the boot section. I just
had
> all those original interrupt vectors point into my jump table, which
then
> pointed to the actual interrupt function. I THINK I did it in C (I'll
have
> to look at the code), but MAY have done it in assembly.
>
> I tried the above stuff (
> function1: goto LocalFunction1;
> Function2: goto LocalFunction2;
> Function3: goto LocalFunction3;
> ), but the C32 compiler did not like it. I don't think it liked the
labels
> (expecting a return value type instead). For now, I've put functions
that
> call local functions at the top of the section, but that uses more
stack
> space and is pretty inefficient.
>
> So... how do I do a jump table in C32? Or do I go back to assembly?

I believe the C32 compiler is GCC based?  I did the exact same thing
using the AVR port of GCC a many years ago, and it's pretty simple once
you plough through the documentation.  Note this almost certainly isn't
the best method, but it does work.  If I were to redo this I would be
tempted to use a structure that could be shared between the bootloader
and application.

In order to locate the jump table, I put the jumps within a function and
then used the various GCC attributes to make the function "naked" i.e.
no prologue or epilogue etc.

In the bootloader I have this:

/* Function prototype */
void JumpTable (void) __attribute__((__unused__))
__attribute__((__naked__)) __attribute__((__section__( ".jump")));

/* Jump table entry macro - target dependant */
#define TB_ENTRY_FAR(addr) __asm__ __volatile__ ("jmp " addr : : )

void JumpTable (void)
{
  // FAR format (each entry 2 words)
  TB_ENTRY_FAR("MyFunc1");  // quotes are necessary
  TB_ENTRY_FAR("MyFunc2");
  TB_ENTRY_FAR("MyFunc3");
  TB_ENTRY_FAR("MyFunc4");
  TB_ENTRY_FAR("MyFunc5");
}

The makefile has the following line added to the linker flags:

-Wl,--section-start=.jump=$(JUMP_TABLE_ADDRESS)

Where JUMP_TABLE_ADDRESS is the start of your jump table.


In the application code I simply defined a bunch of typedefs for each
function type in the jump table (v = void, u8 = unsigned 8 bit, pu8 =
pointer to unsigned 8 bit etc. The first value after 'fp' is the return
type, the following ones are the function arguments).

typedef uint8_t (*fp_u8_pu8)(uint8_t *);
typedef int16_t (*fp_s16_v)(void);
typedef bool (*fp_b_u8)(uint8_t);
typedef void (*fp_v_b)(bool);
typedef uint8_t* (*fp_pu8_v)(void);

And then I define the pointers to the actual function.  JT_BASE is
defined by the makefile, so I only have to change this in one place if I
ever needed to move it.

#define MyFunc1 (a)        ((fp_u8_pu8)(JT_BASE+0))(a)
#define MyFunc2 ()        ((fp_s16_v)( JT_BASE+2))()
#define MyFunc3 (a)        ((fp_b_u8)( JT_BASE+4))(a)
#define MyFunc4 (a)        ((fp_v_b)( JT_BASE+6))(a)
#define MyFunc5 ()        ((fp_pu8_v)( JT_BASE+8))()

The only tricky part was that GCC was expecting word addresses for some
operations and byte addresses for others which resulted in a bit of head
scratching, but this may be specific to the AVR compiler.

HTH

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2011\11\07@065941 by Dave Tweed

face
flavicon
face
Michael Rigby-Jones wrote:
> /* Jump table entry macro - target dependant */
> #define TB_ENTRY_FAR(addr) __asm__ __volatile__ ("jmp " addr : : )
>
> void JumpTable (void)
> {
>    // FAR format (each entry 2 words)
>    TB_ENTRY_FAR("MyFunc1");  // quotes are necessary
>    TB_ENTRY_FAR("MyFunc2");
>    TB_ENTRY_FAR("MyFunc3");
>    TB_ENTRY_FAR("MyFunc4");
>    TB_ENTRY_FAR("MyFunc5");
> }

OK, in this case, MyFunc1, etc. are the addresses of the actual functions,
used as arguments to the jmp instructions.

> And then I define the pointers to the actual function. JT_BASE is defined by
> the makefile, so I only have to change this in one place if I ever needed to
> move it.
>
> #define MyFunc1 (a)        ((fp_u8_pu8)(JT_BASE+0))(a)
> #define MyFunc2 ()        ((fp_s16_v)(JT_BASE+2))()
> #define MyFunc3 (a)        ((fp_b_u8)(JT_BASE+4))(a)
> #define MyFunc4 (a)        ((fp_v_b)(JT_BASE+6))(a)
> #define MyFunc5 ()        ((fp_pu8_v)(JT_BASE+8))()

This doesn't look right. These are pointers into the jump table, not pointers
to the actual functions. These are meant to be used in the application code,
aren't they? As such, shouldn't they should use a different set of names,
rather than MyFunc1, etc. (e.g., JTFunc1, etc.)?

-- Dave Twee

2011\11\07@070547 by PETER ONION

flavicon
face
I can't read earlier post so I may be missing the point, but is there a reason why you can't just use an array of pointers to functions for this ?

PeterO

2011\11\07@072638 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu] On
Behalf
{Quote hidden}

functions,
{Quote hidden}

names,
> rather than MyFunc1, etc. (e.g., JTFunc1, etc.)?
>
Certainly a good idea to clarify that the function pointers call the
target functions indirectly.  In my case the actual names would have
made no other difference (i.e. no name space issues etc.) since the
bootloader and application were two separate projects.

Cheers

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2011\11\07@073610 by Bob Ammerman

flavicon
face

>I can't read earlier post so I may be missing the point, but is there a
>reason
> why you can't just use an array of pointers to functions for this ?
>
> PeterO

An array of pointer to function only really works in a typesafe manner if the signatures of all your functions is the same. You probably want a structure containing pointers to the functions.

(untested code follows!)

===================================
In a header used by both the provider and the consumer of the functions we define a structure type that maps the jump table. The elements of this structure are pointers to functions with various signatures.

typedef struct {
   void (*pA)(void);
   int (*pB)(int,int);
} jmptable_t;

===================================
In the provider that defines the functions to be called we create an instance of the jumptable and initialize it (hopefully by the compiler/linker at build time) with pointers to the functions.

void a(void) ;    // prototype the functions first
int b(int,int);      // ...probably in an include file.

<whatever magic it takes to place this next structure at a specified place in memory goes here>
jmptable_t jt = { a, b };

====================================
In the consumer that calls the functions:

// Declare a pointer to the jump table and initialize it to the hard address in the provider:

jmptable_t  *pJT;   = (jmptable_t *) 0x12345678;


// Now we can call the functions through the jump table:
          (*(pJT->pA))();              // call the first function
          i = (*(pJT->pB))(1,2);    // call the second function

Not sure the '*' belong in the calls above. Probably not. Also one pair of parens in each function call are probably unneeded.

-- Bob Ammerman
RAm Systems

2011\11\07@093737 by Bob Ammerman

flavicon
face
Correction to my previous message:

to call the functions thru the function table all one needs is:

// Now we can call the functions through the jump table:
void CallTester()
{
         int k;
         pJT->pA();              // call the first function
         k = pJT->pB(1,2);    // call the second function
}

-- Bob Ammerman
RAm Systems

2011\11\07@133820 by Electron

flavicon
face

Hi Harold,

At 23.36 2011.11.05, you wrote:
>I'm mostly doing PIC32 stuff now with C32, the linker, etc. I do a little
>assembly for it, but very little. I find linker scripts very cryptic. It'd
>sure be nice if they were commented a bit more. It'd also be nice to
>easily define the address where a function is to be placed. The new
>version of C32 has an attribute that allows this, but it appears there are
>various issues with this new version (especially in printf).
>
>In my bootloader, I'd like to have a jump table at a specific address that
>does not move as I make code changes.

After mumble mumbling I miss the purpose for this, but I'd really like to know!

The bootloader I wanna write is really minimalistic. On ~reset, it should
detect if RxD is kept continuosly low by the host (break), if it's not, it
should simply launch the main application. If it is, it should enter into
a (bootloader) routine which will accept commands through the UART to erase
and write whatever block of program memory I wish.

Perhaps as my menthal context is this and only this, I miss the point of
having an indirect call to functions, like You are implementing. Am I missing
something useful also for my case maybe?

Kind regards,
Mario

2011\11\07@170345 by Sergey Dryga

flavicon
face
Electron <electron2k4 <at> infinito.it> writes:

> The bootloader I wanna write is really minimalistic. On ~reset, it should
> detect if RxD is kept continuosly low by the host (break), if it's not, it
> should simply launch the main application. If it is, it should enter into
> a (bootloader) routine which will accept commands through the UART to erase
> and write whatever block of program memory I wish.

There is a dsPIC bootloader for the 30F4011, which you can use as a basis, or an
example, to develop your own.  You can find it here:
http://www.beaglerobotics.com/community/

Best, Sergey Dryga
http://beaglerobotics.com


2011\11\08@035316 by Electron

flavicon
face
At 23.03 2011.11.07, you wrote:
>Electron <electron2k4 <at> infinito.it> writes:
>
>> The bootloader I wanna write is really minimalistic. On ~reset, it should
>> detect if RxD is kept continuosly low by the host (break), if it's not, it
>> should simply launch the main application. If it is, it should enter into
>> a (bootloader) routine which will accept commands through the UART to erase
>> and write whatever block of program memory I wish.
>
>There is a dsPIC bootloader for the 30F4011, which you can use as a
>basis, or an
>example, to develop your own.  You can find it here:
>http://www.beaglerobotics.com/community/

Thank you, I will have an indeep look at it as soon as I finish reading the list.

Any hints on main differences with a PIC32 implementation? However I need also a
dsPIC one so it's definitely useful to see how others have done it also on the
dsPIC or PIC24.

Greets,
Mario

2011\11\08@045839 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: piclist-bouncesspamspam_OUTmit.edu [@spam@piclist-bouncesKILLspamspammit.edu] On
Behalf
> Of Electron
> Sent: 07 November 2011 18:38
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] Is this correct code? - and absolute code
>
>
> Hi Harold,
>
> At 23.36 2011.11.05, you wrote:
> >I'm mostly doing PIC32 stuff now with C32, the linker, etc. I do a
little
> >assembly for it, but very little. I find linker scripts very cryptic.
> It'd
> >sure be nice if they were commented a bit more. It'd also be nice to
> >easily define the address where a function is to be placed. The new
> >version of C32 has an attribute that allows this, but it appears
there
> are
> >various issues with this new version (especially in printf).
> >
> >In my bootloader, I'd like to have a jump table at a specific address
> that
> >does not move as I make code changes.
>
> After mumble mumbling I miss the purpose for this, but I'd really like
to
> know!
>
> The bootloader I wanna write is really minimalistic. On ~reset, it
should
> detect if RxD is kept continuosly low by the host (break), if it's
not, it
> should simply launch the main application. If it is, it should enter
into
> a (bootloader) routine which will accept commands through the UART to
> erase
> and write whatever block of program memory I wish.
>
> Perhaps as my menthal context is this and only this, I miss the point
of
> having an indirect call to functions, like You are implementing. Am I
> missing
> something useful also for my case maybe?

In my case I needed to carry on processing comms and timer interrupts
whilst a new application firmware was being downloaded (i.e. I couldn't
afford to have the CPU freeze for 5ms or so during each page write).  On
the AVR, there is a specific section of memory (called Read While Write)
from which the CPU can still execute code whilst the main memory is
being written to.  Thus all my interrupts are located in this section
and are either handled by the bootloader during a programming operation,
or by the application code using function pointers.  Also the
programming operation is initiated by the application code, and I
program a secondary area of memory

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2011\11\08@072140 by Electron

flavicon
face
At 10.58 2011.11.08, you wrote:
>In my case I needed to carry on processing comms and timer interrupts
>whilst a new application firmware was being downloaded (i.e. I couldn't
>afford to have the CPU freeze for 5ms or so during each page write).  On
>the AVR, there is a specific section of memory (called Read While Write)
>from which the CPU can still execute code whilst the main memory is
>being written to.  Thus all my interrupts are located in this section
>and are either handled by the bootloader during a programming operation,
>or by the application code using function pointers.  Also the
>programming operation is initiated by the application code, and I
>program a secondary area of memory

Thanks, that explains it all, clever, but luckily for me I have simpler
needs for now.

With kind regards,
Mario

>
>Regards
>
>Mike

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...