'reserving' memory space
I want to 'reserve' a fixed chunk of program memory so that I can load code from a serial eeprom... proberbly a similar thing to a boot loader...
I was thinking of using the assembler ORG command but i was wondering if their was a spacific way of doing it in picbasic?
What aproches do people use?
Thanks
|
Something like this?
http://www.picbasic.co.uk/forum/show...ght=playground
Dave
Always wear safety glasses while programming.
|
I find this quite useful - especially in PICs which have insufficient EEPROM for my needs...
Now, you can reserve as little or as much Programspace as you want and PICBasic takes care of everything else. The most I'd ever done was 8kB, but it sure is handy (and saves on having an external EEPROM). Just remember how much you've allocated and never to do write operations outside of your allocated space (otherwise you'll corrupt your own program).Code:' ' Executable Program Starts Here ' ============================== goto JumpStart ' ' System References ' ================ ' ' SETUPs ' ------ Setups: ASM db 0xA4,0xA5,0xB0,0xB1,0xB2,0xB3,0xB4,0xD0 ; 00-07 db 0xD1,0xD2,0xD5,0xD6,0xD9,0xDA,0xDD,0xDE ; 08-15 db 0xE1,0xE2,0xE5,0xE6,0xE7,0xE8,0xE9,0xEA ; 16-23 db 0xEB,0xEC,0xED,0xEE,0xF0,0xF1,0xF2,0xF4 ; 24-31 db 0xFA,0xF9,0xEF,0x00,0x00,0x00,0x00,0x00 ; 32-39 db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ; 40-47 db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ; 48-55 db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ; 56-63 db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ; 64-71 db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ; 72-79 db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ; 80-87 db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ; 88-95 db 0xB5,0xB6,0xB7,0xB8,0xB9,0xBA,0x00,0x00 ; 96-103 db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ; 104-111 db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ; 112-119 db 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 ; 120-127 ENDASM JumpStart:
This is a great way for long-term but occasional Data-Logging (like the Plastic Chickens you have in your industrial Fridge or Freezers) as you really minimalise your parts count.
|
hmmm, interesting...
I'm assuming i can then use ORG to position it in memory?
Thanks mel
|
Actually I don't do that, because I prefer PBP to position it's internals for itself. If you start using ORG then you could, potentially, run the risk of having PBP create code that could intrude into your reserved space. All I do is workout the address of the start Label (in my previous example 'Setups:') and reference everything from that starting point. The added advantage is that all the reports for BYTE or WORD usage for your PIC take into account your Reserved Space and you get a better feel for how you're filling your PIC up. If you decide you are going to use ORG and position your reserved space up in high memory (nothing stopping you doing that), then you don't get a clear idea of how big your PBP code is, and how much you've got vacant before you intrude into your reserved space.
And before you turn around and ask "How can I work out how to get the address of a Label?", let me refer you to a three-year-old thread...
http://www.picbasic.co.uk/forum/showthread.php?t=3881
|
ok, going to have to come clean...
the reason i want to block off some memory addresses is because one of my original PIC's (877A) has faulty memory locations due to a slight power surge and brownout while being programed... yes, my PC PSU was wrecked... luckerly the only other damage was my graphics card...
i have a low level, really basic task for it to do, if i can get the program to skip the affected memory locations...
The blocks are...
0x0008 to 0x003F
0x0108 to 0x013F
0x0208 to 0x023F
0x0308 to 0x033F
0x0408 to 0x043F
0x0508 to 0x053F
0x0608 to 0x063F
0x0708 to 0x073F
Anyone see a paturn?... lol
the thaught occured to me to alter the ASM so that the memory table thing....
avoides the faulty locations and recompile it using mplabs compiler...Code:RAM_START EQU 00020h RAM_END EQU 001EFh RAM_BANKS EQU 00004h BANK0_START EQU 00020h BANK0_END EQU 0007Fh BANK1_START EQU 000A0h BANK1_END EQU 000EFh BANK2_START EQU 00110h BANK2_END EQU 0016Fh BANK3_START EQU 00190h BANK3_END EQU 001EFh EEPROM_START EQU 02100h EEPROM_END EQU 021FFh
But then i realised it wasn't going to be that easy...
:edit
Having said that... i could alter EEPROM_START to after the first bad block, manually insert a jump followed by enough 3FFF's, and hope the program fits in befor the seconds one (unlikely)...
Last edited by comwarrior; - 23rd September 2009 at 22:13.
|
And you're going to put in how many hours of effort in order to save yourself $4 ?
|
it seems a waste to just throw it...
it's too easy these days to just throw something away and get a new one just coz of a little problem...
What happened to adaptation and flexability?
What ever happend to the atitude, "I can fix that!"?
|
I have a bucket of parts like that. Someday I will use them to make "artwork" , might even be displayed in our local gallery.Originally Posted by comwarrior
At some point we have to let go. It was a good PIC, and will be missed by all.
Seriously, I would not trust it now. Who knows what other damage it has.
Dave
Always wear safety glasses while programming.
|
i've determined that PBP is putting a jump followed by the assembled MAC file (macro's?) at the start of the rom...
Somehow i need to find away to get it to move it...
I once made a borg cube out of dead motherboards...
:edit
their is some code in pbppic14.lib that it places at the start of the rom. I sucessfully got it to place the code in an area of uneffected rom by editing the lib file...
It manually assembled without error...
winpic shows jumps in the first un-affected row 0000-0007 and then lib code at 0040 and my program exactly when i want it at 0800...
Excelent...
However... unfortunatly... it failed to verify at 0048... when i read it back it looks like the entire rom first page is completely trashed and not just in paturns... all the way down to 07BF...
Result... well, now i know an intimate part of how PB works... but also, the pic is trash...
Was it a waste of time?
Hell no, i know tonns more about how PB compiles/assembles and how the rom in a pic is filled...
Last edited by comwarrior; - 25th September 2009 at 02:18.
|
And now we know you are serious about this stuff!
COOL!!!!
Dave
Always wear safety glasses while programming.
|
Well, i not sure if your taking the micky or not...
But yes, i is serious...
I learned everything i know, wether it's IT systems, Web developement / dynamic content / eCommerce through to electronics and laws of physics etc by doing it, trying things out, making mistakes...
It may be in a lot of comedy sketches... but what does actually happen why you press the red button?
My first employment was with a process control company... they were using 8086's as their core processor and the processor boards cost them £2,000 each never mind and DAC's, ADC's, comms cards or digital IO...
Since i started working with pic's I keep thinking back to those times and can't help but think I can make a process controll system that half the size and a fraction of the cost...
Today i had confirmation from crownhill that my order of 2 16F877A's, 2 20MHz res, 1 18F4550 and 100 100K resisters has been dispatched...
I'm looking forward to playing with a pic18...
i have mentioned people on the picbasic forum in one of my utube video's about my pic controled pulse motor.
Most of my free time atm is spent testing and perfecting my lenzless generator...
Thanks All
CW
Members who have read this thread : 1You do not have permission to view the list of names.
Posting Permissions
Bookmarks