How can I establish what RAM I need...and therefore which PIC.

[mackrackit]

http://www.picbasic.co.uk/forum/showthread.php?t=10381
Talks about RAM.
I never did fix the little program in the thread though

[HenrikOlsson]

Hi Hank,
Each character within double quotes of the debug statement eats three bytes of program memory. Counting the number of characters in that single line you posted makes for 70 characters or 210 bytes worth of program space.

The Debug statement itself seems to eat 52 bytes but it's a "one time deal" ie, it doesn't cost you 52 bytes each time you use DEBUG. (It might cost you a byte or two depending on where in the program they are placed.)

There may be ways around this (search for Strings in codespace) but if you just need "a couple" of more bytes then try to reduce the number of characters in your DEBUG statements.

If you do look at the Strings in codespace threads I'd be interested in what you come up with. I'm pretty much having the same issue but using ArrayWrite. The problem with Strings in codespace are they are strings (constants) and I haven't yet figured out how to mix them with numeric values "printed" with the DEC modifier etc.

/Henrik.

[HankMcSpank]

Hi Hank,
Each character within double quotes of the debug statement eats three bytes of program memory. Counting the number of characters in that single line you posted makes for 70 characters or 210 bytes worth of program space.

The Debug statement itself seems to eat 52 bytes but it's a "one time deal" ie, it doesn't cost you 52 bytes each time you use DEBUG. (It might cost you a byte or two depending on where in the program they are placed.)


/Henrik.

Thanks (& to all the others) I was figuring it must the the monster amount of characters I'm using upo in the debug lines - the problem I have is I need to see a fair amount of data as my program works it's way back & forward....abbreviations become awkward to interpret with such a lot of onscreen info - I guess I could always go & make sure all the debug output columns align & put a bit of paper along the top of my screen with what each column means!

[HenrikOlsson]

Hi Hank,
Instead of using a bunch of spaces have you tried "lining up" you columns by sending the ASCII code for TAB, I think it's 9, that might save a couple of bytes here and there.

Another option worth looking into is to use the REP modifier, these two lines:

DEBUG "Ten spaces to follow:          ", 13, 10 
DEBUG "Ten spaces to follow:", REP " "\10, 13, 10

Prints the same thing on the screen but the second takes up 6 bytes less space. Obviosuly there's a break-even point where the extra codespace needed by REP eats up more than simply spelling out the repeated characters but you get the idea.

Good luck!
/Henrik.

[HankMcSpank]

Hi Hank,
Instead of using a bunch of spaces have you tried "lining up" you columns by sending the ASCII code for TAB, I think it's 9, that might save a couple of bytes here and there.

Good luck!
/Henrik.

Just to give some feedback here - a judiscious amount of abbreviating in my original unfeasibly long debug line, coupled with use of Henrik's tab idea above - ie of boshing in a load of ,9, entries throughout debug the line vs the spaces I was using (which is also superb for lining all the onscreen info up - much easier on the eye) has seen my program wordcount plummet - (from about 4080 to circa 2200) I'm chuffed to bits.

My Uart 'VT' is somewhat irritatinlgy outputting a line with corrupt characters every 7-10 lines - could this be because my program uses two interupts ....thereby garbling the serial data a little?

[HenrikOlsson]

Hello,
DEBUG is a bit-banged serial routine that uses software loops to achieve the correct timing. If you're using interrupts they will mess with that timing.

If the interrupts aren't very critical timing wise you can disable (mask) them while executing the debug statement. If an interrupt occurs while the debug statement is executing its interrupt request flag will get set and the ISR will fire as soon as you enable the interrupt again.

The 16F690 however has a EUSART, are you using it or its pin for something else? If not you can switch to HSEROUT instead of DEBUG, that way all the baudrate generating stuff are handled by in hardware.

/Henrik.

[HankMcSpank]

Hello,
DEBUG is a bit-banged serial routine that uses software loops to achieve the correct timing. If you're using interrupts they will mess with that timing.

If the interrupts aren't very critical timing wise you can disable (mask) them while executing the debug statement. If an interrupt occurs while the debug statement is executing its interrupt request flag will get set and the ISR will fire as soon as you enable the interrupt again.

The 16F690 however has a EUSART, are you using it or its pin for something else? If not you can switch to HSEROUT instead of DEBUG, that way all the baudrate generating stuff are handled by in hardware.

/Henrik.

Thanks Henrik, looks like HSEROUT is the way to go - It looks like the 16f690 'TX' pin is pin 10 (RB7) & as luck would have it, that pin is still free in my setup - presumably I can feed the HSEROUT serial data from the PIC RB7 direct into the pickit2 & still use the Pickit2 Uart tool? (ie by feeding RB7 into Pickit2 pin 4, 'RX' pin). I'd rather go this way, as this will save me any extra wiring (I already have a switch installed to switch the Pickit2's RX pin4 back & forward between to my present nominated debug port/pin & back to pin 19 - ICSPDAT - on the 16f690 where it needs to go to program the PIC up)

[circuitpro]

Very nice tool, Dave. Thanks very much!

[mackrackit]

Very nice tool, Dave. Thanks very much!

I guess I should try to fix it. But read Darrel's comments and you will get the idea of the problem.