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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-03-24 20:01 -0700 |
| Message-ID | <86ce9d8f-6ed7-4b4f-b787-38511688a4d9n@googlegroups.com> |
| In reply to | #31699 |
On Friday, March 24, 2023 at 10:44:06 PM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.del...@gmail.com> writes: > > You are providing links to hardware. I'm asking you which pin is data > > out and which pin is data in? This is a very simple question, no? > Didn't I answer? I wrote: > > >> The transmit pin (TXD, pin 2 in that table) is the output and the > >> receive pin (RXD, pin 3) is the input. > Pin 2 = data out, pin 3 = data in. Is something missing from that > answer? There is a possibility that it is wrong and that the two are > switched, but that would show up immediately during testing. > >> A splitter cable? I thought I posted a url to order those from. > > Do you know if that splitter will work for this application? > It sounded to me like it should, but part of the task is to put the > stuff together and test it. Yeah, that's just what engineers do. They throw some stuff together and test it, over and over, rather than actually understanding the requirements. I'm trying to get you to understand the issues, but you just aren't getting it. I don't know how a cable I have no info on is wired. But if pin 3 on the CPU connector goes to pin 2 on both of the cable connectors, then it's not likely to work properly is it? Two drivers on the same pin sound like a bad idea to me. > Anyway I think it is better to use a board > with two uarts. I checked, and the Arduino Leonardo has two, so it > sounds like that is a suitable board if you want to use the Arduino > approach. Does it have RS-232 driver chips? > > Can't use a USB dongle if there's no USB software. > The USB software is present in the boards that have USB host ports. I would hope so. Do any of the boards you are talking about have USB host ports? Typically the small CPU boards use a USB to serial port chip to support bootloading, with no drivers on the CPU to host USB. > >> >> TTL to RS232 (?): https://www.sparkfun.com/products/449 > >> >> Similar: https://www.waveshare.com/wiki/RS232_Board > >> > I don't know why you are showing all these devices. > >> There are tons of cpus with built in UARTs > > > > Having a UART is not sufficient. The interface needs to be a DB9 > > male, RS-232 voltage levels. One connector for the input data, and > > one connector for the output data. > Right, that is the purpose of those boards that I linked. To convert > TTL levels to RS232 levels. You connect the UART to the level converter > board. That is pretty much the same thing that you already did with the > homemade MAX232(?) PCB, thus the idea of swapping in this other board > and seeing if it works where your existing one doesn't. > > That is far outside your concern. > I am glad to hear this. So what happens if I ship you boxes that I've > tested on my bench and that supply the right voltages as shown on a > scope, but only half of them work at the customer site, like with your > boards? Who is responsible? I think that is something we can worry about later. So far, I'm not sure you can produce any boxes. > > Have you picked one yet? > The Leonardo looks good to me but obviously I would want to test an > evaluation unit before settling on it. > > Does the splitter cable run a signal to pins 2 and 3 on both cables? > > I've yet to find one that connects to pin 2 on one connector and pin 3 > > on the other connector, leaving the other pins 2 and 3 unconnected. > I would have to check that. However, disconnecting pin 2 or 3 can in a > cable like that can be done with a wire cutter. > > I think you will find the splitter cable will need to be a custom > > design. It's probably easier to just use a CPU without a DB9 and > > build a cable to run from the header to the two DB9s on the box. But > > then you will need a CPU card with RS232 level shifters. > The suggestion further up is to use that level shifter card. > > This is why I don't want to do the design. It's messy and far too > > much work for something so simple. > Yes, that's why nobody else wanted to do it either until you mentioned a > figure of $300 per box. That is enough to cover the necessary amount of > derping around that always afflicts a project like this. You've done a > lot more hardware stuff than I have, so I shouldn't be the one who has > to explain that. When you get the details worked out, and wish to discuss a price, let me know through email. Thanks -- 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-03-24 21:18 -0700 |
| Message-ID | <87cz4xh3ac.fsf@nightsong.com> |
| In reply to | #31700 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > I'm trying to get you to understand the issues, but you just aren't > getting it. I don't know how a cable I have no info on is wired. But > if pin 3 on the CPU connector goes to pin 2 on both of the cable > connectors, then it's not likely to work properly is it? Two drivers > on the same pin sound like a bad idea to me. Again there is a 3 step process going on: 1) note that a product of this sort exists, without remembering too much detail about it. 2) find the product description page again, and this time study it carefully including the pin diagrams, to develop a theory of whether it does the right thing and which pins to connect or disconnect. 3) actually buy the cable and test the theory. Right now we are at step 1. I think it is best to avoid the whole thing though. The approach of splitting the pins out from a single port is too kludgy, if it is at all practical to use two ports. > [Arduino Leonardo] Does it have RS-232 driver chips? No it does not. That is why I linked those level shifter cards. > I would hope so. Do any of the boards you are talking about have USB > host ports? The ESP32-S2 has it. Here are the API docs: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-reference/peripherals/usb_host.html The CDC (communication device class) software is here: https://github.com/espressif/esp-idf/tree/master/examples/peripherals/usb/host/cdc/cdc_acm_vcp It looks like a potential pain in the neck to use. I currently have an Adafruit Feather board with that chip so maybe I will try it. The chip also supports wifi and bluetooth, fwiw. The software stacks for both of those are way more complicated than USB. > When you get the details worked out, and wish to discuss a price, let > me know through email. OK.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2023-03-24 15:35 -0700 |
| Message-ID | <tvl8jl$1rn25$3@dont-email.me> |
| In reply to | #31684 |
On 3/24/2023 8:08 AM, Rick C wrote: >> Although for quantity 20 at these kind of price points, I might be tempted >> to build something using dev boards, eg: >> https://www.dfrobot.com/product-1030.html >> and maybe a bit of 3D printing for an enclosure. For two of those boards >> you might need to hand-patch one to use different pins, but it's not hard >> and could be done. > > This device is exactly what makes this difficult. Which pin on the DB9 is the data output? "Nominal" signal directions are specified from the standpoint of the *DTE*. Remember that one rule and everything else falls into place. I.e., a DCE *receives* data on the "Transmit Data" pin and transmits on the "Receive Data" pin. [Null Modem cables came into being because DTEs wanted to talk to DTEs. So, *both* want to transmit on the TxD signal -- and thus need a pin swap in the cable to connect out-to-in and in-to-out... even though both are TxD] DTE, by convention, use *male* connectors. That's the second thing to remember. Identify pin #1. Count sideways to the next pin; that will be RxD -- the INPUT for the DTE device. The next pin will be TxD -- the OUTPUT for the DTE device. (This for a DB9; using a DB25 changes this relative order). It's not that hard (though folks tend to confuse themselves by getting the frame of reference wrong -- esp when looking at UART chipsets that want to label their pins TxD and RxD -- even if they are wired to RxD and TxD, respectively, on the DB9, as is the case when implementing a DCE). Folks have historically bastardized all of these conventions -- for "good reasons" (or, so they thought). But, a device (module) designed for general use IN THE 21st CENTURY should have been designed with some adherence to convention (i.e., male connector for DTE, female for DCE; DTE transmits on TxD, DCE transmits on RxD). It's highly unlikely that you're going to find a device that handshakes using SRTS or RLSD! The roles of the control signals can quickly become confused as older kit uses them in the original *interlocked* fashion of RS232C while newer interpretations of the standard(s) have altered that behavior (because most devices aren't as pathetically slow as 103 modems!) [But, I think TWX, TELEX, et al. are long dead and gone]
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-03-24 18:21 -0700 |
| Message-ID | <cc45a881-41d4-4f9d-bda1-11cd72c6d3d1n@googlegroups.com> |
| In reply to | #31693 |
On Friday, March 24, 2023 at 6:35:39 PM UTC-4, Don Y wrote: > On 3/24/2023 8:08 AM, Rick C wrote: > > >> Although for quantity 20 at these kind of price points, I might be tempted > >> to build something using dev boards, eg: > >> https://www.dfrobot.com/product-1030.html > >> and maybe a bit of 3D printing for an enclosure. For two of those boards > >> you might need to hand-patch one to use different pins, but it's not hard > >> and could be done. > > > > This device is exactly what makes this difficult. Which pin on the DB9 is the data output? > "Nominal" signal directions are specified from the standpoint of the *DTE*. > Remember that one rule and everything else falls into place. I.e., a DCE > *receives* data on the "Transmit Data" pin and transmits on the "Receive > Data" pin. > > [Null Modem cables came into being because DTEs wanted to talk to DTEs. > So, *both* want to transmit on the TxD signal -- and thus need a pin > swap in the cable to connect out-to-in and in-to-out... even though > both are TxD] > > DTE, by convention, use *male* connectors. That's the second thing to > remember. > > Identify pin #1. Count sideways to the next pin; that will be RxD -- the > INPUT for the DTE device. The next pin will be TxD -- the OUTPUT for the > DTE device. (This for a DB9; using a DB25 changes this relative order). > > It's not that hard (though folks tend to confuse themselves by getting > the frame of reference wrong -- esp when looking at UART chipsets > that want to label their pins TxD and RxD -- even if they are wired to > RxD and TxD, respectively, on the DB9, as is the case when implementing > a DCE). > > Folks have historically bastardized all of these conventions -- for > "good reasons" (or, so they thought). But, a device (module) designed > for general use IN THE 21st CENTURY should have been designed with some > adherence to convention (i.e., male connector for DTE, female for DCE; > DTE transmits on TxD, DCE transmits on RxD). It's highly unlikely > that you're going to find a device that handshakes using SRTS or RLSD! > > The roles of the control signals can quickly become confused as older > kit uses them in the original *interlocked* fashion of RS232C while > newer interpretations of the standard(s) have altered that behavior > (because most devices aren't as pathetically slow as 103 modems!) > > [But, I think TWX, TELEX, et al. are long dead and gone] Excellent Don. Now, please tell me which unit is the DCE and which is the DTE? Or better yet, just answer the question asked, on this device, which pin on the DB9 connector is the data output and which is the data input? -- Rick C. ---++ Get 1,000 miles of free Supercharging ---++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2023-03-24 19:21 -0700 |
| Message-ID | <tvllr7$1tkto$2@dont-email.me> |
| In reply to | #31695 |
On 3/24/2023 6:21 PM, Rick C wrote: > On Friday, March 24, 2023 at 6:35:39 PM UTC-4, Don Y wrote: >> On 3/24/2023 8:08 AM, Rick C wrote: >> >>>> Although for quantity 20 at these kind of price points, I might be tempted >>>> to build something using dev boards, eg: >>>> https://www.dfrobot.com/product-1030.html >>>> and maybe a bit of 3D printing for an enclosure. For two of those boards >>>> you might need to hand-patch one to use different pins, but it's not hard >>>> and could be done. >>> >>> This device is exactly what makes this difficult. Which pin on the DB9 is the data output? >> "Nominal" signal directions are specified from the standpoint of the *DTE*. >> Remember that one rule and everything else falls into place. I.e., a DCE >> *receives* data on the "Transmit Data" pin and transmits on the "Receive >> Data" pin. >> >> [Null Modem cables came into being because DTEs wanted to talk to DTEs. >> So, *both* want to transmit on the TxD signal -- and thus need a pin >> swap in the cable to connect out-to-in and in-to-out... even though >> both are TxD] >> >> DTE, by convention, use *male* connectors. That's the second thing to >> remember. >> >> Identify pin #1. Count sideways to the next pin; that will be RxD -- the >> INPUT for the DTE device. The next pin will be TxD -- the OUTPUT for the >> DTE device. (This for a DB9; using a DB25 changes this relative order). >> >> It's not that hard (though folks tend to confuse themselves by getting >> the frame of reference wrong -- esp when looking at UART chipsets >> that want to label their pins TxD and RxD -- even if they are wired to >> RxD and TxD, respectively, on the DB9, as is the case when implementing >> a DCE). >> >> Folks have historically bastardized all of these conventions -- for >> "good reasons" (or, so they thought). But, a device (module) designed >> for general use IN THE 21st CENTURY should have been designed with some >> adherence to convention (i.e., male connector for DTE, female for DCE; >> DTE transmits on TxD, DCE transmits on RxD). It's highly unlikely >> that you're going to find a device that handshakes using SRTS or RLSD! >> >> The roles of the control signals can quickly become confused as older >> kit uses them in the original *interlocked* fashion of RS232C while >> newer interpretations of the standard(s) have altered that behavior >> (because most devices aren't as pathetically slow as 103 modems!) >> >> [But, I think TWX, TELEX, et al. are long dead and gone] > > Excellent Don. Now, please tell me which unit is the DCE and which is the DTE? Or better yet, just answer the question asked, on this device, which pin on the DB9 connector is the data output and which is the data input? "Nominal" signal directions are specified from the standpoint of the *DTE*. Remember that one rule and everything else falls into place. I.e., a DCE *receives* data on the "Transmit Data" pin and transmits on the "Receive Data" pin. DTE, by convention, use *male* connectors. That's the second thing to remember.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2023-03-25 21:42 -0400 |
| Message-ID | <1q7v1i9esk6kevvk3um2qf8461a40odt5o@4ax.com> |
| In reply to | #31695 |
On Fri, 24 Mar 2023 18:21:21 -0700 (PDT), Rick C <gnuarm.deletethisbit@gmail.com> wrote: >Excellent Don. Now, please tell me which unit is the DCE and which is >the DTE? Or better yet, just answer the question asked, on this >device, which pin on the DB9 connector is the data output and which >is the data input? "Terminal Equipment" (TE) vs "Communications Equipment" (CE). DTE is the computer (terminal), DCE is the modem. To adhere to the RS-232 conventions, your external device has to be "communications equipment". Don explained the cables and how the signaling works. DTE transmits on TxD, and receives on RxD. DCE does the reverse. Which physical pins these are on depends on the form factor: DB9 or DB25. RS-232 pinout diagrams are very easy to find. Try Google.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-03-25 19:26 -0700 |
| Message-ID | <ee346548-554a-4f03-8222-7568117fe9e2n@googlegroups.com> |
| In reply to | #31702 |
On Saturday, March 25, 2023 at 9:42:21 PM UTC-4, George Neuner wrote: > On Fri, 24 Mar 2023 18:21:21 -0700 (PDT), Rick C > <gnuarm.del...@gmail.com> wrote: > > >Excellent Don. Now, please tell me which unit is the DCE and which is > >the DTE? Or better yet, just answer the question asked, on this > >device, which pin on the DB9 connector is the data output and which > >is the data input? > "Terminal Equipment" (TE) vs "Communications Equipment" (CE). > > DTE is the computer (terminal), DCE is the modem. To adhere to the > RS-232 conventions, your external device has to be "communications > equipment". > > Don explained the cables and how the signaling works. DTE transmits on > TxD, and receives on RxD. DCE does the reverse. Which physical pins > these are on depends on the form factor: DB9 or DB25. > > RS-232 pinout diagrams are very easy to find. Try Google. You are confused. I don't need any information about RS-232. Everything you are talking about is irrelevant. Virtually NO ONE uses RS-232 to connect DCE to DTE. They simply are tying together two devices that wish to use asynch serial at RS-232 voltage levels. But neither you nor Don seem to understand that. I was trying to lead Don to this conclusion by asking pointed questions, but that failed. You, however, seem to have the same problem Don does. I often have this problem with people who don't actually understand how RS-232 is used. There are people who view the world through data sheets and specification standards. Then there's the real world, where you have to toss out some of that, and ask questions like, "Which pin is output and which pin is input?" If the person you are talking to gives you anything other than a pin number, you are talking to the wrong person. Engineers design stuff. Technicians figure out how to make it work. -- Rick C. --++- Get 1,000 miles of free Supercharging --++- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Jim Jackson <jj@franjam.org.uk> |
|---|---|
| Date | 2023-03-26 18:27 +0000 |
| Message-ID | <slrnu213js.2m8.jj@iridium.wf32df> |
| In reply to | #31703 |
On 2023-03-26, Rick C <gnuarm.deletethisbit@gmail.com> wrote: > > I often have this problem with people who don't actually understand > how RS-232 is used. There are people who view the world through data > sheets and specification standards. Then there's the real world, > where you have to toss out some of that, and ask questions like, > "Which pin is output and which pin is input?" If the person you are > talking to gives you anything other than a pin number, you are talking > to the wrong person. Many years ago I often had to connect up gear with RS232 interfaces, and it was a pain, as there was often no manual for the gear or the manual was badly written and the author used the RS232 "standard" terms in a cavalier way. So I used an RS232 breakout box to try and identify RXD and TXD, and what the various pins did, and what had to be strapped to what to get either end to speak! Oh happy days - NOT! Good luck with the project.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2023-03-26 13:23 -0700 |
| Message-ID | <tvq9jk$2remq$3@dont-email.me> |
| In reply to | #31706 |
On 3/26/2023 11:27 AM, Jim Jackson wrote: > Many years ago I often had to connect up gear with RS232 interfaces, and > it was a pain, as there was often no manual for the gear or the manual > was badly written and the author used the RS232 "standard" terms in a > cavalier way. Folks who haven't designed communications equipment where RS232 (in its various bastardized forms) don't understand that commenting on a product chosen (seemingly) at random from a producer of unknown character is pure folly. Simply because the folks who design said pieces of kit are operating often in ignorance -- trying to make a device that mates with X instead of a device that conforms to a standard. This is a common problem when folks try to "bottom feed". > So I used an RS232 breakout box to try and identify RXD and TXD, and > what the various pins did, and what had to be strapped to what to get > either end to speak! Oh happy days - NOT! There were "magic (active) cables" produced years ago that would, automatically, adapt to common pinout incompatibilities. But, "common" is the operative word, here. And, if you were in a market where *many* of the pins on a DB25 were active, they were just toy solutions. Just getting the pinout to *appear* correct is only part of the story. You also need to know how they have implemented the signaling protocol and the timing thereof (see my reply to George, upthread) I have encountered devices made by "established companies" that use all sorts of different signaling schemes as well as pinouts. As I mentioned in an earlier post, seeing SRTS used for flow control, or RLSD, etc. I'm sure there's a reason they made these bastardizations but, regardless, I had to live with it as the vendor isn't going to "fix" his implementation just to satisfy my beliefs. As I have had to design many such devices, over the years, to interact with many *other* devices (they having undisclosed design goals), I quickly learned to accumulate a set of "widgets" that would allow me to quickly make common signal swaps. Then, once each end of the link looked like a DCE or DTE, a straight-through cable solved the ELECTRICAL problem. [E.g., I can understand APC's bastardization, below. Almost. Yet, feel they could have implemented the feature set in a more compatible way...] I build these into connector shells that are designed to support a pair of back-to-back connectors (DB9 or 25) and then affix a label telling me the device that it is intended to normalize (e.g., I have one at my feet that "fixes" APC's UPS serial port) *or* the function it is intended to perform (gender change, NULL modem, NULL 'terminal'!, etc.) An early employer (specializing in comms kit!) had a huge box full of assorted (and undocumented) cables. One of the first chores on any project was finding a suitable cable to mate to the device in question. This involved untangling dozens of cords and *trying* each, in turn, until some signs of life appeared. Then, refining the selection. I pitched the idea of the small (2"x2") widgets paired with a straight-through cable. Discard the box of random wire and keep a shoebox full of the little widgets -- and ONLY straight through, M-F cables. Sometimes I have to stack a few "widgets" to get the requisite signal pairing. But, then know how to make a new widget that is tailored to THIS device (and labeled as such) > Good luck with the project.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2023-03-26 13:32 -0700 |
| Message-ID | <tvqa5a$2remq$4@dont-email.me> |
| In reply to | #31709 |
On 3/26/2023 1:23 PM, Don Y wrote:
> I build these into connector shells that are designed to support a
> pair of back-to-back connectors (DB9 or 25) and then affix a label
> telling me the device that it is intended to normalize (e.g., I have
> one at my feet that "fixes" APC's UPS serial port) *or* the function
> it is intended to perform (gender change, NULL modem, NULL 'terminal'!,
> etc.)
This is the APC widget mentioned:
<https://mega.nz/file/J35SBBob#FtQznCDovhBZHJdA5OspHdMo6_DiDMjQwtCqnh3Oa54>
By (my) convention, the named device ("UPS") is located at the
connector from which the label can be read (i.e., the connector
to the right).
The jack screws -- in the context of that device -- act as a further
hint.
If I want to know what's inside, I have to look up the schematic
for the widget -- unless the function is obvious (e.g., gender
change).
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2023-03-26 13:52 -0700 |
| Message-ID | <tvqbaq$2remq$6@dont-email.me> |
| In reply to | #31710 |
On 3/26/2023 1:32 PM, Don Y wrote: > On 3/26/2023 1:23 PM, Don Y wrote: >> I build these into connector shells that are designed to support a >> pair of back-to-back connectors (DB9 or 25) and then affix a label >> telling me the device that it is intended to normalize (e.g., I have >> one at my feet that "fixes" APC's UPS serial port) *or* the function >> it is intended to perform (gender change, NULL modem, NULL 'terminal'!, >> etc.) > > This is the APC widget mentioned: > <https://mega.nz/file/J35SBBob#FtQznCDovhBZHJdA5OspHdMo6_DiDMjQwtCqnh3Oa54> And this is the COTS *PC* that I use as a name server: <https://mega.nz/file/Fi4hEACJ#YgVZ5tdZBjTcwW76gXC2vdgv5M6u4lTpUDAwu53Z9n8> Note the *two* serial ports (DTE as the standard dictates), 100BaseT network connection (it's just a name server, it doesn't need to have high throughput), PS/2 keyboard and VGA (cuz it's a PC!), wifi and USB. The four mounting holes visible are the VESA standard (I have these mounted between my monitor and support arm) As an ISA PC, it will run damn near any OS intended for such a platform (I run NetBSD on this box). So, all of the PC hosted AND TARGETED tools are available (I have a LFC monitor wired to one of the serial ports to discipline my time service as that was easier/cheaper to implement than any other solution!).
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-03-26 19:30 -0700 |
| Message-ID | <1df505f0-3b7f-4760-96fd-24329bd9757an@googlegroups.com> |
| In reply to | #31712 |
On Sunday, March 26, 2023 at 4:52:48 PM UTC-4, Don Y wrote: > On 3/26/2023 1:32 PM, Don Y wrote: > > On 3/26/2023 1:23 PM, Don Y wrote: > >> I build these into connector shells that are designed to support a > >> pair of back-to-back connectors (DB9 or 25) and then affix a label > >> telling me the device that it is intended to normalize (e.g., I have > >> one at my feet that "fixes" APC's UPS serial port) *or* the function > >> it is intended to perform (gender change, NULL modem, NULL 'terminal'!, > >> etc.) > > > > This is the APC widget mentioned: > > <https://mega.nz/file/J35SBBob#FtQznCDovhBZHJdA5OspHdMo6_DiDMjQwtCqnh3Oa54> > And this is the COTS *PC* that I use as a name server: > <https://mega.nz/file/Fi4hEACJ#YgVZ5tdZBjTcwW76gXC2vdgv5M6u4lTpUDAwu53Z9n8> > > Note the *two* serial ports (DTE as the standard dictates), 100BaseT > network connection (it's just a name server, it doesn't need to > have high throughput), PS/2 keyboard and VGA (cuz it's a PC!), > wifi and USB. The four mounting holes visible are the VESA standard > (I have these mounted between my monitor and support arm) > > As an ISA PC, it will run damn near any OS intended for such > a platform (I run NetBSD on this box). So, all of the PC hosted > AND TARGETED tools are available (I have a LFC monitor wired to > one of the serial ports to discipline my time service as that > was easier/cheaper to implement than any other solution!). Wow! He's gone from making overly verbose posts with far more description than needed, to making replies to himself, neither of which are needed. Don, why are you here? Why are you posting in this thread? You have gone completely off topic. Thanks, -- Rick C. -+-++ Get 1,000 miles of free Supercharging -+-++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2023-03-26 20:31 -0700 |
| Message-ID | <tvr2m0$323gl$1@dont-email.me> |
| In reply to | #31717 |
On 3/26/2023 7:30 PM, Rick C wrote: > On Sunday, March 26, 2023 at 4:52:48 PM UTC-4, Don Y wrote: >> On 3/26/2023 1:32 PM, Don Y wrote: >>> On 3/26/2023 1:23 PM, Don Y wrote: >>>> I build these into connector shells that are designed to support a >>>> pair of back-to-back connectors (DB9 or 25) and then affix a label >>>> telling me the device that it is intended to normalize (e.g., I have >>>> one at my feet that "fixes" APC's UPS serial port) *or* the function >>>> it is intended to perform (gender change, NULL modem, NULL 'terminal'!, >>>> etc.) >>> >>> This is the APC widget mentioned: >>> <https://mega.nz/file/J35SBBob#FtQznCDovhBZHJdA5OspHdMo6_DiDMjQwtCqnh3Oa54> >> And this is the COTS *PC* that I use as a name server: >> <https://mega.nz/file/Fi4hEACJ#YgVZ5tdZBjTcwW76gXC2vdgv5M6u4lTpUDAwu53Z9n8> >> >> Note the *two* serial ports (DTE as the standard dictates), 100BaseT >> network connection (it's just a name server, it doesn't need to >> have high throughput), PS/2 keyboard and VGA (cuz it's a PC!), >> wifi and USB. The four mounting holes visible are the VESA standard >> (I have these mounted between my monitor and support arm) >> >> As an ISA PC, it will run damn near any OS intended for such >> a platform (I run NetBSD on this box). So, all of the PC hosted >> AND TARGETED tools are available (I have a LFC monitor wired to >> one of the serial ports to discipline my time service as that >> was easier/cheaper to implement than any other solution!). > > Wow! He's gone from making overly verbose posts with far more description than needed, to making replies to himself, neither of which are needed. > > Don, why are you here? Why are you posting in this thread? You have gone completely off topic. > > Thanks, To show that if you buy something (or, in my case, RESCUE something with *no* markings at all on it) for a KNOWN MARKET, then you can *infer* how a responsible design would pin the connectors. I rescued this item. I had no idea what sort of CPU was inside. Nor memory. Nor pinouts of the DB9's (which I *assumed* would be serial ports -- why? because the rest of the box LOOKED like it was trying to be a PC, albeit in a very small form factor and with a wonky power connector). Or, if the 8P8C was actually a network port. Or, if the circular DIN was intended as a PS/2 keyboard. Or, the DE15 as a video port. The markings by the connectors *suggested* these uses. And, it seemed more likely than not... With *no* documentation, I opted to plug in a monitor (largely confident that the resolution would be supported by this "unknown" box) and keyboard and poke around the SETUP screen (which I *also* assumed would be available... somehow). Why was I *not* surprised with that outcome? You've posted a link to a device selected from a vendor that I'm unfamiliar with and, you infer, insufficiently documented (hey, at least you KNOW who made/makes your device! That's more than *I* had to go on!). Then, expect "us" to give you a definitive answer about specifics related to that device. And, frown on those of us that point this out to you as being "not helpful". ALL ONE CAN TELL YOU ABOUT A RANDOM DEVICE THAT APPEARS TO HAVE SERIAL PORT(S) IS WHAT THE STANDARD SAYS ABOUT THOSE PORTS, THEIR GENDER AND THE SIGNALS ASSIGNED TO THE PINS AND THEIR DIRECTIONS. I suspect more than a few people learned something about the standard, here. And, the approach I have taken to handle pinning differences (my "widgets"). Why aren't you talking to the vendor? Do you expect him/her to be reading your posts, here? Buy something that appears to be a PC. It won't succeed in that ubiquitous market if it differs radically from other devices that also claim to be PCs. So, you can, /with a high degree of confidence/, expect the connectors to be pinned the way a PC would pin them. Or, buy from Joe's Garage Shop -- ask for Joe. THIS example is a testament to how I was able to make use of a COMPLETELY undocumented device simply by making a good assumption about the intent of the product and the logical conclusions that flow from that assumption. The only examination required was trying to deduce the connections to the power connector and the associated voltages (but, I had a pretty good feeling it wouldn't be 7.293VDC or 28V or... again, because of the likely market)
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-03-27 07:04 -0700 |
| Message-ID | <db00170b-2fe8-4ac9-b19c-5b29d2e15c8dn@googlegroups.com> |
| In reply to | #31718 |
On Sunday, March 26, 2023 at 11:31:18 PM UTC-4, Don Y wrote: > On 3/26/2023 7:30 PM, Rick C wrote: > > On Sunday, March 26, 2023 at 4:52:48 PM UTC-4, Don Y wrote: > >> On 3/26/2023 1:32 PM, Don Y wrote: > >>> On 3/26/2023 1:23 PM, Don Y wrote: > >>>> I build these into connector shells that are designed to support a > >>>> pair of back-to-back connectors (DB9 or 25) and then affix a label > >>>> telling me the device that it is intended to normalize (e.g., I have > >>>> one at my feet that "fixes" APC's UPS serial port) *or* the function > >>>> it is intended to perform (gender change, NULL modem, NULL 'terminal'!, > >>>> etc.) > >>> > >>> This is the APC widget mentioned: > >>> <https://mega.nz/file/J35SBBob#FtQznCDovhBZHJdA5OspHdMo6_DiDMjQwtCqnh3Oa54> > >> And this is the COTS *PC* that I use as a name server: > >> <https://mega.nz/file/Fi4hEACJ#YgVZ5tdZBjTcwW76gXC2vdgv5M6u4lTpUDAwu53Z9n8> > >> > >> Note the *two* serial ports (DTE as the standard dictates), 100BaseT > >> network connection (it's just a name server, it doesn't need to > >> have high throughput), PS/2 keyboard and VGA (cuz it's a PC!), > >> wifi and USB. The four mounting holes visible are the VESA standard > >> (I have these mounted between my monitor and support arm) > >> > >> As an ISA PC, it will run damn near any OS intended for such > >> a platform (I run NetBSD on this box). So, all of the PC hosted > >> AND TARGETED tools are available (I have a LFC monitor wired to > >> one of the serial ports to discipline my time service as that > >> was easier/cheaper to implement than any other solution!). > > > > Wow! He's gone from making overly verbose posts with far more description than needed, to making replies to himself, neither of which are needed. > > > > Don, why are you here? Why are you posting in this thread? You have gone completely off topic. > > > > Thanks, > To show that if you buy something (or, in my case, RESCUE something with > *no* markings at all on it) for a KNOWN MARKET, then you can *infer* how > a responsible design would pin the connectors. > > I rescued this item. I had no idea what sort of CPU was inside. > Nor memory. Nor pinouts of the DB9's (which I *assumed* would > be serial ports -- why? because the rest of the box LOOKED like > it was trying to be a PC, albeit in a very small form factor > and with a wonky power connector). Or, if the 8P8C was actually > a network port. Or, if the circular DIN was intended as a PS/2 > keyboard. Or, the DE15 as a video port. > > The markings by the connectors *suggested* these uses. And, it > seemed more likely than not... > > With *no* documentation, I opted to plug in a monitor (largely > confident that the resolution would be supported by this > "unknown" box) and keyboard and poke around the SETUP screen > (which I *also* assumed would be available... somehow). > > Why was I *not* surprised with that outcome? > > You've posted a link to a device selected from a vendor > that I'm unfamiliar with and, you infer, insufficiently > documented (hey, at least you KNOW who made/makes your > device! That's more than *I* had to go on!). > > Then, expect "us" to give you a definitive answer about > specifics related to that device. And, frown on those of > us that point this out to you as being "not helpful". > > ALL ONE CAN TELL YOU ABOUT A RANDOM DEVICE THAT APPEARS TO HAVE > SERIAL PORT(S) IS WHAT THE STANDARD SAYS ABOUT THOSE PORTS, > THEIR GENDER AND THE SIGNALS ASSIGNED TO THE PINS AND THEIR > DIRECTIONS. I suspect more than a few people learned something > about the standard, here. And, the approach I have taken > to handle pinning differences (my "widgets"). > > Why aren't you talking to the vendor? Do you expect him/her > to be reading your posts, here? > > Buy something that appears to be a PC. It won't succeed > in that ubiquitous market if it differs radically from > other devices that also claim to be PCs. So, you can, > /with a high degree of confidence/, expect the connectors > to be pinned the way a PC would pin them. > > Or, buy from Joe's Garage Shop -- ask for Joe. > > THIS example is a testament to how I was able to make use > of a COMPLETELY undocumented device simply by making a > good assumption about the intent of the product and the > logical conclusions that flow from that assumption. The > only examination required was trying to deduce the > connections to the power connector and the associated > voltages (but, I had a pretty good feeling it wouldn't > be 7.293VDC or 28V or... again, because of the likely market) You are off topic in this thread. Why not start your own thread, rather than polluting this one? -- Rick C. -++-- Get 1,000 miles of free Supercharging -++-- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2023-03-27 09:21 -0700 |
| Message-ID | <tvsfqr$39kg3$2@dont-email.me> |
| In reply to | #31725 |
On 3/27/2023 7:04 AM, Rick C wrote: > On Sunday, March 26, 2023 at 11:31:18 PM UTC-4, Don Y wrote: >> On 3/26/2023 7:30 PM, Rick C wrote: >>> On Sunday, March 26, 2023 at 4:52:48 PM UTC-4, Don Y wrote: >>>> On 3/26/2023 1:32 PM, Don Y wrote: >>>>> On 3/26/2023 1:23 PM, Don Y wrote: >>>>>> I build these into connector shells that are designed to support a >>>>>> pair of back-to-back connectors (DB9 or 25) and then affix a label >>>>>> telling me the device that it is intended to normalize (e.g., I have >>>>>> one at my feet that "fixes" APC's UPS serial port) *or* the function >>>>>> it is intended to perform (gender change, NULL modem, NULL 'terminal'!, >>>>>> etc.) >>>>> >>>>> This is the APC widget mentioned: >>>>> <https://mega.nz/file/J35SBBob#FtQznCDovhBZHJdA5OspHdMo6_DiDMjQwtCqnh3Oa54> >>>> And this is the COTS *PC* that I use as a name server: >>>> <https://mega.nz/file/Fi4hEACJ#YgVZ5tdZBjTcwW76gXC2vdgv5M6u4lTpUDAwu53Z9n8> >>>> >>>> Note the *two* serial ports (DTE as the standard dictates), 100BaseT >>>> network connection (it's just a name server, it doesn't need to >>>> have high throughput), PS/2 keyboard and VGA (cuz it's a PC!), >>>> wifi and USB. The four mounting holes visible are the VESA standard >>>> (I have these mounted between my monitor and support arm) >>>> >>>> As an ISA PC, it will run damn near any OS intended for such >>>> a platform (I run NetBSD on this box). So, all of the PC hosted >>>> AND TARGETED tools are available (I have a LFC monitor wired to >>>> one of the serial ports to discipline my time service as that >>>> was easier/cheaper to implement than any other solution!). >>> >>> Wow! He's gone from making overly verbose posts with far more description than needed, to making replies to himself, neither of which are needed. >>> >>> Don, why are you here? Why are you posting in this thread? You have gone completely off topic. >>> >>> Thanks, >> To show that if you buy something (or, in my case, RESCUE something with >> *no* markings at all on it) for a KNOWN MARKET, then you can *infer* how >> a responsible design would pin the connectors. >> >> I rescued this item. I had no idea what sort of CPU was inside. >> Nor memory. Nor pinouts of the DB9's (which I *assumed* would >> be serial ports -- why? because the rest of the box LOOKED like >> it was trying to be a PC, albeit in a very small form factor >> and with a wonky power connector). Or, if the 8P8C was actually >> a network port. Or, if the circular DIN was intended as a PS/2 >> keyboard. Or, the DE15 as a video port. >> >> The markings by the connectors *suggested* these uses. And, it >> seemed more likely than not... >> >> With *no* documentation, I opted to plug in a monitor (largely >> confident that the resolution would be supported by this >> "unknown" box) and keyboard and poke around the SETUP screen >> (which I *also* assumed would be available... somehow). >> >> Why was I *not* surprised with that outcome? >> >> You've posted a link to a device selected from a vendor >> that I'm unfamiliar with and, you infer, insufficiently >> documented (hey, at least you KNOW who made/makes your >> device! That's more than *I* had to go on!). >> >> Then, expect "us" to give you a definitive answer about >> specifics related to that device. And, frown on those of >> us that point this out to you as being "not helpful". >> >> ALL ONE CAN TELL YOU ABOUT A RANDOM DEVICE THAT APPEARS TO HAVE >> SERIAL PORT(S) IS WHAT THE STANDARD SAYS ABOUT THOSE PORTS, >> THEIR GENDER AND THE SIGNALS ASSIGNED TO THE PINS AND THEIR >> DIRECTIONS. I suspect more than a few people learned something >> about the standard, here. And, the approach I have taken >> to handle pinning differences (my "widgets"). >> >> Why aren't you talking to the vendor? Do you expect him/her >> to be reading your posts, here? >> >> Buy something that appears to be a PC. It won't succeed >> in that ubiquitous market if it differs radically from >> other devices that also claim to be PCs. So, you can, >> /with a high degree of confidence/, expect the connectors >> to be pinned the way a PC would pin them. >> >> Or, buy from Joe's Garage Shop -- ask for Joe. >> >> THIS example is a testament to how I was able to make use >> of a COMPLETELY undocumented device simply by making a >> good assumption about the intent of the product and the >> logical conclusions that flow from that assumption. The >> only examination required was trying to deduce the >> connections to the power connector and the associated >> voltages (but, I had a pretty good feeling it wouldn't >> be 7.293VDC or 28V or... again, because of the likely market) > > You are off topic in this thread. Why not start your own thread, rather than polluting this one? You still fail to see how this applies to "determining which pin is the output". Wow, can a person get any denser? Hey, rick, I've got a box here. It's got a DB25 connector on it. Is it for a printer? Serial port? SCSI interface? I'd post a photo of it but the only distinguishable feature is the connector... Surely you should be able to answer this question! BTW, Joe is still waiting for your call...
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-03-27 09:56 -0700 |
| Message-ID | <2722f21c-fb51-4f5a-a62e-d03eba7a3e18n@googlegroups.com> |
| In reply to | #31733 |
On Monday, March 27, 2023 at 12:21:52 PM UTC-4, Don Y wrote: > On 3/27/2023 7:04 AM, Rick C wrote: > > On Sunday, March 26, 2023 at 11:31:18 PM UTC-4, Don Y wrote: > >> On 3/26/2023 7:30 PM, Rick C wrote: > >>> On Sunday, March 26, 2023 at 4:52:48 PM UTC-4, Don Y wrote: > >>>> On 3/26/2023 1:32 PM, Don Y wrote: > >>>>> On 3/26/2023 1:23 PM, Don Y wrote: > >>>>>> I build these into connector shells that are designed to support a > >>>>>> pair of back-to-back connectors (DB9 or 25) and then affix a label > >>>>>> telling me the device that it is intended to normalize (e.g., I have > >>>>>> one at my feet that "fixes" APC's UPS serial port) *or* the function > >>>>>> it is intended to perform (gender change, NULL modem, NULL 'terminal'!, > >>>>>> etc.) > >>>>> > >>>>> This is the APC widget mentioned: > >>>>> <https://mega.nz/file/J35SBBob#FtQznCDovhBZHJdA5OspHdMo6_DiDMjQwtCqnh3Oa54> > >>>> And this is the COTS *PC* that I use as a name server: > >>>> <https://mega.nz/file/Fi4hEACJ#YgVZ5tdZBjTcwW76gXC2vdgv5M6u4lTpUDAwu53Z9n8> > >>>> > >>>> Note the *two* serial ports (DTE as the standard dictates), 100BaseT > >>>> network connection (it's just a name server, it doesn't need to > >>>> have high throughput), PS/2 keyboard and VGA (cuz it's a PC!), > >>>> wifi and USB. The four mounting holes visible are the VESA standard > >>>> (I have these mounted between my monitor and support arm) > >>>> > >>>> As an ISA PC, it will run damn near any OS intended for such > >>>> a platform (I run NetBSD on this box). So, all of the PC hosted > >>>> AND TARGETED tools are available (I have a LFC monitor wired to > >>>> one of the serial ports to discipline my time service as that > >>>> was easier/cheaper to implement than any other solution!). > >>> > >>> Wow! He's gone from making overly verbose posts with far more description than needed, to making replies to himself, neither of which are needed. > >>> > >>> Don, why are you here? Why are you posting in this thread? You have gone completely off topic. > >>> > >>> Thanks, > >> To show that if you buy something (or, in my case, RESCUE something with > >> *no* markings at all on it) for a KNOWN MARKET, then you can *infer* how > >> a responsible design would pin the connectors. > >> > >> I rescued this item. I had no idea what sort of CPU was inside. > >> Nor memory. Nor pinouts of the DB9's (which I *assumed* would > >> be serial ports -- why? because the rest of the box LOOKED like > >> it was trying to be a PC, albeit in a very small form factor > >> and with a wonky power connector). Or, if the 8P8C was actually > >> a network port. Or, if the circular DIN was intended as a PS/2 > >> keyboard. Or, the DE15 as a video port. > >> > >> The markings by the connectors *suggested* these uses. And, it > >> seemed more likely than not... > >> > >> With *no* documentation, I opted to plug in a monitor (largely > >> confident that the resolution would be supported by this > >> "unknown" box) and keyboard and poke around the SETUP screen > >> (which I *also* assumed would be available... somehow). > >> > >> Why was I *not* surprised with that outcome? > >> > >> You've posted a link to a device selected from a vendor > >> that I'm unfamiliar with and, you infer, insufficiently > >> documented (hey, at least you KNOW who made/makes your > >> device! That's more than *I* had to go on!). > >> > >> Then, expect "us" to give you a definitive answer about > >> specifics related to that device. And, frown on those of > >> us that point this out to you as being "not helpful". > >> > >> ALL ONE CAN TELL YOU ABOUT A RANDOM DEVICE THAT APPEARS TO HAVE > >> SERIAL PORT(S) IS WHAT THE STANDARD SAYS ABOUT THOSE PORTS, > >> THEIR GENDER AND THE SIGNALS ASSIGNED TO THE PINS AND THEIR > >> DIRECTIONS. I suspect more than a few people learned something > >> about the standard, here. And, the approach I have taken > >> to handle pinning differences (my "widgets"). > >> > >> Why aren't you talking to the vendor? Do you expect him/her > >> to be reading your posts, here? > >> > >> Buy something that appears to be a PC. It won't succeed > >> in that ubiquitous market if it differs radically from > >> other devices that also claim to be PCs. So, you can, > >> /with a high degree of confidence/, expect the connectors > >> to be pinned the way a PC would pin them. > >> > >> Or, buy from Joe's Garage Shop -- ask for Joe. > >> > >> THIS example is a testament to how I was able to make use > >> of a COMPLETELY undocumented device simply by making a > >> good assumption about the intent of the product and the > >> logical conclusions that flow from that assumption. The > >> only examination required was trying to deduce the > >> connections to the power connector and the associated > >> voltages (but, I had a pretty good feeling it wouldn't > >> be 7.293VDC or 28V or... again, because of the likely market) > > > > You are off topic in this thread. Why not start your own thread, rather than polluting this one? > You still fail to see how this applies to "determining which > pin is the output". > > Wow, can a person get any denser? No, you can't. You completely fail to understand what is going on with this issue. > Hey, rick, I've got a box here. It's got a DB25 connector on it. > Is it for a printer? Serial port? SCSI interface? I'd post a photo > of it but the only distinguishable feature is the connector... > > Surely you should be able to answer this question! What does YOUR box have to do with my project? You are projecting your imaginings, onto a conversation that is very different from what you are talking about. But that's typical of you. At least your last few posts have not been a complete dump of every stray thought that you encountered while writing the post. > BTW, Joe is still waiting for your call... I'm sure he will wait a long time to come. He's probably waiting for you to stop posting off topic in this thread. -- Rick C. +---- Get 1,000 miles of free Supercharging +---- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2023-03-27 13:08 -0700 |
| Message-ID | <tvst36$3c0ts$1@dont-email.me> |
| In reply to | #31734 |
On 3/27/2023 9:56 AM, Rick C wrote: > On Monday, March 27, 2023 at 12:21:52 PM UTC-4, Don Y wrote: >> On 3/27/2023 7:04 AM, Rick C wrote: >>> On Sunday, March 26, 2023 at 11:31:18 PM UTC-4, Don Y wrote: >>>> On 3/26/2023 7:30 PM, Rick C wrote: >>>>> On Sunday, March 26, 2023 at 4:52:48 PM UTC-4, Don Y wrote: >>>>>> On 3/26/2023 1:32 PM, Don Y wrote: >>>>>>> On 3/26/2023 1:23 PM, Don Y wrote: >>>>>>>> I build these into connector shells that are designed to support a >>>>>>>> pair of back-to-back connectors (DB9 or 25) and then affix a label >>>>>>>> telling me the device that it is intended to normalize (e.g., I have >>>>>>>> one at my feet that "fixes" APC's UPS serial port) *or* the function >>>>>>>> it is intended to perform (gender change, NULL modem, NULL 'terminal'!, >>>>>>>> etc.) >>>>>>> >>>>>>> This is the APC widget mentioned: >>>>>>> <https://mega.nz/file/J35SBBob#FtQznCDovhBZHJdA5OspHdMo6_DiDMjQwtCqnh3Oa54> >>>>>> And this is the COTS *PC* that I use as a name server: >>>>>> <https://mega.nz/file/Fi4hEACJ#YgVZ5tdZBjTcwW76gXC2vdgv5M6u4lTpUDAwu53Z9n8> >>>>>> >>>>>> Note the *two* serial ports (DTE as the standard dictates), 100BaseT >>>>>> network connection (it's just a name server, it doesn't need to >>>>>> have high throughput), PS/2 keyboard and VGA (cuz it's a PC!), >>>>>> wifi and USB. The four mounting holes visible are the VESA standard >>>>>> (I have these mounted between my monitor and support arm) >>>>>> >>>>>> As an ISA PC, it will run damn near any OS intended for such >>>>>> a platform (I run NetBSD on this box). So, all of the PC hosted >>>>>> AND TARGETED tools are available (I have a LFC monitor wired to >>>>>> one of the serial ports to discipline my time service as that >>>>>> was easier/cheaper to implement than any other solution!). >>>>> >>>>> Wow! He's gone from making overly verbose posts with far more description than needed, to making replies to himself, neither of which are needed. >>>>> >>>>> Don, why are you here? Why are you posting in this thread? You have gone completely off topic. >>>>> >>>>> Thanks, >>>> To show that if you buy something (or, in my case, RESCUE something with >>>> *no* markings at all on it) for a KNOWN MARKET, then you can *infer* how >>>> a responsible design would pin the connectors. >>>> >>>> I rescued this item. I had no idea what sort of CPU was inside. >>>> Nor memory. Nor pinouts of the DB9's (which I *assumed* would >>>> be serial ports -- why? because the rest of the box LOOKED like >>>> it was trying to be a PC, albeit in a very small form factor >>>> and with a wonky power connector). Or, if the 8P8C was actually >>>> a network port. Or, if the circular DIN was intended as a PS/2 >>>> keyboard. Or, the DE15 as a video port. >>>> >>>> The markings by the connectors *suggested* these uses. And, it >>>> seemed more likely than not... >>>> >>>> With *no* documentation, I opted to plug in a monitor (largely >>>> confident that the resolution would be supported by this >>>> "unknown" box) and keyboard and poke around the SETUP screen >>>> (which I *also* assumed would be available... somehow). >>>> >>>> Why was I *not* surprised with that outcome? >>>> >>>> You've posted a link to a device selected from a vendor >>>> that I'm unfamiliar with and, you infer, insufficiently >>>> documented (hey, at least you KNOW who made/makes your >>>> device! That's more than *I* had to go on!). >>>> >>>> Then, expect "us" to give you a definitive answer about >>>> specifics related to that device. And, frown on those of >>>> us that point this out to you as being "not helpful". >>>> >>>> ALL ONE CAN TELL YOU ABOUT A RANDOM DEVICE THAT APPEARS TO HAVE >>>> SERIAL PORT(S) IS WHAT THE STANDARD SAYS ABOUT THOSE PORTS, >>>> THEIR GENDER AND THE SIGNALS ASSIGNED TO THE PINS AND THEIR >>>> DIRECTIONS. I suspect more than a few people learned something >>>> about the standard, here. And, the approach I have taken >>>> to handle pinning differences (my "widgets"). >>>> >>>> Why aren't you talking to the vendor? Do you expect him/her >>>> to be reading your posts, here? >>>> >>>> Buy something that appears to be a PC. It won't succeed >>>> in that ubiquitous market if it differs radically from >>>> other devices that also claim to be PCs. So, you can, >>>> /with a high degree of confidence/, expect the connectors >>>> to be pinned the way a PC would pin them. >>>> >>>> Or, buy from Joe's Garage Shop -- ask for Joe. >>>> >>>> THIS example is a testament to how I was able to make use >>>> of a COMPLETELY undocumented device simply by making a >>>> good assumption about the intent of the product and the >>>> logical conclusions that flow from that assumption. The >>>> only examination required was trying to deduce the >>>> connections to the power connector and the associated >>>> voltages (but, I had a pretty good feeling it wouldn't >>>> be 7.293VDC or 28V or... again, because of the likely market) >>> >>> You are off topic in this thread. Why not start your own thread, rather than polluting this one? >> You still fail to see how this applies to "determining which >> pin is the output". >> >> Wow, can a person get any denser? > > No, you can't. You completely fail to understand what is going on with this issue. > > >> Hey, rick, I've got a box here. It's got a DB25 connector on it. >> Is it for a printer? Serial port? SCSI interface? I'd post a photo >> of it but the only distinguishable feature is the connector... >> >> Surely you should be able to answer this question! > > What does YOUR box have to do with my project? You are projecting your imaginings, onto a conversation that is very different from what you are talking about. But that's typical of you. At least your last few posts have not been a complete dump of every stray thought that you encountered while writing the post. > > >> BTW, Joe is still waiting for your call... > > I'm sure he will wait a long time to come. He's probably waiting for you to stop posting off topic in this thread. Wow, had you put this much effort into YOUR problem, you could have put a SoC on a board and written the page of code it would take to suit your problem. The BALANCE of the time, you could have ASSEMBLED the boards into boxes! It's now 27 March. Your initial post was 17 January. A productive two months for you, eh?
[toc] | [prev] | [next] | [standalone]
| From | Jim Jackson <jj@franjam.org.uk> |
|---|---|
| Date | 2023-03-27 20:46 +0000 |
| Message-ID | <slrnu2404n.8p8.jj@iridium.wf32df> |
| In reply to | #31739 |
On 2023-03-27, Don Y <blockedofcourse@foo.invalid> wrote: > On 3/27/2023 9:56 AM, Rick C wrote: >> >> I'm sure he will wait a long time to come. He's probably waiting for >> you to stop posting off topic in this thread. > > Wow, had you put this much effort into YOUR problem, you could have put > a SoC on a board and written the page of code it would take to suit your > problem. The BALANCE of the time, you could have ASSEMBLED the boards > into boxes! > > It's now 27 March. Your initial post was 17 January. A productive two months > for you, eh? That was my thought wwwwaaaayyyy back!
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2023-03-27 15:07 -0700 |
| Message-ID | <6016d40c-d2f0-43bb-ba85-0d3bd102d5c3n@googlegroups.com> |
| In reply to | #31742 |
On Monday, March 27, 2023 at 4:46:20 PM UTC-4, Jim Jackson wrote: > On 2023-03-27, Don Y <blocked...@foo.invalid> wrote: > > On 3/27/2023 9:56 AM, Rick C wrote: > >> > >> I'm sure he will wait a long time to come. He's probably waiting for > >> you to stop posting off topic in this thread. > > > > Wow, had you put this much effort into YOUR problem, you could have put > > a SoC on a board and written the page of code it would take to suit your > > problem. The BALANCE of the time, you could have ASSEMBLED the boards > > into boxes! > > > > It's now 27 March. Your initial post was 17 January. A productive two months > > for you, eh? > That was my thought wwwwaaaayyyy back! It's best not to follow in Don's footsteps. Do you really think nothing has happened in regards to this? Do you think I've been twiddling my thumbs? I barely have time to think about this effort, and nearly none to do it. But it's looking like I'll need to write the software. -- Rick C. +-+++ Get 1,000 miles of free Supercharging +-+++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2023-03-27 15:07 -0700 |
| Message-ID | <tvt441$3dd67$2@dont-email.me> |
| In reply to | #31742 |
On 3/27/2023 1:46 PM, Jim Jackson wrote: > On 2023-03-27, Don Y <blockedofcourse@foo.invalid> wrote: >> On 3/27/2023 9:56 AM, Rick C wrote: >>> >>> I'm sure he will wait a long time to come. He's probably waiting for >>> you to stop posting off topic in this thread. >> >> Wow, had you put this much effort into YOUR problem, you could have put >> a SoC on a board and written the page of code it would take to suit your >> problem. The BALANCE of the time, you could have ASSEMBLED the boards >> into boxes! >> >> It's now 27 March. Your initial post was 17 January. A productive two months >> for you, eh? > > That was my thought wwwwaaaayyyy back! As I said elsewhere this thread: "some people are slow learners". <rolls eyes>
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web