From: Adam B. <ac...@co...> - 2003-09-22 06:28:25
|
I'm working with a flash based part and the project requires some configuration variables to be stored in the device flash memory. Ideally these values can be changed at runtime, but there's an issue with their locations. The flash is organized in 512 byte blocks that must be completely erased and reprogrammed to change a single byte value. However, if the code builds so that the memory aligns the configuration block such it contains any code, it seems pretty dangerous to erasing and reprogramming the code segment. This would be an especially SIGNIFICANT issue if code to reprogram the flash memory happens to align with the block that contains the actual data. I was wondering if there is any way to configure a build with SDCC to handle this situation automatically. I found the information about absolute addressing, but this doesn't sound as this would help unless I exclude a segment of the code memory and handle the allocation of this block myself. Thanks, Adam |
From: Josh S. <jo...@4s...> - 2003-09-22 14:58:34
|
I would use the absolute addressing to place it at the very last block of the flash memory, so that it is completely separate from your code space. For example, if it's a 16k flash, store your variables from 0x3E00-0x3FFF. While it would be convenient for SDCC to handle this automatically, it would add quite a bit of programming complexity. Basically, there would need to be a way to have user-defined data segments, and then a way for the C-code to specifiy in which segment the variable should go. Regards, Josh Stone -----Original Message----- From: sdc...@li... [mailto:sdc...@li...]On Behalf Of Adam Braun Sent: Monday, September 22, 2003 12:27 AM To: sdc...@li... Subject: [Sdcc-user] Anyway to specify addsolute location for ROM/flash variables? I'm working with a flash based part and the project requires some configuration variables to be stored in the device flash memory. Ideally these values can be changed at runtime, but there's an issue with their locations. The flash is organized in 512 byte blocks that must be completely erased and reprogrammed to change a single byte value. However, if the code builds so that the memory aligns the configuration block such it contains any code, it seems pretty dangerous to erasing and reprogramming the code segment. This would be an especially SIGNIFICANT issue if code to reprogram the flash memory happens to align with the block that contains the actual data. I was wondering if there is any way to configure a build with SDCC to handle this situation automatically. I found the information about absolute addressing, but this doesn't sound as this would help unless I exclude a segment of the code memory and handle the allocation of this block myself. Thanks, Adam |
From: Dave M. <mc...@ne...> - 2003-09-22 15:44:19
|
On Monday, September 22, 2003, at 10:56 AM, Josh Stone wrote: > I would use the absolute addressing to place it at the very last block=20= > of the flash memory, so that it is completely separate from your code=20= > space.=A0 For example, if it's a 16k flash, store your variables from=20= > 0x3E00-0x3FFF. > =A0 > While it would be convenient for SDCC to handle this automatically, it=20= > would add quite a bit of programming complexity.=A0 Basically, there=20= > would need to be a way to have user-defined data segments, and then a=20= > way for the C-code to specifiy in which segment the variable should > = go. Hmm...correct me if I'm wrong, but I believe this wouldn't actually=20= be all that difficult. I'm doing a very similar thing in several of my=20= projects (not for flash, for some other stuff) and it involves the use=20= of an assembly language source file in your code. In that file, use=20 the appropriate assembler directives to put variables where you want=20 them, and then make them global. You'd want to do something like this: .module foo .title foo .globl _var1 ;; make these symbols global .globl _var2 .area FLASH_VARS (XSEG) ;; or wherever it needs to land...see=20 assembler docs .org 0xf000 ;; or wherever your flash is located _var1: .ds 1 ;; 1-byte variable _var2: .ds 16 ;; 16-byte variable ... Now you can reference "var1" and "var2" from C code, and they'll be=20= at the absolute addresses defined by the .org directive. Be sure to=20 check the .rst file to make sure the symbols land where you expect them=20= to. -Dave -- Dave McGuire "My tummy hurts now, but my soul St. Petersburg, FL feels a little better." -Ed |
From: Josh S. <jo...@4s...> - 2003-09-22 16:36:54
|
Yeah, that would work too... that's not much different than declaring the variables with absolute addressing, except that your way makes declaring multiple variables easier. The complexity I was referring to is if we tried to make that functionality available in pure C - similar to the way the xdata and idata storage classes work. Even with those, you could have used an asm to declare them in the right place, but the storage classes make it much easier. So what I'm getting at is, it would be really cool if you could define custom storage class subtypes. One idea would be to add the capability to define a range on the storage classes, so your variable would be declared like "code(0x3E00,0x3FFF) char myvar;". Then you could do make a macro "#define flash code(0x3E00,0x3FFF)" so your variable looks like "flash char myvar;". You could also use a syntax similar to absolute addressing, like "code from 0x3E00 to 0x3FFF char myvar;". Ah, now I'm just rambling... I think all of this would be useful, but your way works fine too... Regards, Josh Stone > -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On Behalf Of Dave McGuire > Sent: Monday, September 22, 2003 9:44 AM > To: sdc...@li... > Subject: Re: [Sdcc-user] Anyway to specify addsolute location for > ROM/flash variables? > > > On Monday, September 22, 2003, at 10:56 AM, Josh Stone wrote: > > I would use the absolute addressing to place it at the very last block > > of the flash memory, so that it is completely separate from your code > > space. For example, if it's a 16k flash, store your variables from > > 0x3E00-0x3FFF. > > > > While it would be convenient for SDCC to handle this automatically, it > > would add quite a bit of programming complexity. Basically, there > > would need to be a way to have user-defined data segments, and then a > > way for the C-code to specifiy in which segment the variable > should > go. > > Hmm...correct me if I'm wrong, but I believe this wouldn't actually > be all that difficult. I'm doing a very similar thing in several of my > projects (not for flash, for some other stuff) and it involves the use > of an assembly language source file in your code. In that file, use > the appropriate assembler directives to put variables where you want > them, and then make them global. > > You'd want to do something like this: > > .module foo > .title foo > > .globl _var1 ;; make these symbols global > .globl _var2 > > .area FLASH_VARS (XSEG) ;; or wherever it needs to land...see > assembler docs > .org 0xf000 ;; or wherever your flash is located > > _var1: .ds 1 ;; 1-byte variable > _var2: .ds 16 ;; 16-byte variable > ... > > Now you can reference "var1" and "var2" from C code, and they'll be > at the absolute addresses defined by the .org directive. Be sure to > check the .rst file to make sure the symbols land where you expect them > to. > > -Dave > > -- > Dave McGuire "My tummy hurts now, but my soul > St. Petersburg, FL feels a little better." -Ed > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Dave M. <mc...@ne...> - 2003-09-22 17:18:36
|
On Monday, September 22, 2003, at 12:34 PM, Josh Stone wrote: > Yeah, that would work too... that's not much different than declaring > the > variables with absolute addressing, except that your way makes > declaring > multiple variables easier. It does somewhat. My method is particularly handy for my application because the variables are shared between some assembly code routines and some C routines. The code in question is an I2C driver for Philips P89C66x microcontrollers...I have C-callable assembly routines to retrieve values from I2C nodes and place them in buffers which are accessible as unsigned char arrays in C. That assembly code and those buffers are defined in the same assembler source file, with appropriate .area and .org directives to make them land in the right places. > The complexity I was referring to is if we tried to make that > functionality > available in pure C - similar to the way the xdata and idata storage > classes > work. Even with those, you could have used an asm to declare them in > the > right place, but the storage classes make it much easier. So what I'm > getting at is, it would be really cool if you could define custom > storage > class subtypes. Agreed...that would be very nice indeed. > One idea would be to add the capability to define a range on the > storage > classes, so your variable would be declared like "code(0x3E00,0x3FFF) > char > myvar;". Then you could do make a macro "#define flash > code(0x3E00,0x3FFF)" > so your variable looks like "flash char myvar;". You could also use a > syntax similar to absolute addressing, like "code from 0x3E00 to > 0x3FFF char > myvar;". So that would be nearly analogous to defining an .area in assembler, then dropping things into it? That's a very interesting idea. -Dave -- Dave McGuire "My tummy hurts now, but my soul St. Petersburg, FL feels a little better." -Ed |
From: Josh S. <jo...@4s...> - 2003-09-22 18:01:41
|
> -----Original Message----- > From: sdc...@li... > [mailto:sdc...@li...]On Behalf Of Dave McGuire > Sent: Monday, September 22, 2003 11:19 AM > To: sdc...@li... > Subject: Re: [Sdcc-user] Anyway to specify addsolute location for > ROM/flash variables? > > > So that would be nearly analogous to defining an .area in assembler, > then dropping things into it? That's a very interesting idea. > > -Dave > That's the idea... It would make segmenting very easy to handle. For instance, if you implemented most of your xdata space with normal sram, but then part of it you want non-volatile ram, it would be very easy to specify variables that should be placed in the nvram. Josh |