Logi-Pi board availability?

Is this what you're after?

If so then:

CPC.Farnell Availability

Availability:  2

That is the product I'm looking for, but I was looking on the US site:

http://www.newark.com/logi/logi-pi-2/silicon-manufacturer-xilinx/dp/38Y8590?MER=bn_para_1TP_LastViewed_1

which states: "No Longer Manufactured". The European site says: Available until stock is exhausted

So, is this going to continue to be a product? There's no info on the Valent site to say the current status. I don't want to pursue development on this board if it's not going to be available later.

Is Valent perhaps working on a replacement? An FPGA board for the RPi with a Lattice chip would be sweet...

Thanks for the reply!

You're welcome.

Sorry I can't be of any more help - you're right, the US Newark site does indeed say that.

Is it a viable option to get it shipped from the UK / Europe?

dan luttrell wrote:

 

So, is this going to continue to be a product? There's no info on the Valent site to say the current status. I don't want to pursue development on this board if it's not going to be available later.

 

Is Valent perhaps working on a replacement? An FPGA board for the RPi with a Lattice chip would be sweet...

I don't want to speak for ValentF(x), but it sure looks to me like LOGI-Pi is at end-of-life.

There are lots FPGA boards out there.  Joel Williams has done a remarkable job of maintaining his Cheap FPGA Development Boards site, which has boards from many vendors.  For Lattice iCE40, there's a good list at the bottom of the IceStorm Project home page.

There aren't many boards that plug directly into a RasPi.  There actually is a Lattice iCE40 8K board called icoBoard but it's only available in Germany and costs at least 69 euros.  XESS has a RasPi adapter for their XULA boards but the FPGA board itself is expensive (it's a large FPGA) and you don't get many I/Os.  For a while it looked like XESS was going to have the iCE40-based CAT board but that seems to have fizzled.

For Lattice iCE40 I think your cheapest way to get started is still the iCEstick if you can find a suitable vendor.  Olimex has a nice little board with a 1K part and SRAM for around US$26 at Digi-Key.  However, it doesn't have a programmer.  Lattice iCE40blink boards bring out lots of I/O.

I do FPGAs professionally so I have lots of boards, mostly Xilinx and iCE40.  While I have LOGI-Pi, I rarely use it with a RasPi.  Instead, I program it over JTAG using an Adafruit FT232H breakout board as a cheap USB JTAG dongle.  USB is my favorite way to talk to pretty much any hardware I'm playing with.  Then it doesn't matter which machine I'm using as a host.

What sort of tasks do you have in mind for the FPGA, or to put it another way, if you were using  a Lattice part which one would you go for.

I'm asking with a view to suggesting a Lattice board that might easily interface to a Pi.

MK

dan luttrell wrote:

 

 

So, is this going to continue to be a product?

I recently ran into a product where Farnell says: "no longer manufactured", but Mouser and digikey still have it! On closer inspection the "manufacturer order code" at farnell says it is "version B" and the others now carry "version C" of that same chip. This manufacturer is sometimes a bit dumb in choosing type numbers and this probably caused Farnell not to realize that there simply is "the same chip but a different version".... So the thing to learn from this is: As a manufacturer: do not include the version identifier into the order code.

And another thing to take away from this is to take the "no longer manufactured" from Farnell/newark with a grain of salt....

There are 2 primary tasks: 1) read AquadB outputs of several encoders (these would be A, B, and index pulse buffered down to 3.3V) at speeds up to a few MHz (typically less than this) and generate position data, 2) read image data from a color camera (need R, G, B color planes separately) at perhaps 20 fps.

It looks like the RPi would be a good platform to analyze and record the data once the fpga has it available. I'm thinking the Wolfram Language is appropriate for that task. That's why I'm interested in the RPi with an fpga.

I've been using a National Instruments cRIO and programming in LabView, but there is a serious bottleneck where digital inputs are brought into the fpga. I need another solution. I'm not an fpga programmer but been playing with a small Xilinx board to get a feel for difficulty and issues. It works ok. Appears the Lattice tool chain might be a better long term solution.

John,

Thanks for the info on boards. Very helpful! I've looked at some of these and will search for the others. I'm sure there's an appropriate solution in here somewhere.

It does look like the Logi-Pi is end-of-life, but I'm also finding that vendors don't always update their web sites with the most recent info. Hoping to find someone here who can enlighten us on the status of the ValentF(x) products. Valent hasn't answered my direct inquiries.

