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

I'm generally bemused wrt establishing what 'spec' PIC I need for my PICBAsic program. I guess this is becuase I've not really had to worry about it - I write a simple program, I then flash the PIC - it works.

I'm using a 16f690, for no other reason than it came bundled with my Pickit2 programmer ('lethargy rules ok')....I'm now in a position where I'd like to knock up a few 'widgets', which will need a PIC....I see there are other lesser PICs that have the same functionality as the 16f690, but with less RAM. (PIC16F631/677/685/687/689)

How can I establish what spec PIC I need (from a RAM perspective), for my modest program? (becuase saving some dosh on buying the PIC I can 'just' get away with is always welcome).

Is there some way of establishing that the codespace/RAM for a given picbasic program/pic is say xx% utilized etc?

Well first of all Microchip provide free samples in small quantities.
I've received everything from pic32s to dsPic to 12C508s for free.

You can only really tell how much RAM you need with trial and error where PBP is concerned.
It's own asm routines added to your program to make the BASIC command lines work are
never really seen without disassembly of the compiled program.

That being said, it isn't too difficult to tell how much RAM you have LEFT on the chip you are using.
Just define a bunch of useless variables before a critical variable is defined
(one that the program will fail without).

An array is good for this, just up the number of elements until no more can be assigned,
then you know bank 0 is full, do it again to consume the rest of the space until the program fails.

Say you have your code working on the 690. Look at the *.lst file near the end and see how much of what the code uses. Then dig through the specs from other chips to see what one is large enough.

I use MicroCode Studio Plus... I think it tells you the memory used in the Status Bar.

...

and MPLAB has the " memory usage gauge " ... in the " view " menu ...

Alain

Firstly my apologies....I thought I'd thanked you all, just come back to this thread to find I hadn't so Thank You!

Ok, so it seem 4096 words being used seems to be the 'significant' number wrt using a 16f690 ....anything more & I get compilation error messages.

So I started commenting out a few lines of code to see which commands are eating the word count.

By taking out about six (long) lines inserted randomly throughout my code as follows,.....

Code:

---

IF debug_active= 1 then DEBUG "below    pwm= ", DEC pwm_width," Target= ",DEC target," Sig= ", DEC signal_in, " Mode_status =", DEC mode, " On_Status = ", dec on_status, " AGC Status= ", dec Agc_on_status, 13, 10

---

(debug_active is just variable I use to erhmm activate/deactivate debug info out the debug port/pin)

......the words count used in my program plummets from around 4080-ish to about 1700 words?!!!

Can anyone explain why? (or have a good pop & accounting for the word plummet?!)

& while I'm on, which are the most hungry commands from using up the word space?

cheers,
Hank.

You can play around with Darrels CodeSize program to find some answers. I am not sure why, but it looks like each letter you are printing to your serial port is 3 words long. If you can abbreviate, you will be able to save some space.

Check out his code here: http://www.picbasic.co.uk/forum/cont...odeSize-Update

Walter

Quote:

---

I use MicroCode Studio Plus... I think it tells you the memory used in the Status Bar.

---

Where? I don't see it.

Quote:

---

Originally Posted by circuitpro

Where? I don't see it.

---

It tells you in the status bar, here. But you have to have it turned on with:

Code:

---

Define Measure 1

---

(and include the include file, of course)

Attachment 4713

Bottom left hand corner after you compile.

Success:blablabla bytes used.

Oh, there it is! That's telling you how much flash/program memory you're using, right? Is there a way to see or monitor your RAM useage?

Quote:

---

Originally Posted by circuitpro

Oh, there it is! That's telling you how much flash/program memory you're using, right? Is there a way to see or monitor your RAM useage?

---

That's right, its program data not RAM. Unfortunately I do not know of a clean way to read how much ram you are using. But someone taught me a trick of:

Code:

---

test var byte[96]

---

And if it is too big to fit, make it smaller. The size allowed in the program will be the amount of RAM you have left.

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

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.

Very nice tool, Dave. Thanks very much!

Quote:

---

Originally Posted by circuitpro

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.

Quote:

---

Originally Posted by 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.)


/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!

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:

Code:

---

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.

Quote:

---

Originally Posted by 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.

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?

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.

Quote:

---

Originally Posted by 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.

---

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)

At the risk of talking to myself, yes HSEROUT, can be 'switched' to pin4 (RX) of the Pickit2 - and characters sent via that manner displays fine on the Pickit2 Uart 2 (no garbled data anymore!)

For anyone with a 16f690, who want the settings I'm using to get HSEROUT, here you go...

Code:

---

@ __CONFIG _FCMEN_OFF & _INTRC_OSC_NOCLKOUT & _WDT_OFF & _MCLRE_OFF & _CP_OFF & _IESO_OFF & _BOR_OFF & _PWRTE_OFF

Include "modedefs.bas"

DEFINE HSER_SPBRG 25
DEFINE HSER_TXSTA 24h
DEFINE HSER_CLROERR 1

DEFINE OSC 4
ANSELH=0
ANSEL=0
CM1CON0 =0
CM2CON0 =0
CM2CON1 =0
adcon1=0

TRISB.7 = 0
rcsta.7=1   'this one switches 16f690's Pin 10 from RB7 (general IO) to USART TX usage- it caught me out!

loop:
hserout ["Hello ", 13, 10]
pause 100
goto loop
end

---

Set your Pickit2 UArt tool baud setting to 9600 - away you go!

Now I'm sure this is going to be embarrasingly obvious/simple, *but*

I'm using a 16F1824, the spec says the following...

"Up to 8 Kbytes Linear Program Memory"

however, when I compile my program & goes above 4096 (as shown in microcode studio) I get an error "ARGUMENT OUT OF RANGE" ....if I strip some code out, to take it below 4096...then all is well again.

So where has the extra 4k of programming space gone?!! ie how can I can take advantage of it?!

Microcode Studio shows that number, the 4096, in words (2 bytes) for the 16F series. However, for the 18F series Microcode Studio shows that number in bytes. Don't ask me why..... :eek:

Robert