In a D'oh moment, I realized I had completely missed one option when using the PICkit 2 UART tool for monitoring program operation....use the software UART module and ICSP pin for output to the UART tool.
Here are the details:
http://digital-diy.com/home/swordfish/c ... kit-2.html
I hope I'm not the only one who has been oblivious to this simple trick!
A Not-so-trivial Idea for Using the Software UART and PICkit
Moderators: David Barker, Jerry Messina
-
- Registered User
- Posts: 185
- Joined: Mon Mar 10, 2008 8:20 am
- Location: Seattle, WA USA
- Contact:
-
- Registered User
- Posts: 185
- Joined: Mon Mar 10, 2008 8:20 am
- Location: Seattle, WA USA
- Contact:
Good point. Just to check, a program I'm working on with the software UART and half-a-dozen print statements compiles with this result:
3761 program bytes used
216 variable bytes used
Remove the software UART include, setup commands and print statements resulted in this:
2601 program bytes used
130 variable bytes used
so the software UART does have a considerable overhead!
Jon
3761 program bytes used
216 variable bytes used
Remove the software UART include, setup commands and print statements resulted in this:
2601 program bytes used
130 variable bytes used
so the software UART does have a considerable overhead!
Jon
-
- Swordfish Developer
- Posts: 1469
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
It's not really the suart that's the hog. Passing strings around can start eating up a lot of resources pretty quick...
It's very flexible, but not too efficient. It adds code to copy the rom string to ram for each call, and it uses more data mem as the strings get longer and longer.
In situations where code and data size are important, I like to add a sub that can deal with the strings in rom directly, something like...
suart.bas:
Compare the code and data sizes to the above calls...
This way, adding new messages only adds code space, not data mem space. It tends to be a bit quicker, too.
The downside is you have to deal with the funny syntax, but if you have a lot of fixed messages, you can save boatloads of space.
Jon - great tip for using the suart with the pickit2, BTW.
Code: Select all
uart.write(13, 10)
// code=357, data=53 (baseline)
uart.write("my name is fred", 13, 10)
// code=459, data=65 (adds code=102, data=12)
uart.write("I like pizza", 13, 10)
// code=499, data=65 (adds code=40, data=0)
uart.write("I like beer...........lots and lots of beer", 13, 10)
// code=569, data=93 (adds code=70, data=28)
In situations where code and data size are important, I like to add a sub that can deal with the strings in rom directly, something like...
suart.bas:
Code: Select all
// write a const string to uart
// examples:
// const msg1 = "ABC"
// const msg2 = #13 + #10 + "message"
// WriteConstStr(@msg1)
// WriteConstStr(@msg2)
// WriteConstStr(@("12 34" + #10 + #13))
// WriteConstStr(@(#10 + #13))
// Note: Swordfish needs EEPGD to be set in order to access program
// memory constants (such as strings) when a program is executing
inline sub access_memory_progmem()
EECON1 = $80 // EEPGD=1, CFGS=0
end sub
public sub WriteConstStr(const_addr as TABLEPTR)
dim t_tblptru as byte // copy of TBLPTRU
// save tblptru
t_tblptru = TBLPTRU
// const strings reside in the first 64k page of rom space...
TBLPTRU = 0
access_memory_progmem()
asm
TBLRD*+
end asm
while (TABLAT <> 0)
WriteByte(TABLAT)
asm
TBLRD*+
end asm
wend
// restore tblptru
TBLPTRU = t_tblptru
end sub
Code: Select all
uart.writeconststr(@(#13 + #10))
// code=395, data=53
uart.writeconststr(@("my name is fred" + #13 + #10))
// code=423, data=53 (adds code=28, data=0)
uart.writeconststr(@("I like pizza" + #13 + #10))
// code=449, data=53 (adds code=26, data=0)
uart.writeconststr(@("I like beer...........lots and lots of beer" + #13 + #10))
// code=505, data=53 (adds code=56, data=0)
The downside is you have to deal with the funny syntax, but if you have a lot of fixed messages, you can save boatloads of space.
Jon - great tip for using the suart with the pickit2, BTW.