• Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 310 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.

Understanding how to get I/O into Code Composer Simulator

Loren Caler
Intellectual 265 points

I am working on a project that uses the External Pin 4 on a C6416 chip to interrupt our software to read from a GPIO port about 2K's worth of data.


We would like to run some simulations on the software first using the Code Composer 3.3 Simulator.  I read through the technical document, and think I understand there are two files that I need to create to generate the interrupts and have the simulator push the data through.

What I don't understand from the document is how these two files correlate as far as timing, and what the format of the files need to be.  Also, how do I input the files into the simulator?

  • Intellectual 265 points

    I should be more specific I realized:


    We would like to send multiple interrupts on External Pin 4, sending various data each time.  I am talking on the order of 1000's of interrupts with a spacing of about 1000 ns each interrupt.

  • in reply to Loren Caler
    TI__Guru*** 125430 points

    Loren,

    I don't know the answer to your question, but I do have some questions/suggestions to make.

    I have a couple concerns related to what you're proposing:

    1. Interrupt overhead.  Once you start having interrupts occurring every 1us the overhead of performing a context save and restore for every single interrupt starts to become a substantial amount of your CPU utilization.
    2. CFG bus latency.  Accessing GPIO register is actually a completely different path than accessing RAM.  It runs as at a slower clock speed, has delays for crossing clock boundaries, and stalls the CPU since it's a noncacheable region.

    I suggest using real hardware to setup a test where you use a Timer interrupt setup for a 1us time period and then inside the ISR perform some reads and/or writes of the GPIO just to simulate the kind of access pattern you would expect in your real application.  I expect you're going to see that takes up a huge amount of CPU.  Depending on how much CPU you're already using today that might not be feasible at all.  But better to know that now if that is the case!

    Brad