Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hi Simon,

The architecture used for these processors is the "davinci" architecture. The information you want to look at is primarily in the arch/arm/mach-davinci folder, though some of the drivers (like spi and i2c) are located in drivers/spi/davinci-spi.c and drivers/i2c/...i2c_davinci.c.

The MityDSP-L138 and MityARM-1808 are based on the OMAP-L138 and ARM AM1808. TI had originally named the OMAP-L138 the "da850", so code in the arch/arm/mach-davinci directory pertaining to the da850 and the da8xx platforms in addition to the board-mityomapl138.c will be of particular interest.

There is support for hardware timers and interrupt handling, at the driver level.

Squeezing a 10-20us refresh rate is possible, but it will definitely require writing a linux kernel module (ISR's may only be written at the kernel level) to accomplish that rate. May I ask what you trying to do? Often for synchronization at these rates, we leverage the FPGA (in modules including the FPGA) to provide synchronous ADC sampling or DAC waveform generation as well as provide FIFOs to make the CPU less latency bound.

-Mike

Hey Mike,

Thanks for the info.

Here is what I need to do.

I have 4 different work blocks doing some stuff and sharing some stuff

First block
Must fit into 20uS.
In this time, it must
- read 3 measures over SPI
- Do some computations on the values read
- Toggle 4 GPIO bits that goes on other electrical components

Second block
Must fit into 200uS
Must
- read 3 mearures over SPI
- write 2 things over SPI
- Do some computations
- Toggle 8 GPIO bits

Third block
This one is mostly for debugging. I want to send some information over a UART to my computer at a rate of 500ms. It basically just output some logs...

Fourth block
It's used for communication between mitydsp boards over SPI. Let's say it like this.
Must fit into 200uS.
Must read 20 SPI transfers
Must write 20 SPI transfers

At a high level, we could see those blocks as threads sharing information between each other through shared memory or something like that. What do you think about that? Feel free to give me all your thoughts

Thank you very much!

any thoughts...?

Well,

I suspect you will need to write driver code to meet your 20 usec timing block. IMHO (and I'm not an expert), if you try to route an IRQ from the kernel all the way up to user space, you'll chew up a lot of your timeline working through context setups. Also, if you are planning to use the same SPI device (with different chip selects, etc.) to accomplish all of your blocks, it might be dicey. If you are going to use both SPI1 and SPI0, then it should be doable. However, it would seem that you will need to likely run multiple threads and leverage shared memory to pull all of the information together as you suggest.

I would advise using the latest SPI drivers being ported by Sekhar Nori (I can refer you to a link if you need, it's on the linux-davinci mailing list archives if you look around there) so that you might use triggered DMA's for reading/writing the SPI. In fact, if you can use the external SPI triggering mode, all the better.

To be honest, SPI interfaces aren't my first choice for analog acquisition if you have tight timelines. If you are reading a 24 bit word out of a SPI device running at 25 MHz, you've lost almost 1 usec just getting the data out of the device. This is why we (at critical link) often use the FPGA based modules to interface to parallel data acquisition circuits and then FIFO the data for either uPP access or EMIFA access. It also allows for controlled synchronous sampling of different ADC's or DAC's (you can route triggers any way you like), and simplifies your software (ADC data can be just a register read function).

I'm afraid not going to be able to be much more help than that without actually thinking about / looking at some sort of hardware design and timeline. Seems like your goals are certainly achievable. Good luck!

-Mike

Hey Mike,

Thanks for the feedback. I will discuss your ideas with my hardware partner. Could you send me a link about the new spi driver?

Thanks!

Hi Simon -

I realize you are trying to use an AM1808 module, but using an OMAP-L138 and using the DSP for this quick turnaround might be an easier, and possibly more reliable, solution.

Is there a particular reason for focusing on the ARM only module?

Thanks,
Tom

Hey Tom,

The reason I was focusing on the AM1808 is because at first it was the chip we wanted to work with. The only thing is when we ordered a mity card from you, you only had ones with the OMAP, so we were trying to avoid using it. Now that you point the DSP side out, it just had us wonder, why aren't we using it So, I need to talk with my colleague (which I think you spoke to (Maxime) ) and it may be our way out.

Thanks a lot!

Ok so we are probably going to use the DSP for some stuff and keep the ARM for higher level processing... From what I saw on the wiki, there's no information about how to use the DSP side of the OMAP. I guess I need to usr CCS with a JTAG emulator (XDS510 in my case)?

Hi again

I was wondering, where can I found documentation about which hardware timers are already used by the linux OS on the ARM side. I just want to know which one I can still use on the DSP side without screwing the linux arm.

Thanks!