need some project advice :)

russdx · ‎2012-10-07

Posted on October 07, 2012 at 14:21

Hello 🙂

I have a little project using a stm32f4 which receives usb data from the pc using the cdc classes (2048bytes @ 60fps) and then draws them to a Plasma dot matrix display.

I have it all working ok 🙂 The problem is, the dot matrix display needs to be continually refreshed to keep the image on it /create different shades of colour. When i am not sending usb data the image is fine, nice and stable. But when i start sending the usb data at 60fps it starts to flicker slightly. This is because the cpu is going off to do the usb stuff and taking cpu time away from updating the display :(

is there any way around this? is the cdc class pure interrupt driven? is there a way i can tell it when i want it to run its usb functions. (basically i control the cpu time)

I have had this problem with other microcontrollers but was hoping the speed of this one would solve the problem. only way i have managed to successfully solve the problem is use a FPGA+FTDI but this is quite expensive and was hoping i could do the whole thing just with one stm32f4

any advice would be much appreciated.

#display

jj2 · ‎2012-10-07

Posted on October 07, 2012 at 17:01

Would you be so good as to describe your ''Plasma Color display?'' Am reasonably experienced/skilled w/Displays. (helped develop Matsushita/Pana. mono Plasma - and earlier Compac ''lunchbox'') Is yours a basic ''TV'' panel? If not - need spec or at minimum maker and model number.

Your quest is usually not ''do-able'' by the MCU alone - but depending upon pixel size and color depth - we may have a workaround which proves suitable...

russdx · ‎2012-10-07

Posted on October 08, 2012 at 01:34

Hello

yes the display is this

www.

vishay

.com/docs/37006/apd128g.pdf

each pixel is bit banged out to the display (all 4096 of them)

each pixel can only be on or off, so to create shades (16 in my case) you just flip between 4 sub frames each one with different pixels set to create the 16 shade illusion (each sub frame is 512bytes = 128x32pixels)*4 = full 16 shade frame (ie the 2048bytes)

it seams to be the when refreshing this display if the cpu gets taking away from this process even for the smallest time it upsets it quite badly and you get a slight flicker. when the code is purely just running the display refresh routine its perfect.

but because im sending these frames at 60fps it keeps the usb side of things very busy as well taking the cpu away from the drawing process :(

there are some quite big delays in the display refresh process which would be ideal for it to go off and do usb stuff.

jj2 · ‎2012-10-07

Posted on October 08, 2012 at 02:00

Your reply clears much confusion - ''color'' in your 1st post really is, ''shades of gray,'' and this should be achievable w/ this ARM MCU.

Review the display's spec - usually there are distinct periods in which the display handles incoming data best. (i.e. usually end of each/every line and end of frame) A proper display controller w/in your display should ''signal'' such safe/risky time periods...

In addition - have you organized the display data so that the MCU can, ''machine-gun'' out this data as quickly - and efficiently as possible? DMA transfer may serve you best in this objective.

A final method would be to, ''hold off'' the USB host during especially critical, ''display transaction'' periods. Perhaps you can devise a ''signaling'' method in which the USB follows a, ''Command - Response'' form of protocol. You may also consider shortening the USB transactions - so that the MCU is less burdened...

In all such cases - your goal is greatly aided if you can develop, ''real numbers'' which identify precisely what time & signal ''windows'' work. You then instrument your code so that you stay w/in these parameters...

russdx · ‎2012-10-07

Posted on October 08, 2012 at 02:12

Hey 🙂

yes sorry its not ''colour'' but shades of one colour 🙂

yes there is definitely windows of time i would like the usb to use up rather then just diverting the cpu when it wants it. i was under the impression all the usb code was interrupt driven and just takes the cpu when needed. can this be controlled by me?

at the moment im just using simple GPIO set at 100mhz to bit bang the data, ill try the DMA method to speed this up 🙂

Thanks for your suggestions i will certainly give them all a go! 🙂

jj2 · ‎2012-10-07

Posted on October 08, 2012 at 06:03

Do keep in mind - via basic experimentation you should be able to learn the exact, ''time windows'' in which you can transfer data to the display. Usually the display will show more ''disturbance'' at particular refresh time periods - your testing for and then exploiting this knowledge will yield the best results...

russdx · ‎2012-10-07

Posted on October 08, 2012 at 08:42

Yup 🙂

I have a 5microsec and a 100microsec delay in my main refresh loop. i will start with these as my usb windows 🙂

one thing im not 100% sure on as i am not that familiar with the usb code yet is how i make sure it only executes within my free cpu windows, when the pc wants to send it data i cant just say no i dont want it yet? or can i? i guess i need to do some research here hehe 🙂

thanks for all your help 🙂

jj2 · ‎2012-10-08

Posted on October 08, 2012 at 16:27

You'll add considerable simplicity and robustness if you can ''model'' the old-school, ''Command-Response'' method of communication. Your M4 MCU must be the ''boss'' here - as it machine-guns the display and must deal with the USB.

Too uncontrolled USB transmissions are your challenge here - until you can properly limit or control these you may have to live w/occasional display, ''tearing.''

Classical solutions involve an external display buffer - managed by fpga/cpld (as you noted) or some method to make the USB transmission more conforming/better behaved. This may prove very challenging...

russdx · ‎2012-10-08

Posted on October 08, 2012 at 17:26

fpga+ftdi chip works beautifully (this was my rev2 but to expensive to put into production) its one thing i love about fpga's they can do every thing at once!!! 🙂

i have really come to like this little stm32f4 microprocessor and would love to use it in my rev3 design as it would make my board so simple as the stm32 would be the only chip on it!!! 🙂

im going to have a good read through all the usb classes and see if i can figure out how its pieced together and hopefully add in some code so it only receives frames when i want it to 🙂

im also going to swap my pixel shift out code (big gpio for loop at the moment) for a spi dma controlled one hopefully take some load of the cpu so the usb can use it plus it should be alot faster so yet more free cpu time for the usb stuff 🙂

i think if i play enough ill get it working 🙂 its very close its just a slight flicker just needs some tweaking to perfect 🙂

jj2 · ‎2012-10-08

Posted on October 08, 2012 at 20:47

You know this - but as reminder - insure that your inner SW Display loop is as small, fast executing as possible.

There is a caution - be certain that you do not violate set-up, hold, or data rates of the display control circuits. If you make a mistake here you will spend considerable time, ''chasing your tail'' to fix. (Do not ask, ''How I know...'')

Once you have your display transfer loops optimized - you should be able to incrementally ''fatten'' them (one at a time) and learn exactly where & when the display starts to ''balk.''