Boxed MCU with RS-232 Port

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 &plusmn;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

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

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

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.

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

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.

On 17/01/2023 21:19, Rick C wrote:

> 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.

You mean "\r" and "\n" here - programming is fussy about the details!

When counting line endings, I usually accept either character, and if 
"\r" is received then a following "\n" is ignored (and vice versa - some 
people get things wrong and send "\n\r").

The standard for DOS is "\r\n", the standard for *nix is "\n", and the 
standard for old Macs is "\r".  I would not be happy simply counting 
"\r" characters unless I was sure the incoming data always used carriage 
returns - if I were to pick just one character, it would be "\n".  But 
checking for either is best.

Data corruption is always something you have to consider.  Sometimes you 
can't do much about it, and will just pass on the mess - or skip it 
until the data looks good again.  But you at least want to make sure 
there are no buffer overflows if a line ending is missed!

On 2023-01-17, Rick C <gnuarm.deletethisbit@gmail.com> wrote:
> On Tuesday, January 17, 2023 at 6:04:44 PM UTC-4, Paul Rubin wrote:
>> 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.

That was my first thought as well so I looked it up to double check.
The MAX3232CPE is 0.1uF across the board so far as I can see.  You
do hit problems with MAX232's - the original needed 1uF caps but
the MAX232A and several alternate manufacturers specify 0.1uF as
a minimum.  Problems can arise if a MAX232 is put in place of one
of the alternatives but with the 3232 I'd expect people to get it
right.

OTOH the 3232 is a 3.3V compatible part.  One thing they all have
in common is the charge pumps are a bit weedy in terms of voltage,
aiming for +/-5.5V regardless of supply voltage.  That's within
current specs but the RS232 minimum voltages have dropped over the
years, I suppose it's possible the port of the receiver is an
older design.  In any case it doesn't leave particularly large
headroom for losses.  Do you know if the protocol translator is on
a 3.3v or 5v supply? If the latter a MAX232A (note the A) is a
drop-in replacement with typical +/-10V drive.  If 3.3V a booster
of some form will eliminate low voltage as an issue - in terms of
off the shelf hardware that would probably be a pair of RS232<>RS422
line extenders back to back.

-- 
Andrew Smallshaw
andrews@sdf.org

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

On Wednesday, January 18, 2023 at 8:16:01 AM UTC-4, Andrew Smallshaw wrote:
> On 2023-01-17, Rick C <gnuarm.del...@gmail.com> wrote: 
> > On Tuesday, January 17, 2023 at 6:04:44 PM UTC-4, Paul Rubin wrote: 
> >> 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.
> That was my first thought as well so I looked it up to double check. 
> The MAX3232CPE is 0.1uF across the board so far as I can see. You 
> do hit problems with MAX232's - the original needed 1uF caps but 
> the MAX232A and several alternate manufacturers specify 0.1uF as 
> a minimum. Problems can arise if a MAX232 is put in place of one 
> of the alternatives but with the 3232 I'd expect people to get it 
> right. 

The data sheet I saw has a table of minimum capacitance for three Vcc ranges, 3.3V, 5V and 3.3 to 5V approximately.  Only 3.3V was 0.1 uF on all caps.  The others were larger on at least one cap.  Table 9-1 on page 12. 


> OTOH the 3232 is a 3.3V compatible part. One thing they all have 
> in common is the charge pumps are a bit weedy in terms of voltage, 
> aiming for +/-5.5V regardless of supply voltage. That's within 
> current specs but the RS232 minimum voltages have dropped over the 
> years, I suppose it's possible the port of the receiver is an 
> older design. 

You mean the RS-232 (TIA/EIAI) specification has changed?  I have not seen this. 


> In any case it doesn't leave particularly large 
> headroom for losses. Do you know if the protocol translator is on 
> a 3.3v or 5v supply? If the latter a MAX232A (note the A) is a 
> drop-in replacement with typical +/-10V drive. If 3.3V a booster 
> of some form will eliminate low voltage as an issue - in terms of 
> off the shelf hardware that would probably be a pair of RS232<>RS422 
> line extenders back to back. 

5V supply.  I don't know why you are talking about the MAX232.  I've said "MAX3232CPE" several times.  

-- 

Rick C.

-++ Get 1,000 miles of free Supercharging
-++ Tesla referral code - https://ts.la/richard11209