I don't get it, why is this even high up on HN? There's a ton of similar products, many which do a lot more than this that can be controlled using .net
This was downvoted quite a bit when I came across it, but can someone explain why it's so bad?
Sometimes you do want to add GPIO to an existing Windows machine, but if you just want to mess around with .Net and some simple electronics, the parent's suggestion is cheap and simple (and e.g. https://github.com/raspberry-sharp/raspberry-sharp-io claims to support this use case.)
Used these for some simple automation needs in the past. Simple .net library available on the site. Not nearly as cheap as the one in the post (which I did have to google 3 different sites to find the price of)
You are right there is .NET support, I used it the SPI library.
I think there one library for I2C and one for SPI.
I settled on the FTDI ft4222 which is somehow easier to program
and can only do SPI and I2C (no IO, no UART). The FT232H could be faster
in SPI.
I did find some device that can do DAC/ADC or IO for $99.
I did not find one that can also do SPI and I2C.
one the web site, could give a link to a device like Nusbio
from the web site http://www.mccdaq.com/
for the operating systems version of real time, i'd consider it polling to be real time. you ensure that part of your code will always take the same amount of time.
it actually is, as long as your polling interval is deterministic and meets the requirements of your target application (polling interval < state change interval).
If you look at real hardware (or FPGAs) they will basically do polling: The input gets sampled at each clock cycle and will then get processed. And hardware is definitely realtime :)
The downside of polling is that you burn CPU resources when actually nothing happens. Interrupt driven designs help there.
> If you look at real hardware (or FPGAs) they will basically do polling: The input gets sampled at each clock cycle and will then get processed. And hardware is definitely realtime :)
Smiley noted; I think we can agree that "polling at 10s of MHz on an input pin" becomes something quite different than "polling at 10s of kHz on the other side of a USB link".
Polling GPIOs is bad, because you miss events. Looking through the source code, the author has functions to get the state of GPIO pins, which send a command over the USB serial port, then read the output. This is fine for things that don't change very often, but if you've got a keypad, or something that may have a relatively short pulse width, you really want a notification that something has happened (GPIO 4 just transitioned from 0-1). The simple way of doing that for this project would be for the hardware to send a message when that happens - its easy to set up interrupts on the MCU, and then send a message back down the serial channel saying what happened. Latency won't be great, but you shouldn't miss things. The Serial interface (over USB) isn't too bad, but will add latency over a raw USB interface.
You can still miss things -- you can only have so many interrupts fire at once. if all the pins change at the same time, you'll miss a few of em, especially if you're sending a serial message in the interrupt.
you're also more likely to get more than you want, and have to debounce on the processor side.
I'd go for a small fpga->ftdi usb controller. do a low pass filter on each pin, and when it goes above your threshold, throw it in a fifo that feeds the USB chip. your latency goes up with the number of changes that happen at once, but you're still using raw USB and not miss events that you're interested in.
Don't send serial messages in an interrupt, that is crazy. Just set a flag indicating what happened (or use a queue). Then in your main loop check the flag. If the loop is not able to clear it fast enough, report it as an error.
You can handle signals at 100kHz+ with such a technique.
But yes, might very well want some configurable low-pass/debouncing logic.
There is nothing bad about it as long as one is aware of the limitations. A $25 hobbyist IO module is perfectly fine and fully appropriate for a fleeting appearance on HN.
Please change the default direction to input (high-z). You could potentially fry some sensor or make a short circuit if they start in output before the code changes them to input.
Agreed. Power up sequencing on dumb low-level interfaces has to be thought through carefully. You may turn on something you don't want to turn on.
I have a device which controls an antique Teletype machine from a USB port. It uses the request to send signal on a USB-simulated serial port to start the Teletype motor. This works fine on Linux. On Windows, the motor starts and stops several times when the USB device is plugged in or Windows starts up. That's because an old Windows feature is probing the serial port for a serial mouse. Annoying.
Better yet: provide a 'output state valid' bit that is held low as long as some magic hasn't happened. Even an output configured as an input could cause that output to drift into 'undefined' territory.
An output state valid bit can be used to suppress all activation of external actuators until the software has been initialized and the state of the outputs can be safely exposed.
wonder (i) anything for mac and xcode based trial and (ii) any programmer suggested.
all just for hobby and my attempt to understand. have beadboard exprience and follow a course that use windows xp and M3 and a propeiority tool from TI.
Depends on the protocol they use on the USB connection. Serial over USB has its quirks. Using a Leonardo, a Due or a SAMD21 based Arduino allows you to implement something like HID which should give you better latency
You are right though I do think HID is limited to 64 Kbytes/S.
But an SAMD21 or 32U4 could allow me to build a cheaper product.
I have to think about it now.
What I am currently achieving is
- 100Kbytes/S in I2C with a 10Mhz I2C EEPROM and
- 2.4 Mbytes/S in SPI with a NOR FLASH at 103Mhz
using the FTDI FT4222 and the FT232H should the same or better.
I would think the fact that it is open source as you mentioned is the reason. My question was not meant to criticize just wondering if I missed something that makes these boards a better choice for an application I'm working on. I looked into basic stamp years ago also but the cost of them and my lack of funds at that time forced me to go down the PIC road instead.
You are right in some ways Nusbio and an Arduino with a UART, in term of features may not be that different.
With an Arduino specially Chinese Arduino compatible CH340 or with .NET languages you may be limited to 115200 bauds (about 11Kbyte/S) and you need to write and maintain a firmware. As a plus you get PWM and ADC.
Nusbio1 can do between 15 and 28 Kbytes/S in SPI and there is no firmware. But there is no PWM. ADC or DAC are available as SPI extensions.
it is not a black and white answer.
But with the knowledge I acquired creating Nusbio 1 hardware and software, I am now working on Nusbio 2.
Nusbio v2 coming sometime this year will address some of these issues, IO default state as input, increase in speed transfer (I2C:Up to 128 Kbyte/S, SPI:Up to 2.4 Mbyte/S), 10 bit ADC, PWM.
But unfortunately will be more expensive.
I think it would be more interesting to take ports found on many computers that aren't being used and turn them into GPIO.
There are Ethernet to Serial adapters [1] [2], I wonder if it could go further. There is also dvi, hdmi, displayport with lots of wires and a chip behind them. Displayport even has " A bi-directional, half-duplex auxiliary channel" [3] , though I'd want to look at the spec to see how that could be used, or if it could be contorted to a GPIO purpose.
There's tons of those things. Adafruit has one.[1] They're useful, but if you're doing something with critical timing, you usually don't want a Windows machine on the other end.
Check out https://microsoft.hackster.io/en-US/windowsiot/basic-windows... from microsoft. As I wrote in another comment Serial over USB is not great if you want to contain latency. Something like HID or a custom protocol using the Leonardo or the Zero would give you much better results
Using a i7 with Win10 just to get the blink LEDs application going is a bit over the top :-)
Joking aside, having one of these for a kid to play with is a good way to introduce them to world of controls. They are some areas to work through (polled inputs, default pin configuration etc) but it is a good start. Hoping that v2.0 will be more bespoked.
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.
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:
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.
I would caution against trying to drive anything serious from an IO solution whose inputs are not interrupt driven. Please use a real time operating system for jobs like these and communicate with your windows box on a higher abstraction level than directly driving outputs.
If you don't do that you risk your machinery not responding to critical inputs resulting in machine damage or worse.
If all you want to do is play around with lights and switches then this is fine.
50 comments
[ 5.0 ms ] story [ 82.8 ms ] thread---
Edit: some I have used or heard of that may or may not have .net support:
USB Bit Whacker - http://www.schmalzhaus.com/UBW/
Ultimarc control interfaces (haven't tried them) - http://www.ultimarc.com/
Sometimes you do want to add GPIO to an existing Windows machine, but if you just want to mess around with .Net and some simple electronics, the parent's suggestion is cheap and simple (and e.g. https://github.com/raspberry-sharp/raspberry-sharp-io claims to support this use case.)
Used these for some simple automation needs in the past. Simple .net library available on the site. Not nearly as cheap as the one in the post (which I did have to google 3 different sites to find the price of)
Tutorials, etc, here: https://learn.adafruit.com/adafruit-ft232h-breakout Includes some python code that works on Windows, Linux, etc.
A couple of sources:
http://www.ftdichip.com/Support/SoftwareExamples/MPSSE/FTCSP...
https://github.com/zhelnio/MPSSELight
If you look at real hardware (or FPGAs) they will basically do polling: The input gets sampled at each clock cycle and will then get processed. And hardware is definitely realtime :)
The downside of polling is that you burn CPU resources when actually nothing happens. Interrupt driven designs help there.
Smiley noted; I think we can agree that "polling at 10s of MHz on an input pin" becomes something quite different than "polling at 10s of kHz on the other side of a USB link".
you're also more likely to get more than you want, and have to debounce on the processor side.
I'd go for a small fpga->ftdi usb controller. do a low pass filter on each pin, and when it goes above your threshold, throw it in a fifo that feeds the USB chip. your latency goes up with the number of changes that happen at once, but you're still using raw USB and not miss events that you're interested in.
Is there any specific product you can recommend for a hobbyist's project?
But yes, might very well want some configurable low-pass/debouncing logic.
I have a device which controls an antique Teletype machine from a USB port. It uses the request to send signal on a USB-simulated serial port to start the Teletype motor. This works fine on Linux. On Windows, the motor starts and stops several times when the USB device is plugged in or Windows starts up. That's because an old Windows feature is probing the serial port for a serial mouse. Annoying.
An output state valid bit can be used to suppress all activation of external actuators until the software has been initialized and the state of the outputs can be safely exposed.
all just for hobby and my attempt to understand. have beadboard exprience and follow a course that use windows xp and M3 and a propeiority tool from TI.
http://playground.arduino.cc/Interfacing/Csharp
What I am currently achieving is
- 100Kbytes/S in I2C with a 10Mhz I2C EEPROM and - 2.4 Mbytes/S in SPI with a NOR FLASH at 103Mhz
using the FTDI FT4222 and the FT232H should the same or better.
With an Arduino specially Chinese Arduino compatible CH340 or with .NET languages you may be limited to 115200 bauds (about 11Kbyte/S) and you need to write and maintain a firmware. As a plus you get PWM and ADC. Nusbio1 can do between 15 and 28 Kbytes/S in SPI and there is no firmware. But there is no PWM. ADC or DAC are available as SPI extensions.
it is not a black and white answer.
But with the knowledge I acquired creating Nusbio 1 hardware and software, I am now working on Nusbio 2.
Nusbio v2 coming sometime this year will address some of these issues, IO default state as input, increase in speed transfer (I2C:Up to 128 Kbyte/S, SPI:Up to 2.4 Mbyte/S), 10 bit ADC, PWM. But unfortunately will be more expensive.
see https://twitter.com/MadeInTheUSB/status/848013033335029761
If the former, then why should anyone choose this over Netduino? If the latter: why have you chosen this product?
edit: by browsing the page I saw it is the former.
There are Ethernet to Serial adapters [1] [2], I wonder if it could go further. There is also dvi, hdmi, displayport with lots of wires and a chip behind them. Displayport even has " A bi-directional, half-duplex auxiliary channel" [3] , though I'd want to look at the spec to see how that could be used, or if it could be contorted to a GPIO purpose.
[1] https://en.wikipedia.org/wiki/PHY_%28chip%29
[2] https://electronics.stackexchange.com/questions/24588/is-the...
[3] https://en.wikipedia.org/wiki/DisplayPort
[1] https://www.adafruit.com/product/2264
http://www.ghs.com/products/rtos/integrity.html
But the FT232H breakout from Adafruit is great and the cheapest. But they do not offer .NET support on Windows and FTDI does not either.
Here is one of my experiment with Adafruit FT232H breakout in C. https://twitter.com/MadeInTheUSB/status/848799047632773120
Joking aside, having one of these for a kid to play with is a good way to introduce them to world of controls. They are some areas to work through (polled inputs, default pin configuration etc) but it is a good start. Hoping that v2.0 will be more bespoked.
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
> 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/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.
If you don't do that you risk your machinery not responding to critical inputs resulting in machine damage or worse.
If all you want to do is play around with lights and switches then this is fine.