As I stated before the main data flow would NOT go through the FPGA
All proposals would add cost and complexity. Mine would add cost incrementally, not by orders of magnitude.
So again please stop steeping on my post. What goes on between the original requester and me is between us and none of your business.
From: Mike Ingle <> To:
Sent: Sunday, July 31, 2011 1:30 PM Subject: Re: [ts-7000] Re: Using TS-7500 SBC to collect and transfer camera data over TCP/IP
Hi,
I am sorry you think I am dumping on your posts. Not my intent. What i was trying to do was point out that the hardware interface between the cpu and fpga on the ts7500 seemed marginal at best for this task, and to promote discussion, not attack you. This is starting to feel personal, and maybe I started it with my over enthusiastic response regarding DSP feasability. I have no doubt that you could program the DMA engine, and write the linux driver to get the data. But you are still stuck with a nice linux controller which is starved in both directions. The FPGA can't serve the data fast enough, and the ethernet can't send it up fast enough either. Your proposal to add external buffering could solve the problem, but adds more cost and complexity. I think it is fair to the original requestor to make these things clear.
Again sorry for
stepping on your toes.
Best regards Mike On Jul 31, 2011, at 9:34 AM, walter marvin wrote:
Sir,
If you had read my previous posts you would see that what I propose is DMA to the Cavium, with the FPGA providing high speed timing and control. The entry point into the hardware would probably be a daughter board, replacing the processor main memory. My 30 years system software experience should make the required driver doable.
My cost arguments about standalone MP projects stand
Sir, I have answered your objections 3 times now. Please stop dumping on my
posts
thanks
]Walter
From: Mike Ingle <m("gmail.com","finndmike62");" target="_blank" href="">> To: m("yahoogroups.com","ts-7000");" target="_blank" href=""> Sent: Sunday, July 31, 2011 12:04 PM Subject: Re: [ts-7000] Re: Using TS-7500 SBC to collect and transfer camera
data over TCP/IP
Actually, i have a lot of experience coming to group decisions about hardware. Having used the ts7300 on a past project, I found that technologics decisions regarding cpu to fpga interface left much to be desired. Have you looked at the ts7500 fpga interface? I doubt that you can move data between the cpu and fpga at 25Mbytes/s. and, there is no external buffer memory on the fpga, so only small internal buffers. What value does the ts7500 have if all you want is the data in a host computer? I say this as someone who generally prefers to work in embedded linux, and move data via ethernet. I also have been working at high data rates (65-500Msamples/s 12-14 bit ADCs) for over 10years.
To get the data into an embedded controllers memory would require external hardware on the TS-7500, if the interfaces will even get the data to a DMA engine that could move the data. The
onboard FPGA at first glance appears not to have adequate connectivity, but I could be convinced I am wrong. The FPGA on the TS-7500 definitely lacks external buffer memory, which would be required if the cpu-fpga interface isn't up to the 25Mbytes/s.
Data can be gotten into embedded controller memory using a "camera interfacce" found on some controllers. There are obviously a lot of ways to do it, but I have to ask why? If manipulating the data in an embedded controller is required, then by all means get the data there. If raw data at the host computer is required, then find the cheapest easiest way to get it there. Every separate development task adds complexity, So if you need to use an fpga to buffer the data anyway, then why add linux to the problem?
Why? One reason might be that it is an absolute requirement that the camera data come to
the host over ethernet, then you need to find a better solution than the ts7500, which I don't think is up to the task. The beagle board xm is.
Best regards Mike
On Jul 31, 2011, at 8:27 AM, walter marvin wrote:
A Beagle board is twice the cost of the TS-7500, and you still have to develop drivers
Some high end microprocessor project is also a solution, but so is a pretty standard PC and data capture card.
These solutions have higher hardware cost and or development cost than adding Linux drivers to the TS-7500, aside for not really answering the original question. Some people will only accept their solution to a problem I guess.
From: mike ingle
<m("gmail.com","finndmike62");" target="_blank" href="">> To: m("yahoogroups.com","ts-7000");" target="_blank" href=""> Sent: Sunday, July 31, 2011 10:39 AM Subject: Re: [ts-7000] Re: Using TS-7500 SBC to collect and transfer camera data over TCP/IP
Assumption: You must get your data into a host computer.
You could do it with the beagle board or beagle board xm. The xm has onboard ethernet. You will have to program the capera port to dma into main memory. the xm supports 148Mhz 12 bit camera interface. This would not be how I skinned this cat. You will spend a lot of time on device drivers and a lot f very difficult to debug software. I am sure I could do it this way though. if I was building a product, and cost was a major issue, then using the ti omap 3530 would be under serious consideration, as the host and acquisition computer.
However if getting the data into host computer memory is my main goal, then I would go with:
It comes with the necessary libraries to move the data over USB to the host, and has the needed buffer memory on the FPGA side. Basically, I would divide my SDRAM into "n" buffers each holding 1 frame of data, I would then create a simple state machine to move a buffer at a time over usb to the host. They provide windows libraries to access the usb data. Most of you work would be in FPGA space. it isn't that hard, and there are examples around.
Regards Mike
On Jul 30, 2011, at 2:16 PM, walter marvin wrote:
summary of methods that would work:
1) external hardware that would capture, say a 25 MB frame 2) TS7500 dma kernel based driver supported with FPGA modifications 3) Upgrade to a much more expensive Embedded Linux product supporting a buss based data collection card, and Linux Dma driver
__._,_.___
__,_._,___
|