Update cycle of SRIO

[Bääääär]

Hello!

I habe lots of LEDs for my project (more than 160) and wanted to save DOUT-pins by using a matrix. Works fine so far, but now I wanted to go further and included PWM in my code. Works fine too, but the LEDs are flickering in 4bit PWM and a matrix of 5x11 LEDs.

The update cycle of DOUTs is too low, but how can I change it? I don't find any info on that in the doku and it doesn't seem like there's any opton in the project's config file...

Please help me out ;) Thanks,

Bääääär

[levon]

there have been some posts on this before

Basically the SRIO doesnt update fast enough to do anything higher than 3bit PWM, this is reduced more when doing a LED Matrix.

I have some TLC5940 PWM LED drivers, and im hoping to get that working with MIOS, but writing code to drive the TLC5940 is just a bit above my programing skills at the moment.

check out these threads:

My plan is to use the TLC and a DOUT module to drive a matrix, i have got this working on arduino all ready as it has drivers for the TLC.

[Bääääär]

there have been some posts on this before

Possible... However, the search function didn't help much in this case.

Basically the SRIO doesnt update fast enough to do anything higher than 3bit PWM, this is reduced more when doing a LED Matrix.

Well... And the update-cycle can't be changed? I read it doesn't consume much CPU (DMA), so that shouldn't load the CPU too much. From the flickering I see at the moment, a update-cycle four times as high should be enough. I don't want 32bit PWM, 4bit is ok - and like I said - it shouldn't laod the CPU too much. Only my PWM-routine (executed before SRIO update) takes some cpu-cycles. But hey, if that works fine on a AVRs @ 16MHz without DMA but with software SPI, then it should definitly work on MIOS32.

Thanks anyway,

Bääääär

Edited January 7, 2011 by Bääääär

[TK.]

The big problem is, that you neither mentioned in the subject, nor in your first posting that you are working with MIOS32!

It makes a big difference compared to MIOS8 (and the slow PIC) - please consider this next time.

The MIOS32_SRIO_ScanStart() function is normaly called from vApplicationTickHook, which is a RTOS hook that is called each mS.

See also http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fprogramming_models%2Ftraditional%2Fmain.c

It isn't possible (resp. recommended) to change the interval of the timer which is used by FreeRTOS, but you could simply call MIOS32_SRIO_ScanStart from an own timer service routine.

In order to disable the default handling, add "#define MIOS32_DONT_SERVICE_SRIO_SCAN 1" to your mios32_config.h file

Now you can call the function from an own timer.

The general usage of a MIOS32 based timer is explained here: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Ftutorials%2F007_mios32_timer%2F

In order to speed up SPI transfers, it makes sense to reduce the number of SRs which have to be serviced, this can be done with "#define MIOS32_SRIO_NUM_SR <actual-number-of-sr>" in mios32_config.h

Best Regards, Thorsten.

[Duggle]

Baar, you may be interested (or no) in a method i've been using to obtain PWM (actually PDM, in this case ) as well as matrix driving). It has no extra constant CPU load but it is at the expense of a little RAM and a little extra embedded code to Set/clear a LED.

The idea is discussed in this thread:

Since then Ive used it in some different contexts, works perfectly. I havn't mixed PDM and matrix but there is no reason not to.

The implementation involves changing some SRIO MIOS32 files with a couple of lines of code, they can be removed for compiling apps which dont require them with a #define switch.

If you (or anyone else) wants I can paste the relevant snippets to this thread.

btw; PDM (pulse density modulation) works the same as PWM but has much less flicker because the highs are distributed in time across the cycle.

[Bääääär]

Hello @ all!

Thanks for your answers. Yes, indeed, I forgot to say I'm working with MIOS32 - sorry :wacko:

@Duggle: Nice idea! I guess I won't use it this time, but I will keep it in mind - seems like a great way to save processing power! PDM, is that your word-creation? The main problem I see is that you have to change MIOS32 files - I'd better not do that until I fully know, what I'm doing. Guess it will become very hard to get help, after I fuzzled around in the system's files. Once you did one hack to the system, others will follow and by the time, the whole MIOS32 will become a big mess :hmm: I'd better wait with that...

@TK: I tried your hint. However it doesn't work at the moment.

I added the #define switch to disable SRIO scans by the system.

Then I added the timer initialisation as described in the tutorial. In the timer routine I call "MIOS32_SRIO_ScanStart(SRIO_ServiceFinish);" as done by the system when the switch is not applied. Of course SRIO_ServiceFinish() is not found and I get a compiler error. I went the brute-force-way and added a forward declaration for it.

Compiled good but during boot-up of MIOS32 nothing happens, even the display stays empty (no boot message).

