NetBurner Community Forum

I will be using a mod5270 for a new project.
I have 3 SPI devices.

#1) 320x240 color lcd
#2) Touch Panel IC
#3) SD card.

of course, these each use different SPI modes. I am looking for any ideas / thoughts on how one would control multiple SPI devices when there are different SPI modes for each. For instance, when the LCD is updating the screen, and the user touches the panel, i get a IRQ. i need to switch the SPI to that mode for the touch screen devce get its information. But while doing that the lcd thread will be unaware of this so it's writes are now jacked up.

I could use some sort of signal in the LCD thread to check before it writes if something else is using the SPI, but that would seriously slow down the speed. To do this for all three devices seems a poor way to manage that.

Any ideas or hints to better make this happen ?

Just out of curiosity, are there really no good solutions for an 8-bit parallel bus touch screen or display? It seems like this would be so much faster. The only lcd design I did was many years ago, and used an 8-bit bus.

I have a 4.3" using an Epson controller using the 8-bit bus. But its to costly.
This LCD i have have now is TFT full color with Touch panel built in. only $18.
It can be used in many modes. 8,16,18 bit or SPI.
The SPI bandwidth is very fast 10mhz. so updating the screen takes no time at all.

i'd be interested in knowing what lcd device you are using.

as to multiple spi devices, we simply have a wrapper that handles the
device contention using a semaphore. it also keeps track of the last spi
paramaters loaded to ensure that the correct params are set on changes
of device/cs as needed. we also have benevolent usage to ensure that
one device doesn't hold the bus "too long". for our display we make lots
of use of viewporting so the whole screen doesn't need to be updated
reducing the amount of data being sent at a time.

I am using the MI0283QT-2 from http://www.multi-inno.com/TFT.asp

What i cant see is if say we need to clear the screen 320x240 = 76800 writes to the screen.
if in that loop, the touch needs to be accesses and the SD card does as well.
i just don't see a clean way to handle all of this.

Re: MIO283 display
Thsi is a very interesting device. Is there a graphics driver/code available?

Thanks,

not sure, i wrote mine.

Being a software only guy I probably have too naive a view of this. I typically set up my SPI to do a payload at a time. A payload varies with the target device (typically 6-32 bits). All SPI devices are latch enabled/disabled so I only have to guarantee that the single payload write is atomic. At 10MHz that should be well within the user/touch panel time frame I would think but I don't know from experience. (I put the touchpanel/display on a serial port).

I use a base SPI class and an associated Factory class that returns me an instance with the proper bit width, msb first/last, proper fast slow clock etc. Then I have an instance of this rather low level SPI object held by the higher object like the screen. The screen class itself would have the latch enable/disable methods. So a pseudo code method would look like this: Currently I do all SPI from the same thread but if I wanted it multi-threaded I would do one of two things.
1. acquire a semaphore in the LatchEnable and release it in the LatchDisable(). I know semaphores can be expensive, so maybe this is too low a granularity for the atomicity but it's where I would start. I would probably make the a base latch class that takes care of the semaphore stuff for all the devices that need a semaphored latch.
[Now I'm thinking out loud]
2. Create a LatchController. Pass it a pointer to a struct or class that contains the latch of interest (probably an enum), the payload or a pointer to the payload, a reference to the m_spi object (which already knows how big a payload is), and possibly a priority. This controller would run in its own thread and just execute all SPI requests from highest priority down. All other threads needing SPI would delegate those requests to this thread. Depending on how you pass the data (I'm thinking a MesageQueue but maybe there are better ways) you might not save any time over the semaphore approach but you would get prioritized processing and it seems less likely to cause race conditions. You would also give up some deterministic behavior.

Hey you're the one who asked for ideas!

The issue you will have is that the SD driver will need modification to work if you use the same SPI port. I ran into this with my MOD5234 design. I have a 16 bit bus interfaced TFT LCD display, SPI interface touch driver and then a Micro SD card. You need code to preserve and reset the SPI timing otherwise the SD card stops working and you get garbage.

I had to modifiy the Netburner libraries to get the SPI to work with both as you need a semaphore or mutex to hand this over different tasks. See this forum entry in regards to the code needed to make it all work and the issues I ran into.

http://forum.embeddedethernet.com/viewt ... ?f=5&t=958

As for a suitable driver, Ramtex.dk do a very good LCD driver for this controller but not sure if it supports SPI out of the box. I know it works just fine with 8 and 16 bit data bus. It might seem expensive if only for hobby work but for commercial, it was easy to setup and get going. Took me about 15 mins and I had it working with Netburner. You get full source code and it is pretty quick. If you go with the version that includes the LCD bitmap editor, creating bitmaps that link with your code is easy and it has a nice way to pack images together and then display them based on index. I use this for buttons where all the graphics are a single image side by side. It has all the editing to support this.

You could modify the output driver to do the SPI if need be as it is all very modular and easy to use.

http://ramtex.dk/gclcd/glcd0129.htm

Dave...

i'm using the MI0283QT-2 in one of my current projects.
for a quick setup and check-out of the display i used
//Multi-Inno MI0283QT-2 (HX8347D) - http://www.watterott.net
which has a single .c file to act as a driver above the spi level.
a small q-n-d spi driver that i've used before did what i needed.
anyway, inside that file they show how to do viewporting with
register writes. by breaking the 240x320 into however many
parts as you needed, you can stop the long spi hogging,
e.g., define sequential areas of 20x320 and release the spi
in between if needed.

i also am using the ramtex for gui prototyping using their
windows sim. i next have to stuff a few function stubs that
ramtex provides to port it over to the real hardware and merge
with the code referenced above.

the gpio and adc for the MI0283QT-2 touch screen was kinda fun.
i've got another pile of code to do something better than a straight
linear translation of the voltages to positions but that's another day.