LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Blackfin programmation

Hello,

 

I would like to program a data acquisition card with LabView (250kS/s simultaneously on 80 channels) and wondered if it was possible to program such a device on a blackfin processor rather than a common FPGA. I could then use the Labview embedded module for blackfins to make it easier.

 

The question might be stupid but I don't know much about this subject. Some people in my team are much more aware of that kind of problem but we wanted to check.

 

Do please be indulgent Smiley Happy

0 Kudos
Message 1 of 11
(2,762 Views)

Hi There,

 

What specific blackfin processor were you looking at using?  I would suggest staying with something more along the lines of a FPGA or a PXI chassis with a Real-Time Controller to handle that amount of simultaneous data.  You will also have to consider which data acquisition cards you are using and how they interface with your controller/processor.  I would suggest using a Compact RIO or PXI system with simultaneous data acquisition cards for this application.

 

Programming on the cRIO or PXI system will be very similar to programming LabVIEW on a Windows/Linux/Mac machine.

Scott A
SSP Product Manager
National Instruments
0 Kudos
Message 2 of 11
(2,737 Views)

Hello,

 

Thank you for your answer but I think that you misunderstood my question. You wrote: "You will also have to consider which data acquisition cards you are using".

 

Actually, I want to program the data acquisition card myself, so that I don't need to connect it to a computer, and consequently increase the data treatment speed. Also, I want to make my data acquisition card out of a FPGA or a Blackfin processor if it is possible.

 

This is what I am asking: Is it theoretically possible to make a data acquisition card out of a blackfin processor?

 

 

0 Kudos
Message 3 of 11
(2,718 Views)

I think it is theoretically possible, but I wouldn't attempt to build it in practice. What development team, size and timeframe are you prepared to throw at this? A one man show will never produce a working system, unless you are VERY proficient in hardware system design using VHDL and embedded C programmming. Integrating it with LabVIEW for Blackfin (a discontinued product by the way) is your smallest problem, although certainly also a real challenge.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 11
(2,715 Views)

OK,

 

Thank you for your answer, we would be around 10 students (in physics and informatics engineering) working on this project.

 

Compared to programming a data acquisition card on a FPGA, would it much more difficult?

0 Kudos
Message 5 of 11
(2,702 Views)

I have no idea about the level of university you are in and specialismes you and the other students already have acquired, but I think it is a very ambitious project.

Thinking of my own time at the university and the final diploma work we did there, I would say it's an interesting project to attempt to learn about things like hardware system design, software programming and teamwork organization, but there is a small chance that a working prototype emerges after the few months such a final diploma work usually takes. That does not have to be a problem however, it's not the final product that counts here primarily, but the experiences you make during the project and the ability to document what you did, and why. But it can be a discouraging thought when the end of the period approaches and you see that there is no real chance to get the whole thing working. To not spend all the time in trying to make it work, but instead do the necessary paper writing is not an easy thing for most engineers.

 

And coordinating 10 students in such a project certainly won't make the team 5 times as efficient than if it was done by 2 students Smiley Wink

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 11
(2,694 Views)

Thank you again rolfk for your precious advices, I'll consider them very seriously when the time of determining what to do.

 

Actually, programming our data acquisition card is only a part (a big one of course) of a more important project.

 

For the moment, I'm still in my investigation period. Could you advise me on the choice of the blackfin model that we should use or give me some hints (what are the parameters I should take into account) to make the best choice? We need 80 channels with 250kS/s on 12bits (or more).

 

By the way, how can I determine if I can reach or not the performance I mentioned previously (80 channels with 250kS/s on 12bits) having only the specs of a blackfin processor such as the ones available at this adress: http://www.analog.com/static/imported-files/data_sheets/ADSP-BF539_BF539F.pdf

This is a crucial point for me.

0 Kudos
Message 7 of 11
(2,682 Views)

I can't help you with the Blackfin processor. My limited experience is limited to ARM type CPUs and they would have serious trouble to do anything even close to what you want to do, unless you implement the entire ADC/DAC part in dedicated hardware.

But that is not the only problem. Usually you don't just want to acquire data, but you want to do something with it too. So where and how do you want to process the data? Does it need to be transported into the PC for further processing? In that case you will have to look at the transportation channel too. Your data can be up to 30MB/s raw data and more likely 40 to 50 MB/s real data, with signaling and all. That is not something you can possibly stream over USB or any other of the more common bus systems. Implementing PCIe or USB3 or Firewire however is a challenge in itself that many others have stranded upon before you.

Your project seems to me more and more a huge undertaking, where quite a few sub projects of it would already be more than enough for what a typical diploma work can cover.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 11
(2,675 Views)

I think that we're definitely not going for this option. Do you think it is going to be easier to program our data acquisition card on a FPGA?

0 Kudos
Message 9 of 11
(2,657 Views)

@maggotsBrain wrote:

I think that we're definitely not going for this option. Do you think it is going to be easier to program our data acquisition card on a FPGA?


Not for me Smiley Very Happy My experience with VHDL and similar things is about 0.1%. LabVIEW FPGA won't work either, as they don't have any targets that could remotely handle such requirements with the code they produce. If it is possible to do it with current FPGAs when programmed directly on logic level rather than some higher level such as LabVIEW I wouldn't know. Maybe not all 80 channel on one FPGA but a fraction of them.

Rolf Kalbermatter
My Blog
0 Kudos
Message 10 of 11
(2,649 Views)