Well, using an external EEPROM have it's advantages as well. If you Strings are LCD dedicated, you can also format them the right way in a HEX Editor.
I use bpsoft Hex WorkShop.
|
Well, using an external EEPROM have it's advantages as well. If you Strings are LCD dedicated, you can also format them the right way in a HEX Editor.
I use bpsoft Hex WorkShop.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
|
I'm using a graphic LCD with a whole set of subroutines to display the characters. I suppose I could probably stored the lines in the eeprom as hard coded characters (1 byte per line, 6 lines per character) and pull them out serially (actually 5x7 character font, could probably do some compression on those to save the extra byte here and there).Originally Posted by mister_e
When I run out of room on the '4620, I'll plug an eeprom in and see what happens...or just go with a '4685 (or '8722).
Nothing like extra space to cover for sloppy programming!
uh-hum...WindowsHate it, but what do we all use?
|
Just keep in mind that no matter how much Flash the PIC has, PBP can only use the first 64kb of it. Same as your 4620.
The additional space can be used to store data, but not PBP program code.
<br>
DT
|
Really? I made a program awhile back for my '8722 (with my adapter, plugged into a slot originally for a '4620). I copied/pasted a load of code (a load of LCDOUT statements) back to back just to fill it all up (I wanted to see what would happen)...and it programmed...the full 128K and it ran, all the way to the end.
It looked something like this:
LCDOUT "START"
LCDOUT "SAME" a whole bunch of these lines
LCDOUT "END" : STOP a line like this at the end, verified in the .lst file as being at the end of programmable space
I could've been wrong, but the programmer software (Warp13a) showed it being full up. And the same code wouldn't fit into a '4620. And if you think about it, the '8722 only has 64K-words, the '4620 32K-words, so maybe PBP can still take it.
|
No, not really. That didn't come out right at all.
The space above 64K can't be accessed by the READCODE statement. So your string data has to be in the first 64K. The space above 64k can store data, but READCODE can't use it. It's possible to write an ASM routine that does the same thing as readcode and uses the upper space, but it's not built in to PBP.
Hope that clarifies it a bit.
<br>
DT
|
That sounds about right, and makes quite a bit more sense.
So noted for the next project....
Members who have read this thread : 0You do not have permission to view the list of names.
Posting Permissions
Bookmarks