Serial LCD display for PIC projects ?

[zorgloub]

Greetings to the Community.
Would you have a serial display to propose to me, compatible with our PIC projects (Kit, schematic or website).
In fact, also user of MCU Basic picaxe I have the serial displays AXE 133 and 134 (2x16 and 4 x 20 OLED display), driven by a Picaxe.
But these do not display correctly the signals coming from a Port leaving a SEROUT signal ...

Thanks in advance.

[richard]

I have the serial displays AXE 133

i see no good reason why those displays would not work with pbp

what code have you tried and how have you wired it up

[zorgloub]

Hi Richard,No, no reason, I thought!
But the reality seems unfortunately different.
To use the serial display driven by a (Basic)Picaxe; the picaxe command is Serout, pinx, N2400_4 or N2400_16 depending on the picaxe used.
But, with PBC, the command Serout, pinx, N2400 does not give the same chronogram !?
See attached image.
I try to use this display (AXE 134), or find another model compatible with my PIC.
Thanks9194

[HenrikOlsson]

Bit timing seems to be in the ballpark for 2400 but apparently the PICAxe has quite a bit of delay between each byte (usually not what you want to see). If the display(s) do work with the PICAxe and the timings you show are correct then you can force PBP to insert extra delay between each byte it sends by inserting the following line.

DEFINE CHAR_PACING 500
This will insert 500us delay between bytes (when using SEROUT) which should then match the PICAxe timing.

If you switch to SEROUT2 then the above DEFINE doesn't work so check the manual if that's something you're planning to do.

I'm not into PICAxe but if I'd guess the _4 and _16 tacked onto the end of the SEROUT command simply specifies which routine to call based on if you're running at 4MHz or at 16MHz. In PBP you use DEFINE OSC 16 and the compiler automatically handles the timing for SEROUT (and other stuff).

[zorgloub]

Hi Henrick;
This forum is great!
Thanks a lot for your intervention!
With:
DEFINE OSC 16
DEFINE CHAR_PACING 500
Symbol BAUD = N2400

The three pulse bursts are well separated by 0.92msec and the display responds well.
What is the relationship between parameter 500 and the 0.92msec timing?
Why not 500µsec?

Testing:
If I test with DEFINE CHAR_PACING 1000, the difference is 1.4 msec and the display is a bit slower.
On the other hand, with DEFINE CHAR_PACING 250, the gap between the bursts is 0,64msec and the display does not work anymore.


9196

[zorgloub]

Here is the simple code:

' ************************************************** ************************
' Programme: Test SEROUT.PBP
' RGL 02-2022
' Testing AXE134 (Picaxe 4x20# OLED Display) ---> PIC 16F630
' PicBasicPro Compiler V:2.40
' ************************************************** ************************


Include "modedefs.bas"

' Pic Specifications
'--------------------
'PIC16F630 with 16Mhz resonator
@ Device Pic16F630,HS_OSC, WDT_OFF, PWRT_ON, PROTECT_OFF, MCLR_OFF
CMCON = 7 'Deactive Comparator RA0+, RA1-, RA2 out
DEFINE OSC 16
DEFINE CHAR_PACING 500

' ******* VARIABLES / CONSTANTS **************************
Symbol BAUD = N2400
Symbol OLED = PORTA.0 'pin13

'*** Definition i/o
'All OUTPUT
TRISA = 0
TRISC = 0

Pause 1000

Serout OLED, BAUD,[254,1] : pause 30 ' Clear Display
Serout OLED, BAUD,[254,128] : PAuse 30 ' Line1, Col1

LOOP:
Serout OLED, BAUD, ["UUU"]
Pause 1000
Goto Loop

[HenrikOlsson]

The three pulse bursts are well separated by 0.92msec and the display responds well.
What is the relationship between parameter 500 and the 0.92msec timing?
Why not 500µsec?
Because at 2400 baud ~420us of that 0.92ms is the normal stopbit. Add to that the additional character pacing of 500us.

At 2400 baud you'd also get the same result by specifying two stop-bits.

[zorgloub]

Great Henrick!
Thank you for your clear and quick answers.
Have a nice evening.

[zorgloub]

@Henrick
I have drawn the timeline in the case of a transmission of two spaced bytes with the command DEFINE CHAR_PACING 1000.
I can see, however, that in addition to the normal Start bit of 410µs, another delay of 410 µs is added to the Pacing 1000!?
9197

[HenrikOlsson]

No, you're forgetting the stop-bit! You have 1 startbit, 8 databits and 1 stopbit.

In your diagram, from left to right: First you have the start-bit (1), then you have 8 data-bits (11000010), then you have the stop-bit (0) and THEN you have the 1000us CHAR_PACING before the next start-bit.

[zorgloub]

OK Henrick.
I have corrected my drawing accordingly.
It should be OK like that.

9202