On 19/02/2019 23:28, Theo wrote:> Andrew Smallshaw <andrews@sdf.org> wrote:<snip>> I'd say a basic USB 1 isn't likely to go anywhere because every keyboard and > mouse speaks it, and I can't see that changing. If USB HID is an option for > you, might be worth considering. Similarly USB 2.0 Mass Storage is fairly > ubiquitous. > > USB serial is a bit messier - the protocol is less well specified, there's > already a wide range of silicon that needs its own special driver.That's why I always use FTDI - when you only have one type of silicon, you only need drivers from one place. They are good at keeping their Windows drivers up to date, which is nice when every version of Windows changes things. And there has been solid support in Linux forever, as well as useful libraries (like pyftdi) for controlling them. But HID is another possibility, especially if you have to connect to Windows systems.>> I don't pretend to have answers in the general case, just interested >> in what peoples thoughts are. > > I think the wider question is: where do you want to be on the > simplicity/performance curve? RS232 is very simple, and so implementations > are easy, but it's not performant. If you want more performance, you might > have to go to ethernet or USB Mass Storage, but they depend on larger host > software stacks. >USB mass storage has some advantages. Hosts already have the software stack - you just need it on the device. But it can be a handy way of doing software updates (copy the file onto the device), and makes it easy to distribute relevant software, PC applications, documentation, etc., with the hardware. Ethernet is always nice, flexible and fast - but you again need software on the device. And there is always the question of how you identify the device - it is no longer "the thing plugged into your computer".> The other option is to distribute your own software stack - ie a virtual > machine image. You're still relying on the host machine having an > ethernet/USB port, but you can pin down things like browser versions and > drivers. >That sounds a good deal more effort, especially as it depends highly on the virtual machine software on the computer.
Serial Port Emulation
Started by ●February 17, 2019
Reply by ●February 20, 20192019-02-20
Reply by ●February 23, 20192019-02-23
Andrew Smallshaw wrote:> On 2019-02-18, David Brown <david.brown@hesbynett.no> wrote: >> >> RS-232 is short distance too (though a bit longer than TTL) - for long >> distances you use RS-485 or RS-422. RS-232 is a legacy standard - there >> is plenty of old stuff the still has it, but it would be a strange >> choice for anything new. > > I'm genuinely interested to hear people thoughts on this. Personally > if I anticipate a true long life interfacing requirement - 20, 30, > 40 years - RS232 is my preferred option, ideally (if appropriate > to the use case) with a command line on it.<snip>> > I don't pretend to have answers in the general case, just interested > in what peoples thoughts are. >Anything you can do with RS323 you can do with Ethernet. There are pathological size/weight/power cases where Ethernet doesn't fit but if it does... -- Les Cargill
Reply by ●February 23, 20192019-02-23
On Sat, 23 Feb 2019 14:48:40 -0600, Les Cargill <lcargill99@comcast.com> wrote:>Andrew Smallshaw wrote: >> On 2019-02-18, David Brown <david.brown@hesbynett.no> wrote: >>> >>> RS-232 is short distance too (though a bit longer than TTL) - for long >>> distances you use RS-485 or RS-422. RS-232 is a legacy standard - there >>> is plenty of old stuff the still has it, but it would be a strange >>> choice for anything new. >> >> I'm genuinely interested to hear people thoughts on this. Personally >> if I anticipate a true long life interfacing requirement - 20, 30, >> 40 years - RS232 is my preferred option, ideally (if appropriate >> to the use case) with a command line on it. ><snip> >> >> I don't pretend to have answers in the general case, just interested >> in what peoples thoughts are. >> > >Anything you can do with RS323 you can do with Ethernet. There are >pathological size/weight/power cases where Ethernet doesn't fit but >if it does...Ethernet does have a couple of annoying configuration issues, and requires either a custom client on an attached PC, or requires enough software to implement TCP and a TELNET or HTTP server (and TCP/IP brings a couple of annoying configuration issues as well). And, of course, as soon as you do have an Ethernet connection, anything non-TCP/IP is ruled out because the customer and marketing will immediately want to be able to do (whatever) from across the campus, and then inevitably further than that. And then you have security issues. Definitely the way to go if you can, but there are enough hurdles that you can find yourself longing for async RS-232 and a terminal emulator.
Reply by ●February 23, 20192019-02-23
On 2/23/19 3:48 PM, Les Cargill wrote:> Andrew Smallshaw wrote: >> On 2019-02-18, David Brown <david.brown@hesbynett.no> wrote: >>> >>> RS-232 is short distance too (though a bit longer than TTL) - for long >>> distances you use RS-485 or RS-422. RS-232 is a legacy standard - there >>> is plenty of old stuff the still has it, but it would be a strange >>> choice for anything new. >> >> I'm genuinely interested to hear people thoughts on this. Personally >> if I anticipate a true long life interfacing requirement - 20, 30, >> 40 years - RS232 is my preferred option, ideally (if appropriate >> to the use case) with a command line on it. > <snip> >> >> I don't pretend to have answers in the general case, just interested >> in what peoples thoughts are. >> > > Anything you can do with RS323 you can do with Ethernet. There are > pathological size/weight/power cases where Ethernet doesn't fit but > if it does... >Not sure I would consider it pathological to not have Ethernet as a likely option. Almost every small processor today has serial ports built in, and most of the ones that don't can fake it with bit banging pretty easy. You need a processor with much more significant resources before you get an Ethernet port on the processor, and then you need the resources for the Ethernet stack.
Reply by ●February 28, 20192019-02-28
Robert Wessel wrote:> On Sat, 23 Feb 2019 14:48:40 -0600, Les Cargill > <lcargill99@comcast.com> wrote: > >> Andrew Smallshaw wrote: >>> On 2019-02-18, David Brown <david.brown@hesbynett.no> wrote: >>>> >>>> RS-232 is short distance too (though a bit longer than TTL) - for long >>>> distances you use RS-485 or RS-422. RS-232 is a legacy standard - there >>>> is plenty of old stuff the still has it, but it would be a strange >>>> choice for anything new. >>> >>> I'm genuinely interested to hear people thoughts on this. Personally >>> if I anticipate a true long life interfacing requirement - 20, 30, >>> 40 years - RS232 is my preferred option, ideally (if appropriate >>> to the use case) with a command line on it. >> <snip> >>> >>> I don't pretend to have answers in the general case, just interested >>> in what peoples thoughts are. >>> >> >> Anything you can do with RS323 you can do with Ethernet. There are >> pathological size/weight/power cases where Ethernet doesn't fit but >> if it does... > > > Ethernet does have a couple of annoying configuration issues, and > requires either a custom client on an attached PC, or requires enough > software to implement TCP and a TELNET or HTTP server (and TCP/IP > brings a couple of annoying configuration issues as well). >There exist things like RasPi boards which can have FTDI USB RS232 ports attached. So really? You should be able to use DynDNS and DHCP and that's about all the config you need. With the RasPi's I have seen, it's even 802.11 - just carry an AP and you're in. You can do all the fiddly bits once, and offsite. Generally, I'll have a custom TCP server running on the Pi, which provides the option of encoding any twiddly parts about the device on the other end of the FTDI device, within the Pi.> And, of course, as soon as you do have an Ethernet connection, > anything non-TCP/IP is ruled out because the customer and marketing > will immediately want to be able to do (whatever) from across the > campus, and then inevitably further than that. And then you have > security issues. >Almost everything has Ethernet now.> Definitely the way to go if you can, but there are enough hurdles that > you can find yourself longing for async RS-232 and a terminal > emulator. >Oh, not so much :) Well, sometimes :) -- Les Cargill
Reply by ●February 28, 20192019-02-28
Richard Damon wrote:> On 2/23/19 3:48 PM, Les Cargill wrote: >> Andrew Smallshaw wrote: >>> On 2019-02-18, David Brown <david.brown@hesbynett.no> wrote: >>>> >>>> RS-232 is short distance too (though a bit longer than TTL) - for long >>>> distances you use RS-485 or RS-422. RS-232 is a legacy standard - there >>>> is plenty of old stuff the still has it, but it would be a strange >>>> choice for anything new. >>> >>> I'm genuinely interested to hear people thoughts on this. Personally >>> if I anticipate a true long life interfacing requirement - 20, 30, >>> 40 years - RS232 is my preferred option, ideally (if appropriate >>> to the use case) with a command line on it. >> <snip> >>> >>> I don't pretend to have answers in the general case, just interested >>> in what peoples thoughts are. >>> >> >> Anything you can do with RS323 you can do with Ethernet. There are >> pathological size/weight/power cases where Ethernet doesn't fit but >> if it does... >> > > Not sure I would consider it pathological to not have Ethernet as a > likely option. Almost every small processor today has serial ports built > in, and most of the ones that don't can fake it with bit banging pretty > easy. You need a processor with much more significant resources before > you get an Ethernet port on the processor, and then you need the > resources for the Ethernet stack. >Dunno; there are Arduino-class devices that fake having an Ethernet port pretty well... So that's when you use a RasPi as a serial port server. -- Les Cargill
Reply by ●February 28, 20192019-02-28
On 28/02/2019 05:15, Les Cargill wrote:> Robert Wessel wrote: >> On Sat, 23 Feb 2019 14:48:40 -0600, Les Cargill >> <lcargill99@comcast.com> wrote: >> >>> Andrew Smallshaw wrote: >>>> On 2019-02-18, David Brown <david.brown@hesbynett.no> wrote: >>>>> >>>>> RS-232 is short distance too (though a bit longer than TTL) - for long >>>>> distances you use RS-485 or RS-422. RS-232 is a legacy standard - >>>>> there >>>>> is plenty of old stuff the still has it, but it would be a strange >>>>> choice for anything new. >>>> >>>> I'm genuinely interested to hear people thoughts on this. Personally >>>> if I anticipate a true long life interfacing requirement - 20, 30, >>>> 40 years - RS232 is my preferred option, ideally (if appropriate >>>> to the use case) with a command line on it. >>> <snip> >>>> >>>> I don't pretend to have answers in the general case, just interested >>>> in what peoples thoughts are. >>>> >>> >>> Anything you can do with RS323 you can do with Ethernet. There are >>> pathological size/weight/power cases where Ethernet doesn't fit but >>> if it does... >> >> >> Ethernet does have a couple of annoying configuration issues, and >> requires either a custom client on an attached PC, or requires enough >> software to implement TCP and a TELNET or HTTP server (and TCP/IP >> brings a couple of annoying configuration issues as well). >> > > There exist things like RasPi boards which can have FTDI USB > RS232 ports attached. So really? You should be able to use DynDNS and > DHCP and that's about all the config you need. With the RasPi's I have > seen, it's even 802.11 - just carry an AP and you're in. > > You can do all the fiddly bits once, and offsite. > > Generally, I'll have a custom TCP server running on the Pi, which > provides the option of encoding any twiddly parts about the device on > the other end of the FTDI device, within the Pi.I don't know what kind of systems you work with, but to me a Pi is convenient for testing and developing, but is out of the question for most delivered systems. The same goes for jumbled mixups with dynamic DNS - fine for test setups, not for deployment.> >> And, of course, as soon as you do have an Ethernet connection, >> anything non-TCP/IP is ruled out because the customer and marketing >> will immediately want to be able to do (whatever) from across the >> campus, and then inevitably further than that. And then you have >> security issues. >> > > Almost everything has Ethernet now.Almost every microcontroller does /not/ have Ethernet. Almost every electronics board made does /not/ have Ethernet.> >> Definitely the way to go if you can, but there are enough hurdles that >> you can find yourself longing for async RS-232 and a terminal >> emulator. >> > > Oh, not so much :) Well, sometimes :) >
Reply by ●February 28, 20192019-02-28
On Thursday, February 28, 2019 at 1:41:36 AM UTC-6, David Brown wrote:> On 28/02/2019 05:15, Les Cargill wrote: > > > > Generally, I'll have a custom TCP server running on the Pi, which > > provides the option of encoding any twiddly parts about the device on > > the other end of the FTDI device, within the Pi. > > I don't know what kind of systems you work with, but to me a Pi is > convenient for testing and developing, but is out of the question for > most delivered systems. The same goes for jumbled mixups with dynamic > DNS - fine for test setups, not for deployment.It's nice to say you don't like using pis for delivered systems, but that's not useful to anyone else unless you explain why. The rPi foundation even makes boards specifically for embedded systems and I believe they have some level of assurance these units will continue to be available.> > Almost everything has Ethernet now. > > Almost every microcontroller does /not/ have Ethernet. Almost every > electronics board made does /not/ have Ethernet.I think both statements are exaggerations. Plenty of MCUs are Ethernet capable. If you want Ethernet it is easy to select a version with a network interface. Rick C.
Reply by ●March 1, 20192019-03-01
On 01/03/2019 00:07, gnuarm.deletethisbit@gmail.com wrote:> On Thursday, February 28, 2019 at 1:41:36 AM UTC-6, David Brown wrote: >> On 28/02/2019 05:15, Les Cargill wrote: >>> >>> Generally, I'll have a custom TCP server running on the Pi, which >>> provides the option of encoding any twiddly parts about the device on >>> the other end of the FTDI device, within the Pi. >> >> I don't know what kind of systems you work with, but to me a Pi is >> convenient for testing and developing, but is out of the question for >> most delivered systems. The same goes for jumbled mixups with dynamic >> DNS - fine for test setups, not for deployment. > > It's nice to say you don't like using pis for delivered systems, but that's not useful to anyone else unless you explain why.Fair enough.> > The rPi foundation even makes boards specifically for embedded systems and I believe they have some level of assurance these units will continue to be available.Normally when talking about a Pi without being specific, it is reasonable to assume standard Pi boards. These have no guaranteed availability lifetime, no thoughts of MTBF or environmental limits, are full of connectors without any locking or stability, are impractical for any kind of solid mounting, and are not practically designed for production, testing and integration with industrial systems that need to be produced consistently, solidly, reliably, and cheaply. These devices are made for the desktop - for education, experiments, fun, prototypes, for cheap computers. They are excellent for that. But not for later stages in most kinds of delivered embedded systems. (Of course there are some kinds of system where they are fine, but those are in the minority.) You buy you Pi boards one at a time, not in deliveries of hundreds or thousands. The embedded Pi cards /are/ more suited for production of finished systems. But they still suffer from the same disadvantage any embedded Linux system has in comparison to using small microcontrollers - long and complicated production programming, finer and more delicate electronics, security, software auditing and control, software licensing, timing jitter, boot times, large and complex updates, unstable software, support, developer requirements, power requirements, environmental limits. Now, embedded Linux systems can give you enormous flexibility, and you get a vast amount of software features and power for very little cost. In many systems, this is what you want, and a Pi compute module (not a normal Pi) may be a reasonable way to get that. But in many more systems, you don't need that - and the cost of having a much more complex system is far too high.> > >>> Almost everything has Ethernet now. >> >> Almost every microcontroller does /not/ have Ethernet. Almost every >> electronics board made does /not/ have Ethernet. > > I think both statements are exaggerations. Plenty of MCUs are Ethernet capable.I did a quick and unscientific test. On Digikey, there are 78,510 microcontrollers. 4,498 have Ethernet. (Yes, I know you get multiple lines for essentially the same devices.) I will admit that is a higher proportion than I had expected. But still, the great majority of available types of microcontroller do not have Ethernet. And while I have no statistics here, I would expect the non-Ethernet microcontrollers here to ship in several orders of magnitude higher quantities than the the ones with Ethernet. At what point can we say that almost every microcontroller shipped does not have Ethernet? 99% 99.9%? 99.99%? Certainly Ethernet is getting more common - there are more devices available, and there are quality network stacks available freely. There is a much lower entry cost to using Ethernet now than there was 5 years ago. But still I stand by my statement that almost every board made does not have Ethernet.> If you want Ethernet it is easy to select a version with a network interface. >That is true, when you are at a certain size of microcontroller. If you are talking about a 32-bit device with 64 or more pins, 256K flash and 64K ram, running at 60+ MHz - yes, there is a high chance that you can find a device in the same family that has Ethernet. If you are using 8-bit or 16-bit microcontrollers, small or cheap devices (which may be 32-bit), low-power devices, high temperature devices, tiny package devices - no, you probably won't find Ethernet alternatives without changing family. In my own designs, I am quite fond of Ethernet. It gives a lot of flexibility and convenience. (I have a board plan which would have Ethernet merely for development and debugging.) But it is not for every use.
Reply by ●March 1, 20192019-03-01
gnuarm.deletethisbit@gmail.com writes:> It's nice to say you don't like using pis for delivered systems, but > that's not useful to anyone else unless you explain why.I asked the grisp.org guy that same question, and he replied that: 1) most of the effort in developing an embedded dev environment was in writing device drivers that are very hardware-specific, and in the case of the pi, the hardware changes so fast that the drivers have to be rewritten all the time. So he wanted hardware with a longer lifecycle. 2) the rpi foundation doesn't allow changing the hardware design: you can plop their boards into their product and that's it. Note that the Beaglebone doesn't have that restriction, and there are various Beaglebone-derived boards available from seeedstudio and elsewhere. The Grisp board is very nice but expensive enough that I can't imagine using one in a hobby project. Erlang on Grisp (basically Erlang runs on the bare metal without an intermediary OS) may have some slight latency advantages vs Erlang under Linux on an rpi, but if something is really hard-real-time I'd like to hope it can be offloaded to a simpler mcu (like the realtime coprocessors on the beaglebone) or to an FPGA.