Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31541 > unrolled thread
| Started by | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| First post | 2023-01-17 07:24 -0800 |
| Last post | 2023-03-29 00:44 -0700 |
| Articles | 20 on this page of 155 — 18 participants |
Back to article view | Back to comp.arch.embedded
Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-17 07:24 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-17 11:31 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-17 12:19 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-17 13:07 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-17 13:29 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-17 14:04 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-17 14:47 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-17 15:32 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-17 15:44 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-17 16:04 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-17 17:32 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-17 20:02 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-17 20:24 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-17 20:56 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-17 22:30 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-18 00:37 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-18 04:43 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-18 14:19 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-18 23:15 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-19 12:21 -0800
Re: Boxed MCU with RS-232 Port Andrew Smallshaw <andrews@sdf.org> - 2023-01-18 12:15 +0000
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-18 04:55 -0800
Re: Boxed MCU with RS-232 Port Andrew Smallshaw <andrews@sdf.org> - 2023-01-18 13:22 +0000
Re: Boxed MCU with RS-232 Port Andrew Smallshaw <andrews@sdf.org> - 2023-01-18 13:28 +0000
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-18 06:20 -0800
Re: Boxed MCU with RS-232 Port David Brown <david.brown@hesbynett.no> - 2023-01-18 10:04 +0100
Re: Boxed MCU with RS-232 Port Theo <theom+news@chiark.greenend.org.uk> - 2023-01-18 16:18 +0000
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-18 14:10 -0800
Re: Boxed MCU with RS-232 Port Theo <theom+news@chiark.greenend.org.uk> - 2023-01-19 10:29 +0000
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-01-19 05:41 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-19 10:00 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-19 12:42 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-19 14:10 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-19 16:16 -0800
Re: Boxed MCU with RS-232 Port Grant Edwards <invalid@invalid.invalid> - 2023-01-19 16:07 +0000
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-19 10:13 -0800
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-01-19 14:51 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-19 10:06 -0800
Re: Boxed MCU with RS-232 Port Theo <theom+news@chiark.greenend.org.uk> - 2023-01-20 13:03 +0000
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-20 06:28 -0800
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-01-20 19:14 -0800
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-01-20 20:41 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-01-21 05:05 -0700
Re: Boxed MCU with RS-232 Port Theo <theom+news@chiark.greenend.org.uk> - 2023-01-21 10:53 +0000
Re: Boxed MCU with RS-232 Port Herbert Kleebauer <klee@unibwm.de> - 2023-01-20 19:17 +0100
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-20 12:37 -0800
Re: Boxed MCU with RS-232 Port Dimiter_Popoff <dp@tgi-sci.com> - 2023-01-20 23:02 +0200
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-20 14:08 -0800
Re: Boxed MCU with RS-232 Port Dimiter_Popoff <dp@tgi-sci.com> - 2023-01-21 01:38 +0200
Re: Boxed MCU with RS-232 Port antispam@math.uni.wroc.pl - 2023-01-21 01:58 +0000
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-20 18:44 -0800
Re: Boxed MCU with RS-232 Port antispam@math.uni.wroc.pl - 2023-01-21 20:02 +0000
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-22 17:12 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-02-03 09:22 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-02-03 10:04 -0800
Re: Boxed MCU with RS-232 Port Dimiter_Popoff <dp@tgi-sci.com> - 2023-03-26 22:24 +0300
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 02:27 -0700
Re: Boxed MCU with RS-232 Port pozz <pozzugno@gmail.com> - 2023-01-20 08:54 +0100
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-20 01:03 -0800
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-22 12:18 -0700
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-03-22 20:35 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-22 23:26 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-22 23:28 -0700
Re: Boxed MCU with RS-232 Port Theo <theom+news@chiark.greenend.org.uk> - 2023-03-23 10:06 +0000
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-24 00:59 -0700
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-03-23 09:00 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-24 01:03 -0700
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-03-23 08:54 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-24 01:02 -0700
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-03-24 01:43 -0700
Re: Boxed MCU with RS-232 Port Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2023-03-24 12:44 +0100
Re: Boxed MCU with RS-232 Port Theo <theom+news@chiark.greenend.org.uk> - 2023-03-24 14:20 +0000
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-24 08:08 -0700
Re: Boxed MCU with RS-232 Port Theo <theom+news@chiark.greenend.org.uk> - 2023-03-24 16:23 +0000
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-03-24 13:42 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-24 14:31 -0700
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-03-24 18:19 -0700
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-03-24 18:22 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-24 18:34 -0700
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-03-24 19:43 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-24 20:01 -0700
Re: Boxed MCU with RS-232 Port Paul Rubin <no.email@nospam.invalid> - 2023-03-24 21:18 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-24 15:35 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-24 18:21 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-24 19:21 -0700
Re: Boxed MCU with RS-232 Port George Neuner <gneuner2@comcast.net> - 2023-03-25 21:42 -0400
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-25 19:26 -0700
Re: Boxed MCU with RS-232 Port Jim Jackson <jj@franjam.org.uk> - 2023-03-26 18:27 +0000
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-26 13:23 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-26 13:32 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-26 13:52 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-26 19:30 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-26 20:31 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 07:04 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 09:21 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 09:56 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 13:08 -0700
Re: Boxed MCU with RS-232 Port Jim Jackson <jj@franjam.org.uk> - 2023-03-27 20:46 +0000
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 15:07 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 15:07 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 14:50 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 15:07 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 15:24 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 15:36 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 15:37 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 15:42 -0700
Re: Boxed MCU with RS-232 Port David Brown <david.brown@hesbynett.no> - 2023-03-27 11:03 +0200
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 07:11 -0700
Re: Boxed MCU with RS-232 Port Dimiter_Popoff <dp@tgi-sci.com> - 2023-03-27 17:47 +0300
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 08:05 -0700
Re: Boxed MCU with RS-232 Port Dimiter_Popoff <dp@tgi-sci.com> - 2023-03-27 19:09 +0300
Re: Boxed MCU with RS-232 Port David Brown <david.brown@hesbynett.no> - 2023-03-27 17:38 +0200
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-26 19:22 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-26 19:11 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-26 13:37 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-26 19:28 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 13:38 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 15:05 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 15:08 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 15:25 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 15:38 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-26 13:23 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-26 19:25 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-26 20:31 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 07:05 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 09:18 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 10:09 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 12:16 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 13:03 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 13:17 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 15:05 -0700
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-27 15:40 -0700
Re: Boxed MCU with RS-232 Port Clifford Heath <no.spam@please.net> - 2023-03-28 10:36 +1100
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 17:59 -0700
Re: Boxed MCU with RS-232 Port Clifford Heath <no.spam@please.net> - 2023-03-28 12:58 +1100
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 20:41 -0700
Re: Boxed MCU with RS-232 Port Clifford Heath <no.spam@please.net> - 2023-03-28 15:21 +1100
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-28 08:37 -0700
Re: Boxed MCU with RS-232 Port Jim Jackson <jj@franjam.org.uk> - 2023-03-28 20:00 +0000
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-28 13:06 -0700
Re: Boxed MCU with RS-232 Port Clifford Heath <no.spam@please.net> - 2023-03-29 08:03 +1100
Re: Boxed MCU with RS-232 Port Don Y <blockedofcourse@foo.invalid> - 2023-03-28 00:11 -0700
Re: Boxed MCU with RS-232 Port "b...@gmx.com" <bl1@gmx.com> - 2023-03-27 16:17 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 18:12 -0700
Re: Boxed MCU with RS-232 Port Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2023-03-24 19:26 +0100
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-24 08:03 -0700
Re: Boxed MCU with RS-232 Port Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2023-03-24 19:10 +0100
Re: Boxed MCU with RS-232 Port Herbert Kleebauer <klee@unibwm.de> - 2023-03-24 17:16 +0100
Re: Boxed MCU with RS-232 Port Herbert Kleebauer <klee@unibwm.de> - 2023-03-24 18:54 +0100
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-24 11:34 -0700
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-27 10:18 -0700
Re: Boxed MCU with RS-232 Port Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> - 2023-03-28 20:53 +0000
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-28 16:12 -0700
Re: Boxed MCU with RS-232 Port Niklas Holsti <niklas.holsti@tidorum.invalid> - 2023-03-29 09:06 +0300
Re: Boxed MCU with RS-232 Port Rick C <gnuarm.deletethisbit@gmail.com> - 2023-03-29 00:44 -0700
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-01-17 07:24 -0800 |
| Subject | Boxed MCU with RS-232 Port |
| Message-ID | <f1d09e6f-688d-4a73-9a37-a4a58de6a3a9n@googlegroups.com> |
The unit only really needs one serial port, but it is more convenient to have two connectors, so I guess it needs to ports. One port will only receive and the other only transmit, no handshaking. The function is pretty simple. A sensor sends a line of about 50 chars, at 9,600 bps, once per second. This box counts 20 lines and adds a header. So nothing fancy is required of the MCU. There are parameters set when starting operation. The main thing I'm having trouble finding, is this needs to be in a box as a unit, not a board and a box to be assembled. Google hasn't been much help returning all sorts of things that aren't useful. Anyone know of such a box? The programming might be contracted out, if you are interested. There's a prototype using an Arduino nano, but some of them are flaky and it would not hurt to start over from scratch. -- Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209
[toc] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2023-01-17 11:31 -0800 |
| Message-ID | <87k01lufem.fsf@nightsong.com> |
| In reply to | #31541 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > Anyone know of such a box? The programming might be contracted out, > if you are interested. There's a prototype using an Arduino nano, but > some of them are flaky and it would not hurt to start over from > scratch. There's about a gazillion industrial computers that do this, though they are probably overkill and more expensive than one would prefer. This one is on the front page of cnx-software right now: https://www.cnx-software.com/2023/01/17/edatec-cm4-sensing-industrial-computer-offers-can-bus-rs485-and-rs232-interfaces/ Note that most of the boxed computers on that blog are quite powerful, more than you need for this: https://www.cnx-software.com/news/industrial You could try a more general web search for "industrial embedded computer" if that is the sort of thing you want. Do you need the box to come from a real manufacturer with customer support? Is the idea to deploy a moderate number of these, say dozens? A much larger number? Or is it basically a one-off? If characters are coming in at the full speed of the 9600 bps port, and going out at the same speed, and more characters are going out than coming in (because of the headers being added), how is this supposed to work with no flow control? Regarding the programming, if it is just as you describe, there is not much to it, I would have thought. If there is only one input port to this box, why use a box at all, rather than have the sensor emit the header every 20 lines?
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-01-17 12:19 -0800 |
| Message-ID | <af677448-3930-4c1f-b6da-afdba5720305n@googlegroups.com> |
| In reply to | #31546 |
On Tuesday, January 17, 2023 at 3:31:21 PM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.del...@gmail.com> writes: > > Anyone know of such a box? The programming might be contracted out, > > if you are interested. There's a prototype using an Arduino nano, but > > some of them are flaky and it would not hurt to start over from > > scratch. > There's about a gazillion industrial computers that do this, though they > are probably overkill and more expensive than one would prefer. This > one is on the front page of cnx-software right now: > > https://www.cnx-software.com/2023/01/17/edatec-cm4-sensing-industrial-computer-offers-can-bus-rs485-and-rs232-interfaces/ > > Note that most of the boxed computers on that blog are quite powerful, > more than you need for this: > > https://www.cnx-software.com/news/industrial Yes, way overkill. I think I said the initial units use the Arduino nano. No OS required, and in fact is a liability. > You could try a more general web search for "industrial embedded > computer" if that is the sort of thing you want. Yes, and I get the sort of things you link to above. > Do you need the box to > come from a real manufacturer with customer support? Is the idea to > deploy a moderate number of these, say dozens? A much larger number? > Or is it basically a one-off? I think they have built a dozen now. They expect to build a few more before the modify the receiver of the data to handle this function. They are making this with an Arduino nano and a small custom board for the RS-232 converter, in a 3d printed box. All of that is fine I expect. But they are having this problem. Here's what I would like to use. https://www.brainboxes.com/product/usb-to-serial/usb/us-257 https://www.brainboxes.com/product/ethernet-to-serial/db9/es-257 Right size, right case. But they are not a computer as such, they're USB or Ethernet based serial port adapters. I've written to them to see if this unit can be programmed by the user. > If characters are coming in at the full speed of the 9600 bps port, and > going out at the same speed, and more characters are going out than > coming in (because of the headers being added), how is this supposed to > work with no flow control? You mean, how would it work *with* flow control, right? The data is coming in, 9,600 bps, 50 chars per second. There is a ton of idle time to send the headers between the 50 char messages. > Regarding the programming, if it is just as you describe, there is not > much to it, I would have thought. There's always more than meets the eye. I looked at the code and although it's Arduino code, it is enough like C that I can tell it's missing a few things. One is, the files I have are line delimited by the DOS convention, /r/n. The program counts lines by checking for /r, ignoring /n. I don't know if that would cause any problems, but if the /r is missed from data corruption, the character buffer would likely overflow, causing who knows what harm. The character count should be checked for bounds. I'm not even sure why the data is being buffered, it could be sent through one character at a time, simply monitoring for the end of line. > If there is only one input port to this box, why use a box at all, > rather than have the sensor emit the header every 20 lines? We don't control the sensor. It used to send a periodic header. They changed to a new model or an upgrade, or something else which means the header is no longer sent. If I wasn't up to my ears, I would take this on. But I am, so I can't. But that may change. Thanks for your reply. -- Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2023-01-17 13:07 -0800 |
| Message-ID | <87cz7cvpi0.fsf@nightsong.com> |
| In reply to | #31547 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > Yes, way overkill. I think I said the initial units use the Arduino > nano. No OS required, and in fact is a liability. The OS won't hurt, but maybe it won't help much if the thing is this simple. I can say I worked on a much fancier gadget like this using an ARM Linux board (it intercepted and modified the data stream between a POS terminal and a receipt printer, doing full duplex comms on both sides while also getting data from the internet) and it worked fine using the on-board 16550-style UARTs. > They are making this with an Arduino nano and a small custom board for > the RS-232 converter, in a 3d printed box. All of that is fine I > expect. But they are having this problem. Hmm, I wonder if it can be diagnosed, if they are ok keeping on using the same hardware. Any idea what was going wrong? Flaky hardware? Underpowered RS232 ports? > Here's what I would like to use. > https://www.brainboxes.com/product/usb-to-serial/usb/us-257 Those look nice. I will keep looking around / asking around. > There is a ton of idle time to send the headers between the 50 char > messages. Ah right, I had missed or forgotten that there was just one message per second. Yes, you are fine. > There's always more than meets the eye. I looked at the code and > although it's Arduino code, it is enough like C that I can tell it's > missing a few things. Arduino code is C++ with some special libraries and light preprocessing, so it shouldn't be too big a deal to hack it. > I don't know if that would cause any problems, but if the /r is missed > from data corruption, the character buffer would likely overflow, > causing who knows what harm.... Fair enough, yes, the program should check for various kinds of errors. Is it disastrous if an error results in some kind of alert that temporarily stops operation? The idea is to deploy something that passes reasonable testing, possibly hit a few unexpected error conditions during initial production, fix those, and hopefully be reliable afterwards, but have it not be catastrophic if something goes wrong after a long period. What do you want to have happen in case of data corruption anyway? Do the messages have checksums and should the pass-through box check them? > I'm not even sure why the data is being buffered, it could be sent > through one character at a time... If this thing is susceptible to later feature creep, the buffering might make things easier. It seems to me that if you have another person involved with the programming, that person should be close to the customer site in order to diagnose issues that might come up with the installed systems. Or at least, they should have real sensor hardware that they can test with. > If I wasn't up to my ears, I would take this on. But I am, so I > can't. Understandable ;).
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-01-17 13:29 -0800 |
| Message-ID | <2b3941b6-1a59-412c-b088-29794ac047b3n@googlegroups.com> |
| In reply to | #31548 |
On Tuesday, January 17, 2023 at 5:08:01 PM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.del...@gmail.com> writes: > > Yes, way overkill. I think I said the initial units use the Arduino > > nano. No OS required, and in fact is a liability. > The OS won't hurt, but maybe it won't help much if the thing is this > simple. I can say I worked on a much fancier gadget like this using an > ARM Linux board (it intercepted and modified the data stream between a > POS terminal and a receipt printer, doing full duplex comms on both > sides while also getting data from the internet) and it worked fine > using the on-board 16550-style UARTs. > > They are making this with an Arduino nano and a small custom board for > > the RS-232 converter, in a 3d printed box. All of that is fine I > > expect. But they are having this problem. > Hmm, I wonder if it can be diagnosed, if they are ok keeping on using > the same hardware. Any idea what was going wrong? Flaky hardware? > Underpowered RS232 ports? I don't know. The original guy who designed this is a bit busy. Because the problem is associated with some specific units, it's not terribly likely to be a coding issue. But who knows? Once the error is observed, a power cycle is required to fix it. It's not a one time glitch. > > Here's what I would like to use. > > https://www.brainboxes.com/product/usb-to-serial/usb/us-257 > Those look nice. I will keep looking around / asking around. > > There is a ton of idle time to send the headers between the 50 char > > messages. > Ah right, I had missed or forgotten that there was just one message per > second. Yes, you are fine. > > There's always more than meets the eye. I looked at the code and > > although it's Arduino code, it is enough like C that I can tell it's > > missing a few things. > Arduino code is C++ with some special libraries and light preprocessing, > so it shouldn't be too big a deal to hack it. > > I don't know if that would cause any problems, but if the /r is missed > > from data corruption, the character buffer would likely overflow, > > causing who knows what harm.... > > Fair enough, yes, the program should check for various kinds of errors. > > Is it disastrous if an error results in some kind of alert that > temporarily stops operation? The idea is to deploy something that > passes reasonable testing, possibly hit a few unexpected error > conditions during initial production, fix those, and hopefully be > reliable afterwards, but have it not be catastrophic if something goes > wrong after a long period. This is actually a patch added when the sensor was changed to an updated model which no longer outputs the same format or the headers. It is likely to be dealt with by a change in the device that receives the reformatted data... at some point. > What do you want to have happen in case of data corruption anyway? Do > the messages have checksums and should the pass-through box check them? I don't know. I think Checksums are overkill and just not appropriate. There's no one to add or check the checksums. I believe this is data that is simply being logged. The real problem is not the glitch, but that the failure remains until the translator is reset. > > I'm not even sure why the data is being buffered, it could be sent > > through one character at a time... > > If this thing is susceptible to later feature creep, the buffering might > make things easier. In talking to someone else, I remembered that the date and time formats are changed as well, so that's why the message is buffered. > It seems to me that if you have another person involved with the > programming, that person should be close to the customer site in order > to diagnose issues that might come up with the installed systems. Or at > least, they should have real sensor hardware that they can test with. The problem follows certain units. I don't know how they did testing, but the units that work, work. > > If I wasn't up to my ears, I would take this on. But I am, so I > > can't. > Understandable ;). Anyone else have taller ears? lol I'd be happy with a solid CPU in a good box. The current units are hand wired, so who knows how well they are made? This is the problem when one person designs something, then another person has to make it work. You never know where the bodies are buried. Thanks for your insights. -- Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2023-01-17 14:04 -0800 |
| Message-ID | <878ri0vmvg.fsf@nightsong.com> |
| In reply to | #31549 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > Once the error is observed, a power cycle is required to fix it. It's > not a one time glitch. Gack, yeah. I had been thinking, this isn't my area, but my understanding is that the RS232 electrical spec requires voltages that are somewhat above TTL logic levels, and that various crappy devices skimp on these voltages and mostly work anyway. So that is a thing to suspect if a home-brew RS232 device is acting flaky. It could be that the device at the other end expects those voltages to be closer to the real spec. > This is actually a patch added when the sensor was changed to an > updated model which no longer outputs the same format or the headers. Can I ask about the device or computer that is receiving this data? Does that have software of its own that can be modified? Adding a hardware box just to deal with a software protocol change seems pretty desperate. > The real problem is not the glitch, but that the failure remains until > the translator is reset. How about including a WDT that resets the circuit? Is it possible to tell if the CPU is even still running when the device locks up? > I'd be happy with a solid CPU in a good box. The current units are > hand wired, so who knows how well they are made? As a test, you could put in a laptop with an FTDI cable and see if that is able to keep the system happy. That's how we tested all our stuff with the POS interception thing that I mentioned. > This is the problem when one person designs something, then another > person has to make it work. You never know where the bodies are > buried. Yes, that's why getting a remote contractor involved for something this simple sounds like more trouble than it's worth. It's much more hassle than if the person is already there in your shop and is familiar with the product.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-01-17 14:47 -0800 |
| Message-ID | <d5419959-247d-4162-9ae4-bdabfe1c7e01n@googlegroups.com> |
| In reply to | #31550 |
On Tuesday, January 17, 2023 at 6:04:44 PM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.del...@gmail.com> writes: > > Once the error is observed, a power cycle is required to fix it. It's > > not a one time glitch. > Gack, yeah. I had been thinking, this isn't my area, but my > understanding is that the RS232 electrical spec requires voltages that > are somewhat above TTL logic levels, and that various crappy devices > skimp on these voltages and mostly work anyway. So that is a thing to > suspect if a home-brew RS232 device is acting flaky. It could be that > the device at the other end expects those voltages to be closer to the > real spec. They used a MAX3232CPE which generates it's own voltages using switched capacitor voltage boost. I wanted to check the values of the caps. Seems the have different minimum values depending on the Vcc voltage. But they are not in the BoM. I'll ask about this. It could easily be the cause of the problem. > > This is actually a patch added when the sensor was changed to an > > updated model which no longer outputs the same format or the headers. > Can I ask about the device or computer that is receiving this data? > Does that have software of its own that can be modified? Adding a > hardware box just to deal with a software protocol change seems pretty > desperate. "Desparate"? They just don't want to mess with the box that is receiving the data, not yet anyway. This was supposed to be an easy way to get it working with a minimum of fuss. It just didn't work out. > > The real problem is not the glitch, but that the failure remains until > > the translator is reset. > How about including a WDT that resets the circuit? Is it possible to > tell if the CPU is even still running when the device locks up? > > I'd be happy with a solid CPU in a good box. The current units are > > hand wired, so who knows how well they are made? > As a test, you could put in a laptop with an FTDI cable and see if that > is able to keep the system happy. That's how we tested all our stuff > with the POS interception thing that I mentioned. We have units that work. We have units that fail. I don't know what we would learn from using a laptop. > > This is the problem when one person designs something, then another > > person has to make it work. You never know where the bodies are > > buried. > Yes, that's why getting a remote contractor involved for something this > simple sounds like more trouble than it's worth. It's much more hassle > than if the person is already there in your shop and is familiar with > the product. If pigs had wings, they would fly. The only trouble is, they don't have wings. -- Rick C. -+ Get 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2023-01-17 15:32 -0800 |
| Message-ID | <874jsovisi.fsf@nightsong.com> |
| In reply to | #31551 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > "Desparate"? They just don't want to mess with the box that is > receiving the data, not yet anyway. Well, desperate in the sense that modifying software is usually easier than deploying and maintaining another physical computer, but I guess it depends on how hard it is to mess with that box. > We have units that work. We have units that fail. I don't know what > we would learn from using a laptop. If the laptop worked reliably it would show that the basic FTDI interface was sufficient. It would also allow spotting issues with the incoming data, etc. Someone on irc suggested using thin clients from ebay: https://www.ebay.com/itm/125720309804 They are cheap and plentiful, but maybe not the right look, as it were. > If pigs had wings, they would fly. The only trouble is, they don't > have wings. I just worry that if this is all special purpose hardware at the endpoints, making the gizmo work may involve checking levels with an oscilloscope and stuff like that, rather than being a pure software matter. The laptop could help test that theory.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-01-17 15:44 -0800 |
| Message-ID | <436e8b2e-86eb-4fad-a638-129e963b7e1dn@googlegroups.com> |
| In reply to | #31552 |
On Tuesday, January 17, 2023 at 7:32:51 PM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.del...@gmail.com> writes: > > "Desparate"? They just don't want to mess with the box that is > > receiving the data, not yet anyway. > Well, desperate in the sense that modifying software is usually easier > than deploying and maintaining another physical computer, but I guess it > depends on how hard it is to mess with that box. > > We have units that work. We have units that fail. I don't know what > > we would learn from using a laptop. > If the laptop worked reliably it would show that the basic FTDI > interface was sufficient. It would also allow spotting issues with the > incoming data, etc. ??? You seem to be missing the fact that there are existing units that do the job without a problem. The problem is linked to specific units. There's nothing to learn from using a laptop. I believe they have used a PC running Putty to capture data on the serial ports. You are looking where the light is better, in spite of the fact we know the problems not there. > Someone on irc suggested using thin clients from ebay: > > https://www.ebay.com/itm/125720309804 > > They are cheap and plentiful, but maybe not the right look, as it were. > > If pigs had wings, they would fly. The only trouble is, they don't > > have wings. > I just worry that if this is all special purpose hardware at the > endpoints, making the gizmo work may involve checking levels with an > oscilloscope and stuff like that, rather than being a pure software > matter. The laptop could help test that theory. You mean a laptop with an oscilloscope dongle? A digital measurement of the RS232 signals by a PC is not of much use if you don't know where the thresholds are. -- Rick C. +- Get 1,000 miles of free Supercharging +- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2023-01-17 16:04 -0800 |
| Message-ID | <87zgagu2ru.fsf@nightsong.com> |
| In reply to | #31553 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > There's nothing to learn from using a laptop. I believe they > have used a PC running Putty to capture data on the serial ports. Ok, same idea. > You mean a laptop with an oscilloscope dongle? I mean an scope with analog inputs to check voltages, timings, noise, etc. You have boxes that work and boxes that mostly work. What makes the boxes different from one another? It sounds like something somewhere is marginal. I hope this extreme an approach is not needed, but if custom hardware is involved and you have the final responsibility of getting everything working, you have to be ready for whatever it might take. I remember on the POS project, we had some kind of multi-channel logic analyzer for this purpose, though I don't remember using it. We also had some hacked up serial cables that let us monitor the traffic between two devices by tapping the TX and RX pins and bringing them out to a third DB9 plug that we connected to another computer. Those cables were very useful. I think I can figure out how they worked, but I've been wanting to ask the guy who built them, just to be sure.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-01-17 17:32 -0800 |
| Message-ID | <8abe2b4a-e755-44b1-a2ad-5491030a0f29n@googlegroups.com> |
| In reply to | #31554 |
On Tuesday, January 17, 2023 at 8:04:10 PM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.del...@gmail.com> writes: > > There's nothing to learn from using a laptop. I believe they > > have used a PC running Putty to capture data on the serial ports. > Ok, same idea. > > You mean a laptop with an oscilloscope dongle? > I mean an scope with analog inputs to check voltages, timings, noise, > etc. You have boxes that work and boxes that mostly work. What makes > the boxes different from one another? It sounds like something > somewhere is marginal. If you know anything about RS-232, you would know that it has margin on top of margin preventing marginal issues. The spec is that the voltages between +3V and -3V at the input of the receiver, while the driver is specified to drive at least ±5V. There's 2V margin. Then there's the fact that the actual threshold of the receiver is around 0.7V. I measured this once, but I don't recall the exact number, it might be more like 1.0V. The point is, there's another 2V margin. I've asked for the values of the caps on the MAX3232 chip. If one of those is out of spec, it could impact the drive capability. I don't have the units, so I can't put a scope on anything. > I hope this extreme an approach is not needed, but if custom hardware is > involved and you have the final responsibility of getting everything > working, you have to be ready for whatever it might take. > > I remember on the POS project, we had some kind of multi-channel logic > analyzer for this purpose, though I don't remember using it. We also > had some hacked up serial cables that let us monitor the traffic between > two devices by tapping the TX and RX pins and bringing them out to a > third DB9 plug that we connected to another computer. Those cables were > very useful. I think I can figure out how they worked, but I've been > wanting to ask the guy who built them, just to be sure. Not sure how a logic analyzer would help. That's for digital signals. You are talking about an analog issue. I would like to find some hardware appropriate to the task. I can't even find an Arduino compatible board that has an RS-232 level shifter chip on the board. Everyone just copies the same design. I also can't find any lower end MCU in an enclosure with two serial ports. Everything I've found is a hulking x86 compatible gadget with all sorts of high end interfaces, and only one serial port if any. I guess that's why the guy made his own box. But there are tons of RS-232 interface boards to use with the Arduino. I guess the fact that they have the DB-9 connector is a problem. -- Rick C. ++ Get 1,000 miles of free Supercharging ++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2023-01-17 20:02 -0800 |
| Message-ID | <87v8l4trqz.fsf@nightsong.com> |
| In reply to | #31555 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > Not sure how a logic analyzer would help. That's for digital signals. > You are talking about an analog issue. The logic analyzer for the POS thing was probably for debugging timing problems. I think it was able to timestamp more accurately than our software hack could. You are right that it wouldn't handle analog issues. > Everything I've found is a hulking x86 compatible gadget with all > sorts of high end interfaces, and only one serial port if any. There's a number of ARM boards with RS232 but that's just x86 in minuature, perhaps. Here is one with two RS232's, and again way more other stuff than you want: https://www.olimex.com/Products/ARM/NXP/LPC2378-STK/ Actually it looks like they have (had?) an AVR board with RS232 (single port, meh). It is out of stock though, and (who knows) maybe discontinued: https://www.olimex.com/Products/AVR/Development/AVR-CAN/ Were you thinking of using a single port and splitting out the TX and RX wires? That is a little bit too hacky imho. The company is in Bulgaria but some of their stuff is stocked by Digikey, so you could check there. Also maybe this? https://microcontrollershop.com/product_info.php?products_id=3517 Claims to have two uart ports and rs232 tranceiver chip, but uses JST-like connectors rather than DB9. Same processor as the generic ARM Bluepill though, and no extra ports other than USB. Hmm, this one has two DB9's: https://microcontrollershop.com/product_info.php?products_id=743 Anyway you can find other stuff there too. > But there are tons of RS-232 interface boards to use with the Arduino. > I guess the fact that they have the DB-9 connector is a problem. I think stuff these days tends to use USB, which is its own can of worms, but it is easy to get USB to serial converter cables. There is this though, 1 port: https://microcontrollershop.com/product_info.php?products_id=5579
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-01-17 20:24 -0800 |
| Message-ID | <74ba3bd0-bf07-475e-9ac0-5c2edfe1f30bn@googlegroups.com> |
| In reply to | #31556 |
On Wednesday, January 18, 2023 at 12:02:22 AM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.del...@gmail.com> writes: > > Not sure how a logic analyzer would help. That's for digital signals. > > You are talking about an analog issue. > The logic analyzer for the POS thing was probably for debugging timing > problems. I think it was able to timestamp more accurately than our > software hack could. You are right that it wouldn't handle analog > issues. > > Everything I've found is a hulking x86 compatible gadget with all > > sorts of high end interfaces, and only one serial port if any. > There's a number of ARM boards with RS232 but that's just x86 in > minuature, perhaps. Here is one with two RS232's, and again way more > other stuff than you want: > > https://www.olimex.com/Products/ARM/NXP/LPC2378-STK/ > > Actually it looks like they have (had?) an AVR board with RS232 (single > port, meh). It is out of stock though, and (who knows) maybe > discontinued: > > https://www.olimex.com/Products/AVR/Development/AVR-CAN/ > > Were you thinking of using a single port and splitting out the TX and RX > wires? That is a little bit too hacky imho. > > The company is in Bulgaria but some of their stuff is stocked by > Digikey, so you could check there. > > Also maybe this? > > https://microcontrollershop.com/product_info.php?products_id=3517 > > Claims to have two uart ports and rs232 tranceiver chip, but uses > JST-like connectors rather than DB9. Same processor as the generic ARM > Bluepill though, and no extra ports other than USB. > > Hmm, this one has two DB9's: > > https://microcontrollershop.com/product_info.php?products_id=743 > > Anyway you can find other stuff there too. > > But there are tons of RS-232 interface boards to use with the Arduino. > > I guess the fact that they have the DB-9 connector is a problem. > I think stuff these days tends to use USB, which is its own can of > worms, but it is easy to get USB to serial converter cables. > > There is this though, 1 port: > > https://microcontrollershop.com/product_info.php?products_id=5579 I guess I'm getting tired. If I'm buying a board, one serial port is fine. UARTs are two separate devices, a transmitter and a receiver. They are not connected other than sharing the same bit rate and other format configuration, perhaps. The only reason for wanting two serial ports would be when buying a box level product, since external wiring is simpler with two cables, rather than a Y cable ARM boards would be fine, but I'm not making a box, so I guess this will be someone else's problem. I'm very surprised Digikey and Mouser don't carry a box device like this. They have lots of embedded computers, but they are like a PC in a small case. Some are like rPi's, with ARM processors, but still too messy dealing with a complex processor and an OS. -- Rick C. --- Get 1,000 miles of free Supercharging --- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2023-01-17 20:56 -0800 |
| Message-ID | <87r0vstp93.fsf@nightsong.com> |
| In reply to | #31557 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > I'm very surprised Digikey and Mouser don't carry a box device like > this. It is weird, there must be something like that, but product search everywhere is terrible. I notice there is a new stackexchange for hardware recommendations: https://hardwarerecs.stackexchange.com/ It doesn't look that great, but who knows. > Some are like rPi's, with ARM processors, but still too messy dealing > with a complex processor and an OS. If you can power it up and get a linux shell and run gcc, that is pretty easy to deal with. You don't have to worry about the amount of software underneath the shell prompt, you don't have to worry about UART device registers since the OS handles that, etc. I do understand that it is hardware overkill despite this.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-01-17 22:30 -0800 |
| Message-ID | <b1186816-33e6-4764-9bd4-75b3e926fa61n@googlegroups.com> |
| In reply to | #31558 |
On Wednesday, January 18, 2023 at 12:56:13 AM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.del...@gmail.com> writes: > > I'm very surprised Digikey and Mouser don't carry a box device like > > this. > It is weird, there must be something like that, but product search > everywhere is terrible. I notice there is a new stackexchange for > hardware recommendations: > > https://hardwarerecs.stackexchange.com/ Ok, I've posted there. Thanks. > It doesn't look that great, but who knows. > > Some are like rPi's, with ARM processors, but still too messy dealing > > with a complex processor and an OS. > If you can power it up and get a linux shell and run gcc, that is pretty > easy to deal with. That's not really true. One way of making an MCU robust, is to reboot it periodically. If it can reboot in less than a second, it can do this job while invisibly rebooting. It takes significant time to reboot an rPi. There's ZERO reason to bother with more complex hardware that still doesn't have RS-232 I/Os or a case. > You don't have to worry about the amount of software > underneath the shell prompt, you don't have to worry about UART device > registers since the OS handles that, etc. I do understand that it is > hardware overkill despite this. No, no reason to worry about any of that, because an OS is not going to be in the device. -- Rick C. --+ Get 1,000 miles of free Supercharging --+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2023-01-18 00:37 -0800 |
| Message-ID | <87mt6gtf0v.fsf@nightsong.com> |
| In reply to | #31559 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > That's not really true. One way of making an MCU robust, is to reboot > it periodically. If it can reboot in less than a second, it can do > this job while invisibly rebooting. It takes significant time to > reboot an rPi. So have it auto-reboot at night. More seriously, the thing that fails the most on Rpi-style boards is the SD card. If you have a board that doesn't use an SD card, it can be pretty robust. > No, no reason to worry about any of that, because an OS is not going > to be in the device. Of course the Arduino library is sort of an OS, if you use it. I still worry a little about whatever is making your existing box fail. If you can isolate it to those capacitors or whatever it was, that is great. Otherwise maybe you have to be ready for the possibility of installing a ready-made box with properly working RS232 ports and still finding that it occasionally fails the same way. Regarding the boxed microcomputer, someone on the Forth group might know of a suitable product? It's the type of thing they might be using.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-01-18 04:43 -0800 |
| Message-ID | <f205ccdc-09f4-4d55-9f6c-9a9c9accb273n@googlegroups.com> |
| In reply to | #31560 |
On Wednesday, January 18, 2023 at 4:37:13 AM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.del...@gmail.com> writes: > > That's not really true. One way of making an MCU robust, is to reboot > > it periodically. If it can reboot in less than a second, it can do > > this job while invisibly rebooting. It takes significant time to > > reboot an rPi. > So have it auto-reboot at night. More seriously, the thing that fails > the most on Rpi-style boards is the SD card. If you have a board that > doesn't use an SD card, it can be pretty robust. So potentially lose an entire day of data? LOL > > No, no reason to worry about any of that, because an OS is not going > > to be in the device. > Of course the Arduino library is sort of an OS, if you use it. Now this is getting silly. > I still worry a little about whatever is making your existing box fail. > If you can isolate it to those capacitors or whatever it was, that is > great. Otherwise maybe you have to be ready for the possibility of > installing a ready-made box with properly working RS232 ports and still > finding that it occasionally fails the same way. Yes, and I would still need to worry about it being stepped on by a dinosaur. > Regarding the boxed microcomputer, someone on the Forth group might know > of a suitable product? It's the type of thing they might be using. Maybe. -- Rick C. -+- Get 1,000 miles of free Supercharging -+- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2023-01-18 14:19 -0800 |
| Message-ID | <87edrrtrj4.fsf@nightsong.com> |
| In reply to | #31563 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: >> More seriously, the thing that fails the most on Rpi-style boards is >> the SD card. > So potentially lose an entire day of data? LOL Does that refer to the SD card failing? I didn't realize you were envisioning saving any data on the Pi. If you were using a RPi type of board presumably you'd upload incoming data (maybe over a network) as it arrived. But that is far away from the Arduino approach. > Yes, and I would still need to worry about it being stepped on by a > dinosaur. Ok, so it sounds like you are confident that something is really wrong with the Arduino boxes that are failing. Seems reasonable.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-01-18 23:15 -0800 |
| Message-ID | <e654f835-d4b7-437c-9347-0377f8110176n@googlegroups.com> |
| In reply to | #31570 |
On Wednesday, January 18, 2023 at 6:19:16 PM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.del...@gmail.com> writes: > >> More seriously, the thing that fails the most on Rpi-style boards is > >> the SD card. > > So potentially lose an entire day of data? LOL > Does that refer to the SD card failing? I didn't realize you were > envisioning saving any data on the Pi. If you were using a RPi type of > board presumably you'd upload incoming data (maybe over a network) as it > arrived. But that is far away from the Arduino approach. > > Yes, and I would still need to worry about it being stepped on by a > > dinosaur. > Ok, so it sounds like you are confident that something is really wrong > with the Arduino boxes that are failing. Seems reasonable. I don't think we are communicating at all. When the glitch happens, no further data is sent to the recipient, until the translator is reset. At this point, you have some idea in your mind as to what has been designed, that seems to not match reality. Sorry if I've misled you. -- Rick C. +-+ Get 1,000 miles of free Supercharging +-+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2023-01-19 12:21 -0800 |
| Message-ID | <871qnqtgv8.fsf@nightsong.com> |
| In reply to | #31571 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > When the glitch happens, no further data is sent to the recipient, > until the translator is reset. At this point, you have some idea in > your mind as to what has been designed, that seems to not match > reality. I think I understand what has been designed. What I don't have is any solid idea of what is going wrong. I therefore can't infer that the mysterious problem won't also affect other hardware. If you're not worried about that, then fine. Your judgment is better than mine when it comes to stuff like that.
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web