Are you planning on using the raspberry pi camera for the "aquire images"? Or the FPGA? As far as I know, modern cameras do not readily ouput "easy" data. There is a lot of processing involved that an image processor on a CPU like the raspberry COULD do, but you need to have the software. That software is available (closed source) when you use the raspberry pi camera.

Also, acquiring images into an FPGA is tricky: The FPGA rarely has enough memory to hold a whole frame, so you need the FPGA to store the data externally. And then you need a fast datachannel between the raspberry and the FPGA. Not sure what is a convenient option.

Consider for example SPI. You can run that at maybe 18MHz. That would mean 18 Mbits per second at full-blast. Now consider your 20FPS. At 24bpp, 1920x1080@20FPS, that is 995 Mbits per second.... There is a gap here....

Not your average "my first FPGA project"!

Fortunately, this project doesn't require the entire image for what we need to do initially - only about 4 or 5 lines from each color plane. That makes the problem one of manipulating (and storing) arrays instead of full image matrices. One approach that may work is to use the RPi for capturing images from a camera and then feed the needed arrays to the fpga for fast processing (filtering, peak detection and perhaps a few other things). The result would be just a few numbers that represent the key metrics we are after. That might also be done on the RPi but at a slower speed. That might be ok here in the beginning. It seems to me an RPi and fpga combo gives us options to try things a couple of different ways as we learn what's really going to be needed.

We actually learned a lot about what's needed for the image processing by using the LabView vision tools so we're not starting completely from scratch.

Yeah, this is probably not a normal starter project, but average is boring.

Fortunately, this project doesn't require the entire image for what we need to do initially - only about 4 or 5 lines from each color plane. That makes the problem one of manipulating (and storing) arrays instead of full image matrices. One approach that may work is to use the RPi for capturing images from a camera and then feed the needed arrays to the fpga for fast processing (filtering, peak detection and perhaps a few other things). The result would be just a few numbers that represent the key metrics we are after. That might also be done on the RPi but at a slower speed. That might be ok here in the beginning. It seems to me an RPi and fpga combo gives us options to try things a couple of different ways as we learn what's really going to be needed.

We actually learned a lot about what's needed for the image processing by using the LabView vision tools so we're not starting completely from scratch.

Yeah, this is probably not a normal starter project, but average is boring.

dan luttrell wrote:

 

. One approach that may work is to use the RPi for capturing images from a camera and then feed the needed arrays to the fpga for fast processing (filtering, peak detection and perhaps a few other things).

IMHO, if you have a 50ms repetition rate, "filtering, finding the peak and perhaps a few other things" is something you can and should do in software. Bouncing the data back and forth to the FPGA is going to be a hassle, and probably not any faster. The FPGA will be able to do these things in say a microsecond, getting the data there and back is likely to cost WAY more... But you're waiting 50 miliseconds for the next frame anyway. I'd say that taking a milisecond to do things in software should also work. But I don't have your complete project parameters....

What you COULD consider is to get a DE-NANO-SOC. Dual core ARM running Linux for the high-level stuff, and... All that runs on the FPGA. The FPGA has access to main memory, the FPGA has private memory, and you could add a special function peripheral to the ARM to do exactly what you need. I think there is also a camera module for the DE- series.

Oh. One thing I forgot to say before: Handling an encoder signal at several MHz is not really a problem. A $2 STM32 can do that. But is your encoder that fast? I've only looked at one datasheet so far, and it mentioned a maximum frequency of 100kHz. So double check that you have encoders that are faster than mine... :-)

The encoders are indeed that fast, actually faster. Each individual signal (A, /A, B, /B) can be up to 10 MHz from the encoder read-head. It uses the RS422 signal format. These are buffered with a receiver chip that generates a single 3.3V signal for each channel.

These are very high resolution encoders with single nanometer resolution. It doesn't take a high speed motion to generate a lot of pulses. For example:

http://www.mgscale.com/mgs/language/english/product/BH25.html

VIONiCplus incremental encoder system with RSLM linear scale

The tightly integrated DE-NANO-SOC looks interesting. It's always worked out well to have more speed and computing capability than initially thought. Something always comes up later to push the capabilities beyond what we ever thought we would need. I have to keep reminding myself of this.

They might be exaggerating when they claim a resolution of 0.3 the size of a hydrogen atom.

Actually, that resolution is real, and it is sometimes interpolated down to less than that. Ultra-precision motion systems can make coordinated multi-axis moves with following errors in the single-digit nanometer range (velocities are fairly slow). The fine resolution is especially important for deriving velocity and acceleration. Current control systems use an ASIC to read and interpolate these encoders. I'm looking for flexibility beyond what the ASIC offers.