Given this limitation of the Cavium CPU, the fact that Linux support for it
seems poor and no EABI support, why choosing this CPU then? I didn't expect to
have to tweak the drivers provided by TS to make our application work.
I don't think our application as being that much IO intensive. For now, we have
minimal sdcard access and about 150 CAN messages per 500ms and we already
encounter problems. Throw in some more intensive sdcard access (which we will
eventually have to do), some RS232 communication and some GPIO and I bet you
get something barely functional...
Too bad because I really like the features of the TS-7552. The specs and
functionalities are an almost perfect match for our application. It's very good
for us to be able to boot a full Linux distro in 13 sec (from our customized
sdcad image). Power consumption is really critical for us and sub 2W controller
with CAN bus and Ethernet with decent processing power are hard to find.
However, this buslock thing is a show stopper right now.
--- In Michael Schmidt <> wrote:
>
> On 7/13/2010 7:00 AM, Jean-Francois wrote:
> >
> >
> >
> > I just confirmed now why they shouldn't have gone this way and going
> > everything through the CPLD...
> >
> > I was struggling to make CAN communication run smoothly. In our
> > application, we have nearly 150 CAN messages on the bus every 500ms
> > (TS7552 sends 26 and receives 121). I had problems because the other
> > controllers on the network were regularly reporting communication
> > timeouts. I started to time everything and found that sometimes
> > buslock() calls can stall for several hundreds milliseconds... All
> > hardware interfaces are going through the CPLD and use buslock(). For a
> > test, I copied a file to the SDcard while our software is running and it
> > made CAN communication completely erratic. Thats really not good...
> > Design issue?
>
> It's a limitation of the Cavium CPU, which uses SPI for its peripheral
> bus. Since access to this bus is not atomic a locking mechanism is
> required. The SD card driver in particular bursts something like 256
> reads or writes at a time in between preemption points for efficiency.
> You might want to look at the source code for sdctl to tweak the
> preemption points for a lower burst length and for canctl to try to send
> more packets every time it gets the bus. (The CAN controller has a 128
> packet Rx FIFO but only has 1 packet pending to Tx at a time)
>
> ______ Best Regards,
> |__ __/ Michael Schmidt
> || Software Engineer
> ||echnologic Systems (EmbeddedARM.com)
> || (480) 16525 East Laser Drive
> |/ 837-5200 Fountain Hills, AZ 85268
> http://oz.embeddedarm.com/~michael
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|