This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Sysbios timings issue with TMS320F28062

Other Parts Discussed in Thread: SYSBIOS, TMS320F28062

Hi,

I am actually evaluating possibility to use sysbios (6.35.1.29) on a TMS320f28062 (clk=90MHz) to drive a power supply. In my basic program, I use

- One low priority task toggling one output,

- One clock (swi) posting a semaphore to access an high priority task. This second task toggles a second ouput.

If I choose Tick period & Clock period between 100us and 1ms, it seems that the OS begin to have some difficulties to follow. I can see that because my low priority task is almost never called and my high priority task shows a non-periodic access (meaning that Tick period is lower than semaphore treatment latency). - Checked via oscillo connected to outputs -

My target is to periodically call functions that would launch actions like ADC conversion and result treatment with an approximate period of 100us. This with other tasks that must have a maximum latency below 5ms.  Can I do that with SYSbios? (I hope yes!).

Many thanks for your feedback.

  • Hi Van Goethem Fr��d��ric,

    Do you know what memory your code is running out of?  Is it in flash?

    If so, we've seen a problem on the 28 h/w where running code out of flash was resulting in a very high number of wait states.

    Van Goethem Fr��d��ric said:
    If I choose Tick period & Clock period between 100us and 1ms, it seems that the OS begin to have some difficulties to follow. I can see that because my low priority task is almost never called and my high priority task shows a non-periodic access (meaning that Tick period is lower than semaphore treatment latency). - Checked via oscillo connected to outputs -

    I think you mean that if you start with periods at 1ms, behavior is stable/normal.  But as you decrease the period down, approaching 100us, you begin to see the difficulties.  Right?

    I think this is expected.  I'm betting that at this low period value, your app is being hammered by Timer interrupts, causing to erratic behavior that you are seeing.

    Van Goethem Fr��d��ric said:
    My target is to periodically call functions that would launch actions like ADC conversion and result treatment with an approximate period of 100us. This with other tasks that must have a maximum latency below 5ms.  Can I do that with SYSbios? (I hope yes!).

    Based on the info I have so far, the best answer I can give you is maybe.  How many tasks will you be launching that will do ADC work?  How many "other tasks" will you have in your system.

    Once you give us a more detailed overview of the requirements of your app, hopefully we can give you a better answer.

    Steve

  • HI Steve,

    First many thanks for these precious information's!

    In fact, my code is running from flash. I know that I can transfer it to RAM to decrease execution timings but not yet tried.

    I confirm that the behaviour of the system is normal for timings under 1ms and begin to be strange below.This could probably be linked to these wait state delays? Could we avoid it? Could you give me more details on these wait states?

    Other details: my application needs some other special features like

    - More ADC conversions (24 ADC usings analog muxs)

    - Short latency on some outputs control (mainly for alarms and regulation)

    - USB communication with USB bootloader

    These features would be implemented as swi, tasks, hwi. The hwi would be transfered to the OS via semaphores as suggested in your applications notes.

    Many thanks for your feedback!

  • Van Goethem Fr��d��ric said:

    In fact, my code is running from flash. I know that I can transfer it to RAM to decrease execution timings but not yet tried.

    I confirm that the behaviour of the system is normal for timings under 1ms and begin to be strange below.This could probably be linked to these wait state delays? Could we avoid it? Could you give me more details on these wait states?

    I think you should first try to run out of RAM and then retry your experiments.

    Unfortunately I think there may still be issues due to the high number of timer interrupts triggering so frequently.

    Van Goethem Fr��d��ric said:

    Other details: my application needs some other special features like

    - More ADC conversions (24 ADC usings analog muxs)

    It sounds like the majority of the work will be taken up by the ADC conversions.  What's the worst case for such a work load?  Will you need to process the data for 24 conversions at the same time?

    Steve