A Not-so-trivial Idea for Using the Software UART and PICkit

Discuss PIC and electronic related things

Moderators: David Barker, Jerry Messina

Post Reply
Jon Chandler
Registered User
Registered User
Posts: 185
Joined: Mon Mar 10, 2008 8:20 am
Location: Seattle, WA USA
Contact:

A Not-so-trivial Idea for Using the Software UART and PICkit

Post by Jon Chandler » Mon Sep 06, 2010 7:28 am

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!

User avatar
ohararp
Posts: 194
Joined: Tue Oct 03, 2006 11:29 pm
Location: Dayton, OH USA
Contact:

Post by ohararp » Mon Sep 06, 2010 5:24 pm

Jon, part of the reason I hate the pickit3 is that it does not have this features. The software uart commands can put a hurt on smaller chips in terms of code space and ram but with most 18F parts I use this isn't really a problem.
Thanks Ryan
$25 SMT Stencils!!!
www.ohararp.com/Stencils.html

Jon Chandler
Registered User
Registered User
Posts: 185
Joined: Mon Mar 10, 2008 8:20 am
Location: Seattle, WA USA
Contact:

Post by Jon Chandler » Mon Sep 06, 2010 6:11 pm

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

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Post by Jerry Messina » Tue Sep 07, 2010 2:52 pm

It's not really the suart that's the hog. Passing strings around can start eating up a lot of resources pretty quick...

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

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

Compare the code and data sizes to the above calls...

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

Post Reply