P2 Serial and LCD (60x40 text) Drivers using a common Formatting Object and Buffers (superceded)
Replaced by this thread - because I changed the way it is implemented
This code is still valid. although it will be incompatible with the newer objects which have been renamed to avoid confusion
The title says it all!
This post brings together the following threads
P2 Multiport x16 Serial Driver working (based on JonnyMac's FullDuplexSerial)
4.0in TFT SPI 480x320 LCD ST7796 Driver and TCS2046 touchscreen support
New Generation of Low Level Driver for P2
I have been working for years on both P1 and P2 to bring together the possibility of utilising a standard buffer interface that decouples the physical driver code which usually resides in it's/their own pasm cog(s), and the formatting object that converts strings, numerics, etc into a single object that has consistent named methods and can be used across most character drivers (ie not microSD etc).
For the formatting object "mpx_fullduplexserial.spin2", I have taken @JonnyMac 's fantastic jm_fullduplexserial object to use as the base. I have tidied up a few naming methods (to include tx and rx for the most used ones) and added a few extras (txASCII and txDump, along with rxStr - a method to receive CR terminated strings and return a zero-terminated string). @Kaio has made some great suggestions too although at present they have not been included due to timing. The big thing that I did was to bring in a more common buffer pointer mechanism that can be carried over to the pasm drivers.
I have written a new multiport serial driver "mpx_multiportserialdriver.spin2"- the base version supports up to 16 serial pins in any mix of transmitters and receivers, on any pins, and any baud (note I said baud as it is not baud rate - a pet peeve of mine to fix incorrect usage). I also have a variant that caters for 64 serial pins although I don't expect much use!
Now today, I also release a new LCD SPI Text Driver "lcd_textdriver_480x320.spin2". This driver supports my standard formatting object, so all the string, numerics, dump, etc features of the formatting are supported. It utilises the standard buffering mechanism I've formulated. It's an extension to the head and tail method originally used by Chip in his P1 fullduplexserial object.
The demo "lcd_demo.spin2 supports a full duplex serial port (2 port/pins as a pair) and the lcd port. Formatted messages can be sent to both serial and LCD at will, using the duplicated, but identical formatting object as described above.
This brings me to the ultimate objective. Since the drivers have been fully decoupled from their calling and formatting routines, it is now feasible to substitute the drivers when necessary. Once these drivers can be compiled and loaded as separate entities, we will have true on-the-fly indirection on our little micro.
The LCD Driver does not have scrolling working as yet. I kludged a version over on the LCD thread but I'm still investigating other ways. At present I'm using an 8x8 font which gives 60 columns by 40 rows in landscape format. I have used a 6x8 font (80 columns by 40 rows) but it's not present as an option here - again see the LCD thread for code. I was also looking at an 8x12 font (from @baggers) but nothing yet.
The LCD I use is a 4.0" TFT SPI 480x320 V1.0 (color) which has at it's heart an ST7796 chip which is similar to the ILI9163 chip on much smaller 160x160 color LCDs. This LCD is available in smaller versions too, as well as parallel and arduino versions.
Mine also has a Touch Pad chip although I haven't used it yet. @mwroberts has kindly done a touch driver for P2 and he posted code on the LCD thread so check it out.
There are probably a few tweeks I'll need to do to make it more user friendly to call, but it's not too bad really. The main part is to look at the demo file.
BTW There's a Quick Bytes for the multiport serial object and it describes the operation in a bit more detail.
Multiple Serial Port (8 UART – 16 Tx/Rx) Object
Note: SEND and RECV have not been used. I do not feel they adequately support this mechanism. There has been discussion on the abovementioned threads. You can read this if in doubt.
Currently only tested on FastSpin v5.0.8 although the multiportserial works on pnut and proptool IIRC, so no reason this shouldn't. I'm working the next couple of days.