PDA

View Full Version : 'reserving' memory space



comwarrior
- 22nd September 2009, 03:19
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

mackrackit
- 22nd September 2009, 06:34
Something like this?
http://www.picbasic.co.uk/forum/showthread.php?t=137&highlight=playground

Melanie
- 22nd September 2009, 14:50
I find this quite useful - especially in PICs which have insufficient EEPROM for my needs...



'
' 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:


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).

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.

comwarrior
- 23rd September 2009, 17:13
hmmm, interesting...
I'm assuming i can then use ORG to position it in memory?

Thanks mel

Melanie
- 23rd September 2009, 18:13
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

comwarrior
- 23rd September 2009, 22:07
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....

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

avoides the faulty locations and recompile it using mplabs compiler...

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)...

Melanie
- 23rd September 2009, 23:04
And you're going to put in how many hours of effort in order to save yourself $4 ?

comwarrior
- 23rd September 2009, 23:18
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!"?

mackrackit
- 24th September 2009, 02:04
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. :)

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.

comwarrior
- 25th September 2009, 01:28
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...

mackrackit
- 25th September 2009, 04:39
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...
And now we know you are serious about this stuff!
COOL!!!! :)

comwarrior
- 25th September 2009, 22:37
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