• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 585 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Port C program from ROM library based to TI-RTOS

david genge
Intellectual 600 points
Other Parts Discussed in Thread: EK-TM4C123GXL, TM4C123GH6PM

Context:  CCS Version: 6.0.1.00040         TI-RTOS for TivaC (IDE Client)    2.10.1.38      EK-TM4C123GXL

Project:   a team of garden maintenance robots each based on EK-TM4C123GXL (TM4C123GH6PM)

Status:

Used TivaWare™ Peripheral Driver Library in ROM to implement all required I/O (only I2C not used). Great!

Implementing my own SDcard driver/file system was too arduous so...

I've watched the RTOS videos once and a bit. (kudos on the videos, I know that's a LOT of work)

I now see how RTOS will be extremely useful for implementing higher levels of abstraction atop the I/O base.

Have appropriately modified and successfully run the SDSPI demo (yaaaaay! robots now have big memory)

I understand IRQs, vectors, tasks, semaphores, events, ques, etc. quite well thanks in part to videos

so now perhaps all i need to know is...

How/where do I initialize hardware in a way compatible with RTOS before invoking RTOS?

and related: Is it proper to still use TivaWare™ Peripheral Driver Library in ROM calls under RTOS?

Where can I find 'motor' drivers (using PWMs and QEIs)?

If I must write a driver where can I find the "Writing RTOS Drivers Guide?

Do you have any tips so i can progress quickly with minimum reading (lol)? 

Thanks very much.

Dave

(No doubt more questions later)

  • 0
    TI__Mastermind 30830 points

    Dave,

    1) In general, the peripherals that TI-RTOS drivers support are initialized by TI-RTOS and do not need to be initialized by the user.

    Other low level initialization hooks are provided by the xdc.runtime.Startup module.

    Specifically, the xdc.runtime.Reset.fxns which are called before C initialization, and the xdc.runtime.Startup.firstFxns and xdc.runtime.Startup.lastFxns which are run before and after TI-RTOS module initialization respectively.

    2) In general, it is dangerous to use TivaWare driver APIs on peripherals that are managed by TI-RTOS.

    3) The latest TI-RTOS release includes a PWM driver module that can be used to drive motors and servos.

    4) I'll ask around to find a guide for writing your own drivers.

    Alan

  • 0 in reply to Alan DeMars
    Intellectual 600 points
    Context: CCS Version: 6.0.1.00040 TI-RTOS for TivaC (IDE Client) 2.10.1.38 EK-TM4C123GXL
    Thanks Alan,
    The fog of ignorance is beginning to lift and the ins and outs of the system are becoming clear.

    I see now that I can use any of the system resources that RTOS doesn't use (although i still don't know all the resources it does use but that will come in time).

    I started with a copy of the SDSPI demo (my main motivation for using RTOS) to test my hardware design (which worked (whew!))
    Copy and pasted my initialization routines for ADC, other UARTS, QEIs etc. and called them just before BIOS_start(); and that worked,
    (note: had to remove 'ROM_' from the front of all the library calls).
    Pasted my ADC Interrupt Service Routine (which copies the converted values from the hardware FIFO into a global array variable) and used XGCONF to setup its 'conversion complete' interrupt, (one has to look up the IRQ number in the vector table in the Tiva TM4C123GH6PM Microcontroller DATA SHEET),
    wrote a timerfxn and used XGCONF to create a timer object to cause timerfxn to be executed 10 times a second,
    in the timerfxn made a call to ADCProcessorTrigger(ADC0_BASE, 0) to start the ADC conversion,
    added a TASK to process the raw conversion data into meaningful values,
    added a binary SEMAPHORE so the ADC ISR could 'post' a signal to tell the TASK when to stop 'pending',
    added an 'idle' function just to print stuff so i could see if and when it ran,
    (note: there's a check box in XGCONF inthe 'task' area that you have to check before idle will work!),
    sprinkled System_printf("something") everywhere (don't know how to setup'instumentation" yet) and
    it all works wonderfully! Yaaaay.

    Now, I did have everything working (thanks to all those library routines in ROM) before I switched to RTOS (except sdcard) but it was all low level stuff. Sure the robot could see an obstacle and feel a collision etc. but how to program it to respond appropriately represents some real challenges that I now see the RTOS will considerably ease.

    So in repose to your
    1) I understand that now
    2) yes, makes no sense to mess with stuff the OS is using
    3) don't care because i now see how my PWM/PID/QEI code and the rest can be easily stuffed into the RTOS framework.
    4) i reckon folks at TI are writing more drivers even now but in light of the above i don't need to.

    Thanks again Alan,
    I hope this note is useful to others who might be as overwhelmed as i was by the sheer volume of .pdfs and videos...
    Cheers,
    Dave
  • 0 in reply to david genge
    Intellectual 600 points
    One more thing: as i discovered: one should read all of the TI_RTOS_Kernel_Workshop_Student_Guide_rev2.30.pdf. It is very helpful (blush).