Serial comms using UART - query

[Aresby]

Hi everyone, I'm new to Swordfish and pretty new at PIC programming although I've done a couple of simple PICAXE projects.

Now I'm using an AMICUS18 board, PICkit2 and Swordfish and it all handshakes just fine. The mandatory flashing LED program compiled, downloaded and ran just fine.

However, the lack of a Serout command has stumped me, as when trying to use the UART with a baud rate of 2400 to display stuff to my LCD module (complete with PICAXE driver chip) I just get garbage.

I've set the clock = 16 and the device = 18F25K20. I've set the baud rate to br2400.

The LCD module expects T2400N1 which I gather is the "default" parity/stop bit setting for the PIC18 series anyway when using the built in UART, hence why there are no options to change this in the Swordfish include file.

Any pointers as to what I need to do or what I'm doing wrong here?

(My next step is to use the Proton compiler with the Amicus just to prove I can actually communicate with the LCD using the standard Serout command available with Proton - but I really want to standardise on the Swordfish as it's closer to the dot.net environment I normally work in and a similar price.)

Any pointers gratefully received.

[Senacharim]

Tip 1: The code in the modules can be viewed. (This has cleared up many questions for me in the past.)

Tip 2: If need be, copy a module the the 'UserLibrary' directory and then modify the copy to your heart's content.

Tip 3: (This one's in the help file...) Specify a module by including the module's name. For example: Let's say I have 2 modules which both have a "send" function. Let's call them 'foo' and 'bar'. Like so:
foo.send() ' <-- calls the send function in the 'foo' module.
bar.send() ' <-- calls the send function in the 'bar' module.

It is good practice to ALWAYS specify which module you're calling.


Lastly, if you're using the hardware USART, the line you're looking for is 'USART.Write()'

[RKP]

Aresby,

Try adding

Code: Select all

#option USART_BRGH = false

After your clock setting but before your includes in your code and let us know if this works.

[Aresby]

Thank you for your replies.

I tried the suggestions (the latter [#option USART_BRGH = false] certainly changed the display but just to a different set of garbage characters).

However, I also tried using the display with the standard Proton compiler that comes with the Amicus with similar results (ie garbage) so it's the PICAXE display that is not communicating successfully with the UART, I'm guessing. I even tried driving the LCD display directly from an output pin, as per one of the Proton examples, wtih no luck (which is what I do with the PICAXE chips as they have no UART).

As I have two such displays (one of them an OLED) I'll decouple the AXE133 intelligent driver and just couple the naked LCD to the Amicus directly and try again. That will surely prove one way or the other whether the LCD can be driven successfully.

The downside is that I need several pins (probably a whole port) to successfully interface the LCD to the Amicus which has only 3. And it means I can't use that LCD display with my PICAXE system as it uses all available pins on my 08M2 chips! The PICAXE133 LCD driver accepts serial output successfully when using PICAXE chips but perhaps there is an element of proprietary handshaking going on behind the scenes, who knows?

I'll post back when I've tried a "naked" LCD (hopefully sometime over the weekend) directly coupled to the AMICUS board and coded using both Proton and Swordfish.

[Jerry Messina]

The LCD module expects T2400N1

Are you sure about that?

The picaxe examples I see for the AXE133 seem to show

Code: Select all

serout B.7,N2400,(“Hello”)

which would use an inverted output (TX pin idle low).

You can set the uart TX polarity using the CKTXP bit in the BAUDCON register. From the datasheet:

The default state of this bit is ‘0’ which selects high true transmit idle and data bits. Setting the CKTXP bit to ‘1’ will invert the transmit data resulting in low true idle and data bits.

[RKP]

To follow up on what Jerry is saying try adding

Code: Select all

SetBaudrate(br2400)
BAUDCON = BAUDCON Or %00010000

to your code.

This should invert the output so the AXE133 LCD will understand the data.

Also you could use the software UART, module SUART.Bas I believe this works similiar to the PICAXE Uart, the output is already inverted by default and you can choose any available pin as the output.

[Aresby]

Thanks again for your inputs.

I first tried the software (SUART) method as I figured this was the method I was most familiar with and which the PICAXE 133 is known to work.

Until I set the variable Pacing=350 all was just a garbled mess; introducing the delay worked wonders. 350 uS was the lowest setting I could use without it reverting to garbage. This still displays a message in a flash so that's fine. Even the special codes (eg to clear the display) work.

Unfortunately, trying to write out any kind of variable value results in a garbled display (just for those characters). So writing out a float, integer etc is still not possible using this method.


I then tried the hardware USART.

Including the USART_BRGH = False is an absolute necessity to get partial success, as is setting the CKTXP in the BAUDCONbits to invert the output.

However, at this stage I can only send individual bytes (such as "A") separted by a small delay of DelayMS(30).

Looking at the USART.BAS it appears that strings of more than one character are handled differently to all other data types which possibly explains why I'm getting success with single character bytes but garbage when trying to send a complete string.

Incidentally, although other variable types (eg float, word) all seem to call the same WriteByte subroutine, none of these other types display correctly either.

Perhaps it's all down to the pacing speed again, but I can't work out how (whether it's possible even) to adjust this on a hardware USART.

I'd love to get the hardware method working so any further suggestions would be most welcome.

Thanks to everyone so far, at least I have one working solution and am half way towards the other.

Just to make you smile (ironically), I only read these last two answers AFTER I had oh-so-carefully desoldered the driver chip from my OLED display (do you know how hard it is to desolder a 14-pin header from a through-hole PCB using solder wick? Sigh.) Thanks goodness I still had my old LCD version with which to continue these tests!

[Jerry Messina]

It looks like there's possibly a few issues.

The AXE133 serial LCD module internally uses a PICAXE to do its serial interface, and for whatever reason it's using a software uart to do it. In general, a real hardware uart beats a software one hands down. They're usually ok for transmitting, but they're not so great for receiving. Hardware uarts have addtl buffering so the timing (while still important) isn't quite so critical. The 350us delay between characters is probably the processing time req'd by the displays PICAXE chip. There you're pretty much stuck... the code just can't handle incoming chars faster than this.

Unfortunately, the SF hardware USART module doesn't have a Pacing setting like the software UART module does, so you can't adjust the time between chars. You could add one, but you'd have to add it in two different places so for the time being I'd suggest you use the software UART module since you found out how to make it work with the AXE133.

I think the other issue you're having is with the data itself. The WriteXXXX() routines in the uart modules send binary bytes, not ASCII text. That works out fine for sending messages, but if you want to display a variable's value you'll have to use one of the routines in CONVERT.bas to format it into a string first.

Code: Select all

dim wValue as word
dim fVal as float

wValue = 123
fVal = 34.567

UART.Write("Hello World", 13, 10)                // string
UART.Write("Binary  : ", BinToStr(wValue), 13, 10)  // binary number
UART.Write("Hex     : ", HexToStr(wValue), 13, 10)  // hex number
UART.Write("Decimal : ", DecToStr(wValue), 13, 10)  // decimal number

UART.Write("Float   : ", FloatToStr(fVal), 13, 10)  // decimal number

[Aresby]

@Jerry

I had just about come to the same conclusion about using the software USART, and the need to convert the values in the manner you suggest.

You have confirmed my suspicions that the PICAXE serial interface is OK for some simple stuff (exactly the audience that TechEd aim their PICAXE items at, such as students) but for other work I really need to accept the limitiations or use a naked device or a different device altogether.

On a far more general note regarding Swordfish I find it a huge stumbling block not having access to a printable language reference (such as that available with the Proton compiler). I'm one of those sad geeks that actually does RTFM, sometimes page by page, so at least I have lodged something at the back of my mind for future use. Swordfish doesn't give me this so it's a bit of an uphill struggle.

This is a pity because the Swordfish approach is, in some ways, superior to the Proton offering due to its dot net-like subroutines, overloaded methods and the like (which I'm used to and use every day in my day job). Never in my wildest dreams did I ever expect this sort of high level IDE/compiler to be available for a relatively humble PIC (when compared to a fully blown Intel/AMD microprocessor).

However, using the Proton system as I have just done to repeat this entire serial output exercise with 100% success makes me think I should stick to Proton until such time that I no longer rely on the manual so much.

Certainly trying to use both systems makes my head hurt and my Amuicus gets its bootloader overwritten everytime I use my PicKit2 with Swordfish

Anyway, I've not given up on Swordfish, and I really appreciate all the help you guys have given me. It is, however, time I got on with my project which is the reason I had to move away from PICAXE as its compiler did not understand such esoteric constructs such as string and float variables.

I might just write the code twice, in Proton and Swordfish just to see which one is better/easier - although I fully accept this can be a quite subjective judgement!

[Jerry Messina]

Lots of folks like Proton... I'm just not one of them. Like you, I find the whole approach of Swordfish to be much more in line with other programming languages, and with the open libraries (mostly written in SF itself) much easier to deal with than convoluted macros and asm includes. But, as I always say the best tool is the one that works for you.

If you don't mind killing a few trees printing things out, there are pdf's of both the language reference and the libraries available:

http://www.sfcompiler.co.uk/downloads/SFManual.pdf

http://www.sfcompiler.co.uk/wiki/upload ... erence.pdf

Maybe a good project would be to replace the code in the AXE133 with code to use the hardware usart. Add some buffering, and the whole thing would work much better.

[Aresby]

Thank you for those links to PDFs.

I had the first one already (unfortunately a few trees were harmed as I printed it out) but I hadn't seen the second one except on-screen. I shall consider carefully whether I need to print it or not.

I've just discovered that I can call subroutines in Proton with parameters too. It's a bit convoluted and just PUSHes and POPs a user-defined stack but it's a step in the right direction (for me).

If only I could merge Swordfish and Proton I think I would have the perfect compiler

I'll post back to this forum should I get my latest project running with Swordfish - or I'll post back why it wouldn't work for me.

[Senacharim]

If coded in Proton, Microcode Studio, & Swordfish and I'll take Swordfish over the others any day of the week.

[Aresby]

... if you want to display a variable's value you'll have to use one of the routines in CONVERT.bas to format it into a string first.

<snip>

UART.Write("Float : ", FloatToStr(fVal), 13, 10) // decimal number

If I include CONVERT.BAS (even if I don't reference any of the routines in my code) I get a compiler error on line 455 CMCON = $07.

The compiler says:

[Error] utils.bas(455): Left side cannot be assigned to
[Error] utils.bas(455): Identifier not declared: CMCON
Anyone have any ideas?

Meanwhile I'm now struggling to get my PicKit2 programmer to work with the Amicus board using Swordfish - something that I have working on my computer upstairs but the one in the workshop is resolutely refusing to play nicely. Half the problem is that the command window disappears so quickly there's never enough time to read the error message(s), despite having the parameter set to wait for 9 seconds (which only seems to be honoured when there is NO error!).

Never a dull moment...

[Aresby]

I've trapped the error messages:

WARNING: VDD below device bulk erase voltage
- Erase/Program may not be successful.
PICkit 2 Program Report
22-Mar-2012, 07:28:20
Device Type: PIC18F25K20

Program Memory Errors

Address Good Bad
000000 00EF31 000000
VPP Error detected. Check target for proper connectivity.

Not sure what it's telling me here. The Amicus board is powered by a standard 9v supply. PicKit2 writes the HEX file just fine if run manually using the file created by Swordfish.

I'm guessing there is something wrong with my command line so I'll compare it to my other computer but I just copied this from someone else's thread that defines the parameters (and checked them against the PicKit2 help file).

I'll post back if I get a soluton before anyone responds to this.

[Aresby]

I changed the PicKit2 parameters to the just following: /M /R /Hk (ie I took out the /W) and from the command line I got:

PICkit 2 Program Report
22-Mar-2012, 07:38:04
Device Type: PIC18F25K20

Program Succeeded.

Press any key to exit.

Update: now working from Swordfish too. I deleted the old programmer on the basis there must be somthing dodgy in its setup and re-created it using the same set of parameters as above.

That only took about 4 hours to resolve. MY fix-to-fail time must be improving.