Well, I have no idea right now, but I'm scanning through the MIOS32 code to find the solution... I don't think it's a timer problem (timers seem to be a simple thing in MIOS - idiotproof [hopefully...]). Maybe you can help me out another time :rolleyes:

Thanks a lot,

Bääääär

[Duggle]

PDM, is that your word-creation?

It turns out to be a very natural concept: http://en.wikipedia....sity_modulation

The main problem I see is that you have to change MIOS32 files - I'd better not do that until I fully know, what I'm doing. Guess it will become very hard to get help, after I fuzzled around in the system's files.

The changes to MIOS32_SRIO.c are small, simple (easy to understand) and are included/removed by a single #define variable which appear in the app's mios32_config.h .

This way when paged DOUT is not required in an app the changes are not present.

[Bääääär]

It turns out to be a very natural concept: http://en.wikipedia....sity_modulation

The changes to MIOS32_SRIO.c are small, simple (easy to understand) and are included/removed by a single #define variable which appear in the app's mios32_config.h .

This way when paged DOUT is not required in an app the changes are not present.

Could you send me your modified MIOS32_SRIO.c? Thanks!

[Duggle]

Could you send me your modified MIOS32_SRIO.c? Thanks!

I dont have the code with me ATM, but I'll put it in a blog article with a link very soon (hopefully today).

There are routines to get/set paged DOUT shift registers which go with mios32_dout.c they dont have to go in this file, but I found modifying the makefiles to build them from a seperate file difficult for some reason, so I put them here. It turns out to be neat and logical anyhow.

On top of this there are the access routines to suit your application that you will be writing yourself app (i.e brightness modulation and matrix scanning etc). I'll see if I can provide an example of these.

[Bääääär]

Ok, I got an update:

I tried several things and found out, that my 100us were just too fast, so events were stacking. That's the reason for the hanging MIOS. I tried different settings and it seems like the maximun is 400us... and still flickering. I wonder why it's not possible to go faster. The problem is not my PWM routine. Setting the timer-cycle to 1ms, MIOS was booting, but no light from the LEDs. I realized I forgot to call the SRIO-Prepare routine before MIOS32_SRIO_ScanStart(SRIO_ServiceFinish). This prooves, that not my PWM routine is the speed barrier (=> it was not involved 'til this point). It must be MIOS32_SRIO_ScanStart(SRIO_ServiceFinish) itself that blocks me from setting the timer faster than 400us.

Any idea what I can do? The worst thing would be to use no matrix. But I got 8 encoders, each surrounded by 11 LEDs and some more LEDs for other purposes. I would need 4 DOUTs instead of one. Or seperate PWM chips...

Thanks,

Bääääär

[TK.]

It's probably related to the slow SPI baudrate which has been selected in mios32_srio.h:

  // init SPI port for baudrate of ca. 2 uS period @ 72 MHz

  MIOS32_SPI_TransferModeInit(MIOS32_SRIO_SPI, MIOS32_SPI_MODE_CLK1_PHASE1, MIOS32_SPI_PRESCALER_128);

[/code]


what happens if you select MIOS32_SPI_PRESCALER_64, MIOS32_SPI_PRESCALER_32, MIOS32_SPI_PRESCALER_16, MIOS32_SPI_PRESCALER_8 (etc) instead.


Change this in your local mios32_srio.c file for testing, start with higher numbers.


It would be interesting at which prescaler value the LEDs get unstable.


Best Regards, Thorsten.

[Bääääär]

It's probably related to the slow SPI baudrate which has been selected in mios32_srio.h:

  // init SPI port for baudrate of ca. 2 uS period @ 72 MHz

  MIOS32_SPI_TransferModeInit(MIOS32_SRIO_SPI, MIOS32_SPI_MODE_CLK1_PHASE1, MIOS32_SPI_PRESCALER_128);

what happens if you select MIOS32_SPI_PRESCALER_64, MIOS32_SPI_PRESCALER_32, MIOS32_SPI_PRESCALER_16, MIOS32_SPI_PRESCALER_8 (etc) instead.

Change this in your local mios32_srio.c file for testing, start with higher numbers.

It would be interesting at which prescaler value the LEDs get unstable.

Best Regards, Thorsten.

OMG, stupid not to think at the prescaler. I already stumbled upon this before, but didn't remeber it now.

Yes, it works. Perfectly :frantics: I started with 8 :devil: and no problems so far. It works as expected. I also tried timer-cycles lower than 100us, just for fun. However, 80us didn't work - 100us is already close to the edge.

Thanks TK!

Edit: a prescaler of 4 makes them unstable, which seems to result in unstable buttons first. I have one DIN and one DOUT connected btw.

Edited January 14, 2011 by Bääääär