Hi,
I am sure the correct answer is to use a device driver and hw timer interrupts. There is sample code in the files section for doing this with a ts7200 style processor (ep9315). You have a cavium processor, and I don't know what the status of getting data sheets for that is, as far as I recall they are kind of closed. Good luck.
Mike
On Tue, Jun 22, 2010 at 10:43 PM, ignac.kolenko
<m("yahoo.com","ignac.kolenko");" target="_blank" href="/mc/compose?to=">ignac.kolenko@ yahoo.com> wrote:
Hi everyone, new to this group.
I'm working with the TS7500 and for a project I need to be able to poll and/or manipulate the digital I/O lines at least 1000 times a second (perhaps faster), and store the state of digital I/O lines in shared memory for other tasks to eventually read from. The project I'm working on involves a number of digital I/O signals wired to external sensors whose digital levels can change as often as 1000 times a second, perhaps slightly more often in worst case scenario. I figure a 1kHz sampling rate should be easy to achieve on a 250Mhz processor running a lean OS like Linux.
So to get familiar with the TS7500, I figured i'd do a few tests with some of the sample code found on the FTP site, namely the LED control app. I can flash the LEDs at about 4 or 5 times a second accurately (usleep() of 250000), but going faster than that generates less accurate timing.
I would have figured a stripped down embedded kernel would allow for fairly accurate 1ms or 500usec delays between polls or access to hardware.
I figure the overhead comes in the form of the sbus.c routines (locking, port access, unlocking). But doing the lock/unlock outside of the test loop (running the flashing routine for 10 seconds) yields similar results than calling the lock/unlock within the loop. The actual peek/poke code doesn't seem overly cumbersome compared to the lock/unlock (semaphore control), so i think i'll rule out this code as causing timing issues.
Is usleep() a problem? Is there a better way to do sub second delay timing?
Is there a simpler way to talk to the DIO lines and I/O ports that doesn't require the overhead of the sbus.c routines? Can any of the DIO lines generate an interrupt?? Would that allow for 1kHz or better sampling rate?
Should I be investigating writing a driver to manage access to and polling of digital I/O?
I noticed as well in the TS7500 resource page of embeddedarm. com that it has a link to a PDF for the TS7200, and the sample DIO access code in there is vastly different. Is that because the TS7200 is a much simpler embedded Linux environment? ? Is there a similar document for the TS7500??
Any thoughts and direction here would be very welcome.
Thank you all in advance for any assistance you can provide!
-ig