4 ms·

I designed Nusbio 1 to be cheap and a first USB device for .NET developers with little knowledge in electricity to start playing with IO, I2C, SPI, ADC directly

I designed Nusbio 1 to be cheap and a first USB device for .NET developers with little knowledge in electricity to start playing with IO, I2C, SPI, ADC directly from Windows and .NET languages. It has some limitations in terms of IO default state, IO polling or speed of transfer (I2C:15Kbyte/S, SPI:15KBytes/S To 28KBytes/S). Samples in C#, VB.NET or Powershell codes are available on github. Regarding the IO polling issue, I do not think this can be address with a Windows PC or Linux on the Raspberry PI. I tested the USB interrupt for the FTDI FT4222 and this is not very impressive. Nusbio v2 coming sometime this year will address some of these issues, IO default state as input, increase in speed transfer (I2C:Up to 128Kbyte/S, SPI:Up to 2.4 Mbyte/S), 10 bit ADC. But unfortunately will be more expensive. Therefore not a device for beginner or small project. see https://twitter.com/MadeInTheUSB/status/848013033335029761 https://twitter.com/MadeInTheUSB/status/848013033335029761

LeifCarrotson 10y ago
First, love your username. And it's impressive to get this level of a product together! > Regarding the IO polling issue, I do not think this can be address with a Windows PC or Linux on the Raspberry PI. I tested the USB interrupt for the FTDI FT4222 and this is not very impressive. Yeah, that's not the right approach. As a controls engineer who builds PC-based test and manufacturing equipment, this is your competition: http://www.ni.com/pdf/manuals/374369a.pdf http://www.ni.com/pdf/manuals/374369a.pdf http://www.ni.com/pdf/manuals/374566d.pdf http://www.ni.com/pdf/manuals/374566d.pdf These can be programmed with .NET languages and C/C++ using Measurement Studio, or graphically through LabView. I think the critical differences are (1) using USB directly, rather than a serial emulator, enabling much higher data rates - you don't necessarily need this yet, low-speed is probably fine and (2) using internal FIFOs and Tasks to control IO instead of handling each bit over the connection. Essentially, what you want to do is push all the real-time stuff off to the microcontroller on the peripheral, and only synchronize every couple hundred milliseconds with the PC, which will essentially take in a large buffer with the history of the inputs at 1 kHz or more, and output a similarly sized buffer with the data to be encoded on the outputs until the next synchronization. Anything that needs to happen faster than that needs to be set up before hand.
yitchelle 10y ago
Don't get me wrong. For me it all comes down to context. You still could do plenty of stuff at slow speed. Good luck on v2.0!

LeifCarrotson 10y ago

First, love your username. And it's impressive to get this level of a product together! > Regarding the IO polling issue, I do not think this can be address with a Windows PC or Linux on the Raspberry PI. I tested the USB interrupt for the FTDI FT4222 and this is not very impressive. Yeah, that's not the right approach. As a controls engineer who builds PC-based test and manufacturing equipment, this is your competition: http://www.ni.com/pdf/manuals/374369a.pdf http://www.ni.com/pdf/manuals/374369a.pdf http://www.ni.com/pdf/manuals/374566d.pdf http://www.ni.com/pdf/manuals/374566d.pdf These can be programmed with .NET languages and C/C++ using Measurement Studio, or graphically through LabView. I think the critical differences are (1) using USB directly, rather than a serial emulator, enabling much higher data rates - you don't necessarily need this yet, low-speed is probably fine and (2) using internal FIFOs and Tasks to control IO instead of handling each bit over the connection. Essentially, what you want to do is push all the real-time stuff off to the microcontroller on the peripheral, and only synchronize every couple hundred milliseconds with the PC, which will essentially take in a large buffer with the history of the inputs at 1 kHz or more, and output a similarly sized buffer with the data to be encoded on the outputs until the next synchronization. Anything that needs to happen faster than that needs to be set up before hand.

yitchelle 10y ago

Don't get me wrong. For me it all comes down to context. You still could do plenty of stuff at slow speed. Good luck on v2.0!