truni Posted January 3, 2016 Report Share Posted January 3, 2016 Hi AllI am currently running through the beaglebone tutorials online as well as completing the Derek Molloy "exploring beaglebone" book.I want to create a project over the next year or so which will have the following requirements:1. Connectivity to a PC, via wifi and Ethernet/USB2. Possible lcd panel integration (tbc)3. Expansion (maybe more than one real time "peripheral" connected into "slots" on the main pcb4. Real time data acquisitionMy thoughts are to use the beaglebone as the "hub", where the data from the real time units are sent. The beaglebone would take advantage of its linux os to provide high level user interface programming and connection to the outside world.The FPGA would be used to sample the input signals (probably via adcs), perform some signal processing and pass the "computed results" over to the main "hub"Am I thinking correctly here? Would the fpga be a good solution to the real time "sampling" and signal processing?As an example, imagine wanting to sample an adc at 500ks/s (50hz waveform) and transfer the rms value to the main PC every 20ms.... So the transfer rate to the main hub would be low whilst he fpga handled the heave maths...Am I on the right track? If so I will continue on this route of research :-)And of course... Buy a Papilio!Thanks!! Quote Link to comment Share on other sites More sharing options...
johnbeetem Posted January 4, 2016 Report Share Posted January 4, 2016 While I'm a huge fan of FPGAs, what you want to do might be an excellent fit for the BeagleBone's Programmable Real-time Unit (PRU) Sub-System (PRUSS). In addition to its ARM Cortex-A8 BeagleBone's SoC has two 200 MHz RISC processors for real-time I/O and signal conditioning. Here's a good starting point: http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone/blog/2013/08/04/bbb--high-speed-data-acquisition-and-web-based-ui Quote Link to comment Share on other sites More sharing options...
truni Posted January 4, 2016 Author Report Share Posted January 4, 2016 Hi john Thanks for the response Yes I have considered the PRUs, but I thought this would limit be with regards to expansion. If I can install expansion slots on the main PCB which all run on one bus of some description, then this will help with expand ability. What do you think? I could run an SPI bus or something similar, or I2C... I have not crunched the numbers yet but as the raw samples won't be on the bus (only computed results at max 1ms intervals) then I think even an I2C bus will be fine.. Interested to hear your comments.. Thanks! Quote Link to comment Share on other sites More sharing options...
james1095 Posted January 4, 2016 Report Share Posted January 4, 2016 My friend built a power monitor using a cheap AVR microcontroller with the internal ADC sampling the AC line and producing a graph of the current waveform. It also calculates the RMS value in real time and that's a ATMEGA88 running at 8MHz. You could use a FPGA, but that's sort of like using a sledge hammer to drive a small nail to hang a picture. Quote Link to comment Share on other sites More sharing options...
truni Posted January 4, 2016 Author Report Share Posted January 4, 2016 Hi James You want to see the walls in my house, smashed to bits;) That is true, but I want to ramp up the sample rate for maximum bandwidth.... Quote Link to comment Share on other sites More sharing options...
Jack Gassett Posted January 4, 2016 Report Share Posted January 4, 2016 Hello Truni, Here is my take on this, use the FPGA if you need to capture high speed signals or you want a platform that you can always overcome limitations with. FPGA's are flexible enough to solve any type of problem, but it is going to be more difficult to do with an FPGA. If you can find an easier solution with another platform that solves all of your problems then I would go with that option. Now, having potentially pointed you to another platform for this project you are working on, which is the right thing to do, let me make the case for learning about FPGAs too. I think everyone in this forum can attest to the amazing feeling of satisfaction you get when you build a circuit on your computer that comes to life on an FPGA board and does something you couldn't do any other way. In short, it is very worthwhile to learn FPGA technology because at some point it is going to enable you to do something you can not do with any other platform... Jack. Quote Link to comment Share on other sites More sharing options...
truni Posted January 4, 2016 Author Report Share Posted January 4, 2016 Hi Jack I appreciate the response, thank you for the advice. I will continue on my quest to master linux (which 4 weeks ago I knew very little about) I will make sure I know what is possible with the PRU's before I do anything else. I want to simultaneously sample from a number of ADCs, I do not want to "mux" the adcs, I am worried that I will run out of processing power with the beaglebone PRU's... But that is a naive assumption as I do not know enough about them.... More reading and learning about the limitations of the beaglebone before committing. Out of interest, how would you interface the FPGA to the beaglebone? I2C? SPI? Direct memory? Sorry for the stupid questions... Quote Link to comment Share on other sites More sharing options...
alvieboy Posted January 4, 2016 Report Share Posted January 4, 2016 "Out of interest, how would you interface the FPGA to the beaglebone?"Preferrably SPI."I want to simultaneously sample from a number of ADCs, I do not want to "mux" the adcs"Why not ? your sampling rate is quite small. I happen to work on a system that does sampling of more than 100 analogue signals each 12-bit, with an average sample rate of 400Hz each, with a single ADC. All done in software with a microcontroller much much slower than a beaglebone, but a real-time system nonetheless. Analog muxers are cheaper than ADCs. You can use the FPGA to control all this and present all ADC data on SPI bus (either master or slave) to main CPU in case you are worried. You can also do RMS computations on FPGA (as well as other goodies). Alvie Quote Link to comment Share on other sites More sharing options...
johnbeetem Posted January 4, 2016 Report Share Posted January 4, 2016 Out of interest, how would you interface the FPGA to the beaglebone? I2C? SPI? Direct memory? For talking to a Papilio I agree with Alvie that SPI is the way to go. While I suppose it's bad manners to mention other FPGA boards here, you might want to check out the ValentF(x) LOGI-Bone, which is a Spartan-6 LX9 FPGA board that plugs directly into a BeagleBone. This gives you the option of treating the FPGA as a 16-bit wide memory using BeagleBone's General-Purpose Memory Controller (GPMC). You also have SPI and I2C. LOGI-Bone is a nice solution provided you don't have to separate the boards too often since it's a pain to pry those connectors apart. Quote Link to comment Share on other sites More sharing options...
alvieboy Posted January 4, 2016 Report Share Posted January 4, 2016 @johnbeethem: heh, just tell me if you want a wider bus (quad-spi, 8-bit spi). Just make it synchronous. Is GPMC synchronous ?Asynchronous [parallel] buses are long dead. It's faster and more reliable to use SPI on let's say 80Mhz with a quad-bus (yielding 40MBit/s) than using plain asynch stuff.i2C is so slow no one uses it unless a shared bus is required (cause CAN is still encumbered by Bosch's patents). Quote Link to comment Share on other sites More sharing options...
truni Posted January 4, 2016 Author Report Share Posted January 4, 2016 "Out of interest, how would you interface the FPGA to the beaglebone?"Preferrably SPI."I want to simultaneously sample from a number of ADCs, I do not want to "mux" the adcs"Why not ? your sampling rate is quite small. I happen to work on a system that does sampling of more than 100 analogue signals each 12-bit, with an average sample rate of 400Hz each, with a single ADC. All done in software with a microcontroller much much slower than a beaglebone, but a real-time system nonetheless. Analog muxers are cheaper than ADCs. You can use the FPGA to control all this and present all ADC data on SPI bus (either master or slave) to main CPU in case you are worried. You can also do RMS computations on FPGA (as well as other goodies). AlvieThanks for the advice, I may end up sampling at 1MHz per channel, do you consider that low frequency?The data will then be transferred at around 1kHz (max data transfer of around 100 bytes or so per transfer)As you can imagine, at this stage of my learning curve I have millions of questions and lots of research to make.Good job I have an understanding wife!!!For this project there aren't any serious cost saving requirements so I figured I would use sledgehammers ;-)Thanks for all advice... Quote Link to comment Share on other sites More sharing options...
truni Posted January 4, 2016 Author Report Share Posted January 4, 2016 For talking to a Papilio I agree with Alvie that SPI is the way to go. While I suppose it's bad manners to mention other FPGA boards here, you might want to check out the ValentF(x) LOGI-Bone, which is a Spartan-6 LX9 FPGA board that plugs directly into a BeagleBone. This gives you the option of treating the FPGA as a 16-bit wide memory using BeagleBone's General-Purpose Memory Controller (GPMC). You also have SPI and I2C. LOGI-Bone is a nice solution provided you don't have to separate the boards too often since it's a pain to pry those connectors apart.Hi JohnI have considered the Logibone but heard that you guys on this forum are more help and friendly ;-)I have certainly found that to be the case here :-)The GPMC is something I will certainly look into!Thanks! Quote Link to comment Share on other sites More sharing options...
johnbeetem Posted January 4, 2016 Report Share Posted January 4, 2016 Just make it synchronous. Is GPMC synchronous ?Asynchronous [parallel] buses are long dead. It's faster and more reliable to use SPI on let's say 80Mhz with a quad-bus (yielding 40MB/s) than using plain asynch stuff.GPMC can probably be used synchronously, but I suspect most people use it to talk to async devices such as SRAM and NOR Flash. If async buses are dead, I guess it was a bad idea to put asynchronous SRAM on Papilio DUO, eh? Seriously, an async parallel bus is still a good way to talk to lots of peripherals and has the advantage that you don't need a device driver -- you can just use mmap(). This can be an important feature for a Linux newbie who doesn't want to become a device driver guru. The Spartan-6 LX9 has lots of dual-port RAM, so an effective way to do data acquisition is to store inbound data to one side of a dual-port RAM and have the other side talk to the CPU. "Long dead" reminds me of an early unix "man" page for assembly language. IIRC, the page read "Assembly language is dead. Necrophilia will be punished." Funny, you don't see that page any more if you enter "man as" Quote Link to comment Share on other sites More sharing options...
mkarlsson Posted January 5, 2016 Report Share Posted January 5, 2016 I happen to work on a system that does sampling of more than 100 analogue signals each 12-bit, with an average sample rate of 400Hz each, with a single ADC. All done in software with a microcontroller much much slower than a beaglebone, but a real-time system nonetheless. And I happen to work on a system that samples up to 1024 analog signals each 16-bit at 30 kHz sampling rate using up to 16 ADCs, each with a 64 ch mux All done with an Spartan6 LX16 and streaming the data out using a TMDS link (i.e. like HDMI but just clock and data) at 78.6 MB/s. using regular HDMI connectors and cables. For something like this you definitely need an FPGA. Here is a picture of a 640 ch system. FPGA board to the right with micro-HDMI connector for power and data, 5 ADC boards in the middle, each with 2 ADCs (i.e. 128 ch each), and LVDS terminator board to the left. The ADCs are connected to the FPGA using SPI with LVDS signaling (CS, CLK, MOSI, 16x MISO). 1 Quote Link to comment Share on other sites More sharing options...
Felix Posted January 7, 2016 Report Share Posted January 7, 2016 that is very sexy. makes me want one Quote Link to comment Share on other sites More sharing options...
mkarlsson Posted January 7, 2016 Report Share Posted January 7, 2016 For more info see:https://www.llnl.gov/news/nih-taps-lab-develop-sophisticated-electrode-array-system-monitor-brain-activity The NIH project is a collaboration between LLNL's Neural Technology Group; the laboratory of Loren Frank at University of California, San Francisco (UCSF); Intan Technology; and SpikeGadgets. Housed at the Center for Bioengineering, the Neural Technology Group will work with UCSF researchers to design and build electrode arrays that can record hundreds to thousands of brain cells simultaneously. Their goal is to develop 1,000-plus channel arrays that can eventually be expanded to 10,000 channels. These arrays will use new microchips designed at Intan and will send data to a system developed at SpikeGadgets. UCSF will coordinate these efforts and test the technologies. The arrays will penetrate multiple regions of the brain without interfering with normal functions during the experiments, allowing for detailed studies of brain circuits that underlie behavior. "This collaboration combines the engineering talent of LLNL with UCSF's expertise in neural recording and modulation systems, and the design and programming skills of Intan and SpikeGadgets," Frank said. "The result will be a system that will help us understand how different brain areas communicate and carry out complex mental functions." 1 Quote Link to comment Share on other sites More sharing options...
Felix Posted January 7, 2016 Report Share Posted January 7, 2016 thanks will check it out Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.