> Plus they don't run standard i386 Linux distros, so you can't just boot > Debian on the thing like you can with most of the ARM boards. So the > primary reason for picking Intel (binary compatibility and the large x86 > ecosystem) is gone.Well, yes and no. No, you can't run standard distros. Yes, it's still binary compatible so you can run natively compiled programs. Assuming that most people are running development system on x86 Linux (aka PC/laptops), you don't need to cross-compile as in the case for ARM.
Does this exist - dev board with GPIO and fast storage to a SSD or equiv.
Started by ●May 22, 2014
Reply by ●May 23, 20142014-05-23
Reply by ●May 23, 20142014-05-23
> I have a Galileo board, which is the previous Intel idea to the Minnowboard. > It's utterly utterly terrible for IO. There are 2 (yes two) high speed > GPIO lines - the rest are all via I2C expanders, max speed 240Hz.If you look at the block diagram, the 8 GPIOs come out of the controller hub, rather than SPI. So, hopefully it would be high speed, but remains to be verified. http://www.minnowboard.org/technical-features/
Reply by ●May 25, 20142014-05-25
On Friday, May 23, 2014 10:21:46 AM UTC-4, David Brown wrote:> On 23/05/14 14:32, ha2iticare2011@gmail.com wrote: > > > On Friday, May 23, 2014 4:30:11 AM UTC-4, David Brown wrote: > > >> On 22/05/14 23:47, zhaiticare2011@gmail.com wrote: > > >> > > >>> Greetings, > > >> > > >>> I am trying to get a reasonably fast ADC capability to a PC. I have > > >> > > >>> been told that using the USB bus on a PC has latency, preventing the > > >> > > >>> data from being gathered RT. > > >> > > >> > > >> > > >> No, you have not been told that. In all your posts in > > >> > > >> sci.electronics.design, you have been told that USB can have significant > > >> > > >> latency depending on how it is used - but you have also been told how it > > >> > > >> can work fine for the job you describe. USB latency can be an issue if > > >> > > >> you need fast turnaround (read something, then write something new > > >> > > >> depending on what you read) - for continuous reads of an ADC, there is > > >> > > >> no problem. You have also been warned not to connect other devices to > > >> > > >> the same USB bus. > > >> > > >> > > >> > > >> You have also regularly banded around the term "RT", without showing any > > >> > > >> understanding of what "real time" actually means. It does not mean "as > > >> > > >> fast as possible", or "as fast as I can imagine", or "as fast as > > >> > > >> randomly picked numbers that may or may not apply to some parts of the > > >> > > >> system". It /really/ means "within a guaranteed pre-determined time limit". > > >> > > >> > > >> > > >> Getting back to reality, you have been thinking of using one or more > > >> > > >> ADS8344 ADCs. These have a maximum rate of 100 KSps, at 16-bit. A > > >> > > >> 2Mbps (Mb is "Mega bit" - mB is "milli byte") SPI bus will saturate the > > >> > > >> device (even allowing for some overhead). But even if you have 4 of > > >> > > >> these devices on a common SPI bus, an FTDI USB-to-SPI module will handle > > >> > > >> them all. The USB latency will mean a slight delay between starting and > > >> > > >> receiving the first input, but if you do your PC-side software correctly > > >> > > >> then you should be able to get continuous sampling, with data coming in > > >> > > >> at 800 KB/s. > > >> > > >> > > >> > > >>> So I am wondering if an embedded dev board somewhere has fast storage like a SSD > > >> > > >>> that can accumulate data at say, 5-10 mB / s. > > >> > > >> > > >> > > >> Why do you think you need an SSD to get 10 MB/s? (I assume you mean 10 > > >> > > >> MB/s, i.e., 10 Megabyte per second, rather than 10 millibytes per > > >> > > >> second.) Even a decent USB memory stick will cope with that - it is > > >> > > >> certainly not a challenge for a hard disk, an good network, embedded > > >> > > >> NAND, etc. And of course it is 10 times the rate of the ADC (guessing 4 > > >> > > >> chips in parallel). > > >> > > >> > > >> > > >> And this is all pointless unless you can say how much data you need in > > >> > > >> total. > > >> > > >> > > >> > > >> > > >> > > >> You really need to start figuring out what data you actually want to > > >> > > >> collect, and what sampling rates you have there. Once you have > > >> > > >> realistic values there, you can start to work out what you need in order > > >> > > >> to collect and process that data. Randomly picking parts of the chain > > >> > > >> with throughput rates differing by several orders of magnitude will not > > >> > > >> help. > > >> > > >> > > >> > > >> > > >> > > >>> I will also need a way to > > >> > > >>> continually store the data. The only thing I can think of is to put a SSD on > > >> > > >>> the USB port on something like a Pi, but I don't know if this would be fast enough. > > >> > > >> > > >> > > >> You don't know if it will be fast enough, because you don't know what > > >> > > >> "fast enough" is. An SSD on USB 2.0 will peak a bit lower than 60 MBps, > > >> > > >> since that is the limit for USB 2.0. It is the same rate as you will > > >> > > >> get with a hard disk on USB 2.0. > > >> > > >> > > >> > > >>> The camera which uses the GPU evidently records at 30 fps. Also, I see some activity around the "pru" on BBB. > > >> > > >> > > >> > > >> What camera? What GPU? And so what? > > >> > > >> > > >> > > >>> > > >> > > >>> I need to control the ADC with SPI, which could be through the GPIO pins. > > >> > > >> > > >> > > >> You think you need SSD speeds to store the data, but GPIO bit-banging is > > >> > > >> good enough for your SPI bus? > > >> > > >> > > >> > > >>> > > >> > > >>> Now you have to take the above with a grain of salt, since I am SW developer, and > > >> > > >>> just looking for the magic combo of several features: > > >> > > >>> -RT data storage on an SSD or equiv. > > >> > > >>> -SPI control of an ADC > > >> > > >>> -ability to send data to a PC periodically. > > >> > > >>> > > >> > > >>> Anybody ideas appreciated. > > >> > > >>> > > >> > > >> > > >> > > >> Here's the best idea - find yourself a systems designer who can specify > > >> > > >> the system and get a realistic picture of how the parts will fit > > >> > > >> together. You've asked repeatedly about this in s.e.d., and leapt > > >> > > >> between a USB module, PCI express cards, microcontroller boards, and > > >> > > >> high-spec PCs, with corresponding leaps in the data throughput you think > > >> > > >> you need - without ever giving useful concrete information about your > > >> > > >> requirements. And now you have jumped back to the beginning again in c.a.e. > > >> > > >> > > >> > > >> So find someone who knows about hardware, and knows about the task you > > >> > > >> want. Talk it over with them, draw pictures on a whiteboard, and get > > >> > > >> the requirements clear. Once you have that in place, come here and ask > > >> > > >> again - then you can get useful help. > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >>> jb > > >> > > >>> > > > > > > David, > > > Actually, I am getting useful help. And you have been a purveyor of some of > > > that. As I was at pains to point out, and did, the speed of acquisition is > > > open-ended - the spec is "as much as is practical for my situation." IOW, I'd > > > like to do this for less than 1k$ right now. > > > > > > Alhough your manner is one of constant exasperation, you have given me useful > > > leads. :) I have downloaded all the datasheets for the FT4232 dev board - and > > > the MSSE docs. > > > > > > But you must realize, opinion onions have various layers, and I have received > > > much good info here, though most of it is partial and not due to my lack of > > > precsion, IMO. > > > > > > The situation is like SETI - Those guys don't know what BW the signal has they > > > are searching for. In my case, we are going to be sensing medical diagnostic > > > situations, and I can't a priori specify what the data through-put will be, > > > except that the process will reveal it. (See the quote below.) > > > > > > That you stick to your guns about USB latency is a good sign for your FTDI > > > solution, BUT I'm still concerned about the OS handling the data and storing it > > > quickly. > > > > > > John > > > > > > > Pick a speed you like, buy a pre-made data acquisition system, and try > > it out. Once you have sample data there, you can decide whether that > > speed was fast enough, or too slow. /Then/ you can start specifying > > what you want in a /real/ system, and start putting together something > > that will be more cost-effective in quantity and better tuned to the > > final usage. > > > > At the moment, you are guessing a ADCs with a total data rate of 1 MBps, > > an SSD that can handle 300 MBps connected to a USB interface at about 50 > > MBps - you are all over the place. > > > > There is a reason this stuff is called "Research and Development". Do > > the research, then you can start of the development. > > > > And don't guess about OS data handling being "a concern" - either listen > > to people who have told you what they know, or try experiments yourself. > > And note that /you/ are the person who has been insisting on using a PC > > because it has high throughput, high processing speed, and high quality > > OS's and development tools. A $2 microcontroller can handle the speeds > > you have at your current bottleneck - a PC should not have a problem > > storing this data. > > > > (Yes, I am in constant exasperation here. I am trying to help, but this > > is /not/ how you should be developing any sort of project.)Thanks David. I have been surveying a plethora of different ways to bet high data througput with solutions that are PC-centric, SBC-centric, and MCU-centric. I can say there is little consensus about how to do this. What kind of latency do you have for USB data transfers?
Reply by ●May 25, 20142014-05-25
On Friday, May 23, 2014 10:37:13 AM UTC-4, Theo Markettos wrote:> Paul Rubin <no.email@nospam.invalid> wrote: > > > I have no personal experience in this area but a hardware guy warned me > > > recently that complex ARM boards tend to be full of software bugs in the > > > Linux drivers due to corner cases in the specific hardware, etc. He > > > said the Raspberry Pi is pretty reliable because so many were in use > > > that the bugs have mostly been found and fixed by now, and the > > > Beaglebone Black was #2 in number of units deployed, but for the others > > > you should expect to spend some of your development time on Linux kernel > > > debugging. > > > > That is a risk. I'm especially wary of the chips with non-complete public > > datasheets (eg NVIDIA, Allwinner) because you can't just dive in and fix > > things. The kernel engineering of some of the SoCs is patchy too (vendor > > releases sources for 2.6.29 or something, it's a big effort to port to > > modern 3.1x, maybe some of the drivers like graphics or wifi are > > binary-only). > > > > > I don't know if this applies to the Minnowboard that I > > > mentioned, which is an x86 board rather than an ARM, and I think it is > > > designed by Intel rather than by hobbyists. > > > > I have a Galileo board, which is the previous Intel idea to the Minnowboard. > > It's utterly utterly terrible for IO. There are 2 (yes two) high speed > > GPIO lines - the rest are all via I2C expanders, max speed 240Hz. If that's > > not your cup of tea you have USB or PCIe - which are fine, but then they > > dress it up in an Arduino formfactor and pretend it's a microcontroller. > > > > Plus they don't run standard i386 Linux distros, so you can't just boot > > Debian on the thing like you can with most of the ARM boards. So the > > primary reason for picking Intel (binary compatibility and the large x86 > > ecosystem) is gone. > > > > IMO Intel have completely lost the plot as far as embedded goes - if it > > isn't PC architecture they don't know how to handle it. They're currently > > making plans for IoT but they haven't a hope. IMHO anyway. > > > > TheoIs that PCIe on the Intel board fully functional? JB
Reply by ●May 25, 20142014-05-25
On Friday, May 23, 2014 11:14:59 AM UTC-4, edward....@gmail.com wrote:> > I have a Galileo board, which is the previous Intel idea to the Minnowboard. > > > It's utterly utterly terrible for IO. There are 2 (yes two) high speed > > > GPIO lines - the rest are all via I2C expanders, max speed 240Hz. > > > > If you look at the block diagram, the 8 GPIOs come out of the controller hub, rather than SPI. So, hopefully it would be high speed, but remains to be verified. > > > > http://www.minnowboard.org/technical-features/When is this minnow going to surface? jb
Reply by ●May 25, 20142014-05-25
On 5/22/2014 5:47 PM, haiticare2011@gmail.com wrote:> Greetings, > I am trying to get a reasonably fast ADC capability to a PC. I have > been told that using the USB bus on a PC has latency, preventing the > data from being gathered RT. > So I am wondering if an embedded dev board somewhere has fast storage like a SSD > that can accumulate data at say, 5-10 mB / s. I will also need a way to > continually store the data. The only thing I can think of is to put a SSD on > the USB port on something like a Pi, but I don't know if this would be fast enough. > The camera which uses the GPU evidently records at 30 fps. Also, I see some activity around the "pru" on BBB. > > I need to control the ADC with SPI, which could be through the GPIO pins. > > Now you have to take the above with a grain of salt, since I am SW developer, and > just looking for the magic combo of several features: > -RT data storage on an SSD or equiv. > -SPI control of an ADC > -ability to send data to a PC periodically. > > Anybody ideas appreciated.I would design this system by hanging a small SBC on a USB port of a PC. I still have not seen any numbers for the sample rate of the ADC, so I will have to assume your number of 5 MB/s is valid. Certainly you should be able to get that on USB 2.0 which has a max rate of 60 MB/s. If I understand your needs correctly, the SBC can either include the ADC or control the ADC over an SPI interface quite easily. The data can be provided to the PC as a virtual disk drive or as a COM port negating the need for any special drivers. The PC can write the data to any storage device you wish. As part of the protocol for talking to the PC you can include whatever control info you have in mind. Once the data is captured by the SBC handling it no longer needs to be "real time" in that you can use a buffer to provide storage during any delays in communications. As long as the average rate is high enough no data will be lost. The required program on the SBC should be fairly easy to write if the vendor provides adequate examples for USB and I/O. The SBC does not require PC like hardware or even any sort of operating system. It just needs USB and the I/O you want. I would recommend that you look at the chip maker's eval boards. NXP, ST and Atmel are popular ARM manufacturers with a wide variety of eval boards to choose from. A Cortex M3 or M4 should do this job very well. You might also consider the advantages of Ethernet over USB as well. There are plenty of such boards with Ethernet support. :) -- Rick
Reply by ●May 26, 20142014-05-26
On Sunday, May 25, 2014 3:27:55 PM UTC-4, rickman wrote:> On 5/22/2014 5:47 PM, khaitiscare2011@gmail.com wrote: > > > Greetings, > > > I am trying to get a reasonably fast ADC capability to a PC. I have > > > been told that using the USB bus on a PC has latency, preventing the > > > data from being gathered RT. > > > So I am wondering if an embedded dev board somewhere has fast storage like a SSD > > > that can accumulate data at say, 5-10 mB / s. I will also need a way to > > > continually store the data. The only thing I can think of is to put a SSD on > > > the USB port on something like a Pi, but I don't know if this would be fast enough. > > > The camera which uses the GPU evidently records at 30 fps. Also, I see some activity around the "pru" on BBB. > > > > > > I need to control the ADC with SPI, which could be through the GPIO pins. > > > > > > Now you have to take the above with a grain of salt, since I am SW developer, and > > > just looking for the magic combo of several features: > > > -RT data storage on an SSD or equiv. > > > -SPI control of an ADC > > > -ability to send data to a PC periodically. > > > > > > Anybody ideas appreciated. > > > > I would design this system by hanging a small SBC on a USB port of a PC. > > I still have not seen any numbers for the sample rate of the ADC, so I > > will have to assume your number of 5 MB/s is valid. Certainly you > > should be able to get that on USB 2.0 which has a max rate of 60 MB/s. > > > > If I understand your needs correctly, the SBC can either include the ADC > > or control the ADC over an SPI interface quite easily. The data can be > > provided to the PC as a virtual disk drive or as a COM port negating the > > need for any special drivers. The PC can write the data to any storage > > device you wish. As part of the protocol for talking to the PC you can > > include whatever control info you have in mind. > > > > Once the data is captured by the SBC handling it no longer needs to be > > "real time" in that you can use a buffer to provide storage during any > > delays in communications. As long as the average rate is high enough no > > data will be lost. > > > > The required program on the SBC should be fairly easy to write if the > > vendor provides adequate examples for USB and I/O. The SBC does not > > require PC like hardware or even any sort of operating system. It just > > needs USB and the I/O you want. I would recommend that you look at the > > chip maker's eval boards. NXP, ST and Atmel are popular ARM > > manufacturers with a wide variety of eval boards to choose from. A > > Cortex M3 or M4 should do this job very well. You might also consider > > the advantages of Ethernet over USB as well. There are plenty of such > > boards with Ethernet support. :) > > > > -- > > > > RickThanks. OK - That seems reasonable to break up the architecture in a "bare metal" type board which is data-facing plus a PC which is storage-centric. SO I guess what you are saying is that the SBC can send the data to the PC via ethernet or USB, and accumulate it RT in a buffer on the SBC. One problem is that, if you dig into some of the popular SBC systems, like the ARM335x, the actual ability to communicate with the world is pretty crappy. One fellow (shabaz) tried to use USB-ftdi and abandoned it. Next he tried using the PRUSS, a co-processor on the BBB, and eventually got 1-2 mHz speeds. What is lacking is actual solutions by hackers/companies that are published. Until then, I can't play tinker-toys and plug the parts together. (which is what I want of course. Like to avoid 6 month development detours.) As an example, look at the Raspberry Pi camera, a 5 mp Omniview cmos chip. It communicates with the Pi via a coprocessor section and high speed paralell cable. This is the PRU idea, a dedicated coprocessor which runs independently of the SBC mcu. Hijacking this data line is not feasible since internal routines massage the image data to make the image pretty. That's the type of solution which would work on a SBC, and it's what the BBB is "supposed" to do in the PRU. But actual working code is scarce. This will get better over time, prolly. Another solution along this line of thinking is choose a board that is closer to bare metal, yet one that can input, store, and pass on data. No OS. It would need to be able to store data in local RAM and pass it on. The loop I get into with that solution is you are asking a lot of that SBC and wanting it to address memory, etc. without an OS. We worked on a DSP card for the PC that did part of this. So thanks for your input. The "missing link" remains elusive. jb
Reply by ●May 26, 20142014-05-26
In comp.arch.embedded, haiticare2011@gmail.com <haiticare2011@gmail.com> wrote:> Greetings, > I am trying to get a reasonably fast ADC capability to a PC. I have > been told that using the USB bus on a PC has latency, preventing the > data from being gathered RT. > So I am wondering if an embedded dev board somewhere has fast storage like a SSD > that can accumulate data at say, 5-10 mB / s. I will also need a way to > continually store the data. The only thing I can think of is to put a SSD on > the USB port on something like a Pi, but I don't know if this would be fast enough. > The camera which uses the GPU evidently records at 30 fps. Also, I see some activity around the "pru" on BBB. > > I need to control the ADC with SPI, which could be through the GPIO pins. > > Now you have to take the above with a grain of salt, since I am SW developer, and > just looking for the magic combo of several features: > -RT data storage on an SSD or equiv. > -SPI control of an ADC > -ability to send data to a PC periodically. > > Anybody ideas appreciated.I've been following this thread loosley but still have little idea what it is you actually require. Is this for instance for a one off system or do you need to mass produce this? If this is a one off, there are manufacturers that sell aquisition cards for PCs that may do what you want. But these are usually not cheap. National Instruments is one example: http://sine.ni.com/np/app/main/p/bot/no/ap/daq/lang/en/pg/1/sn/n1:7690,n25:device/sb/-maxsamplingrate_d/ -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) "Someone's been mean to you! Tell me who it is, so I can punch him tastefully." -- Ralph Bakshi's Mighty Mouse
Reply by ●May 26, 20142014-05-26
On 5/26/2014 9:33 AM, haiticare2011@gmail.com wrote:> Thanks. > OK - That seems reasonable to break up the architecture in a "bare metal" type > board which is data-facing plus a PC which is storage-centric. > > SO I guess what you are saying is that the SBC can send the data to the PC via > ethernet or USB, and accumulate it RT in a buffer on the SBC. > > One problem is that, if you dig into some of the popular SBC systems, like the > ARM335x, the actual ability to communicate with the world is pretty crappy. > One fellow (shabaz) tried to use USB-ftdi and abandoned it. Next he tried using > the PRUSS, a co-processor on the BBB, and eventually got 1-2 mHz speeds. > What is lacking is actual solutions by hackers/companies that are published. Until then, I can't play tinker-toys and plug the parts together. (which is > what I want of course. Like to avoid 6 month development detours.)If this is a one-off design, then you are going to need to do some work I think. If any part of this becomes a 6 month detour then you are not the right person for the job.> Another solution along this line of thinking is choose a board that is closer > to bare metal, yet one that can input, store, and pass on data. No OS. It would > need to be able to store data in local RAM and pass it on.Of course. The reason to get away from programming the PC in real time is the OS. So why pick a SBC with an OS??? That's not bare metal.> The loop I get into with that solution is you are asking a lot of that SBC and > wanting it to address memory, etc. without an OS. We worked on a DSP card for > the PC that did part of this.??? Addressing memory is hard? I'm not sure what you mean by this but I think you are showing your lack of familiarity of lower level programming. That is not intended to be offensive, just a statement of fact. On a SBC with no OS, the only difficult part is programming the interface to the host PC. You should choose one that has plenty of example code for doing this. Like I mentioned before you can let the SBC emulate a storage device in the eyes of the PC. If you need a separate I/O channel for control it can add a serial port emulation or perhaps an HMI. Mostly likely you can add a protocol to the storage interface to support both data and control.> So thanks for your input. The "missing link" remainsAgain, not trying to be offensive, but you keep looking right at the solution and passing it over. You seem not to be asking questions to learn what others have already learned, but to find a quick and easy solution to your problem that requires no learning. If that was available I think you would have received it already. To be honest, I expect there are data loggers available that will do exactly what you need. You might want to look for a COTS solution which is the truly easy path. -- Rick
Reply by ●May 26, 20142014-05-26
> What is lacking is actual solutions by hackers/companies that are published. Until then, I can't play tinker-toys and plug the parts together. (which is > what I want of course. Like to avoid 6 month development detours.)First of all, you need to help us understand what you really want. You talked a lot about A2D, but then this:> As an example, look at the Raspberry Pi camera, a 5 mp Omniview cmos chip. It > communicates with the Pi via a coprocessor section and high speed paralell > cable. This is the PRU idea, a dedicated coprocessor which runs independently > of the SBC mcu. Hijacking this data line is not feasible since internal routines massage the image data to make the image pretty.Do you want data acquisition or imaging, or even video? I think you said something about 30fps before.> That's the type of solution which would work on a SBC, and it's what the BBB is > "supposed" to do in the PRU. But actual working code is scarce. This will get > better over time,Can't suggest the solution without knowing the requirements.
