• NULLPTR (unregistered)

    Public Function getComment(idx as Int) As String throw new Exception() End Function

  • jwoieo (unregistered)

    This has shades of "Method '~' of object '~' failed" and the ISupportErrorInfo interface...

    Back in the misty days of COM, making a cross-process call would involve the caller activating the remote executable and then generating a proxy IDispatch which forwarded your method call to the EXE and captured the return.

    However, should your initial call to the IDispatch::Invoke cause an error on the EXE that makes it terminate, all that the Invoke() method returns is a single-number HRESULT 0x80010105.

    Then the client side is meant to call BACK INTO the remote executable to get the full error message via ISupportErrorInfo.

    Of course there is now no longer any executable to call, and the useless error message is displayed.

    I miss you VB6.

  • William Sauron (unregistered)

    Bridging RTS-CTS and DTR-DSR is neither stupid nor tricky. It was common at the time, so only 3 wires were needed for communication.

  • (nodebb)

    There's an interesting side effect of this approach. Despite looking like a series of recursive calls, throw unwinds the stack, so this code will never actually trigger a stack overflow. It's actually more of an exception-assisted infinite loop.

    Surely throw waits until after MakeComPortException has returned before unwinding the stack?

  • (nodebb)

    Using RS-422 or RS-485 gets you over the noise and distance problems. Just needs an adaptor at each end, as they're logically compatible with RS-232. (One of them is multi-drop and requires playing with the signal lines to take control of the line, with added chances to lock everyone else of the bus. I leave it as an exercise for the reader to find out which one (I've forgotten and can't be bothered to Google))

  • Tim Ward (unregistered)

    C'mon, no off-the-shelf RS232 cable ever worked with any software. It was always build-your-own, after a day or three with an Interfaker trying to find out what was going to work.

  • guest (unregistered)

    "RTS" does mean "Request To Send", doesn't it? Not "Ready to Send"...

  • (nodebb)

    Ah, RS-232. I used to connect all kinds of devices using that. It was lots of fun (not) figuring out what cable wiring arrangements would make each one work (you see, I also made the cables). I designed cables, adapters, "un-adapters", and loopback connectors. To make some combinations work even required an external power supply. Happy days.

  • Andrew (unregistered)

    TRWTF is "recieve".

  • boatymcboatface (unregistered) in reply to guest

    yes https://en.wikipedia.org/wiki/RS-232#Data_and_control_signals

  • Brian Boorman (google)

    Came here to say that it's Request To Send and that true industrial controls use RS-422 not RS-232 for the physical layer. As others pointed out, there are converters you can put on.

    And looping RTS to CTS at the cable (or in the far end of the equipment) is not stupid or unheard of. It is used to defeat HW flow control (if it's not needed and you can't turn it off). Though for cable detection purposes it makes more sense to use DTR (Data Terminal Ready) looped to DCD (Data Carrier Detect).

    I've noticed that Remy tries to pretend that he knows anything about the embedded world. Usually fails.

    Remy: Oh, I'm really bad at embedded programming. I do a fair bit of it, but I'm terrible at it. It's okay, I'm not coding anything that controls anything important.

  • Angela Anuszewski (google) in reply to Brian Boorman

    Maybe Remy should turn the article writing over to you then. I agree that the embedded world is way different. There's nothing inherently wrong with infinite loops in the embedded world. That's why I will always tell someone trying to decide between EE or a CS degree go for EE. Knowing how to program things other than PCs is not a skill you are going to pick up in your average CS program.

  • get off my lawn (unregistered)

    A gigantic Switch statement? Looks more like a Case statement to me.

  • Gumpy_Gus (unregistered)

    Serial communications is usually a WTF. The handshaking is almost always done wrong, like with jumpered 4 to 5 and 6 to 20 on the computer end, to defeat any attempt at detecting if the other end is even connected or turned on or attempting to use hardware flow control. Software flow control is only slightly better handled, with sometimes ^S/^Q used, sometimes to excess, sometimes space kills ^S, and since you jumpered the handshaking lines ^S can get lost too!

  • Coyote (unregistered)

    The RTS-CTS loopback is common in cables that have DB-9 or 25 on one end and something really stupid like RJ-11 or even a re-purposed USB-A on the other end (I'm looking at you, Dell...)

    Now, when it comes to stupidity and/or malice, nobody beats APC. Their older Smart-UPS models had DB-9 on both ends, but with a totally non-standard pinout on the UPS end.

    The EPO pin was on DTR. Unless you used the custom APC cable, the UPS would power off the instant you opened the port.

  • I dunno LOL ¯\(°_o)/¯ (unregistered)

    Using RJ-45 cables for RS485? Heathens! Back in my day (now 20 years ago) we used RJ-11 cables. (For RS-232 too, actually. I still have one of my old MAX-232 boards in my parts box.) Cat-1 silver cord is plenty good enough, and there's a much nicer variety of widgets to hook them together than RJ-45. I suppose you could even daisy-chain a bunch of splitters to create a nice RS-485 network that's still much better than barbed wire!

    It's also fun to use paper clips to dangle all that silver wire from ceiling tiles, when the equipment is too big to roll into your work area.

  • Alipha (unregistered) in reply to Steve_The_Cynic

    Yeah, I agree. I'm pretty sure that'll still cause a stack overflow.

  • I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to RobyMcAndrew

    RS-485 is just RS-422 with the transmit and receive pairs tied together. And you just need to ground one of the input pair and ignore one of the output pair to get RS-232. The original Macintosh had RS-422 ports, so you could even get it to talk RS-485. RS-485 is of course half-duplex, and often used in multi-drop situations where there is a single master. For me, that was talking to gas pumps. (hence the equipment that was too big to roll into your work area, and also you had share with your co-workers, much easier when everybody drops their own silver phone wires to the same place)

  • Just another Embedded Designer (unregistered)

    Many things wrong in article

    Until RS232-D the EIA RS232 spec concerned one signal and its voltage levels for one way communication, not how you were going to define multiples into Simplex, Half-Duplex or Full Duplex communication links.

    Looping back RTS to CTS (and often DSR to DTS) was so common there was a specifc name for it a 'NULL Modem cable' which nulled out the modem control lines. You could buy the cables by the bucketload. What was more of a problem was the connectors if someone had made a 'special' cable as until RS232-D version of the specification the 25 way D type was not specified and in D version they also allowed the then prolific 9 way version. Says he who has had to deal with Synchronous interfaces using RS232 and the Secondary signalling needing all 25 pins.

    The 25 way D type connector came from the then CCITT V24 spec for modem interfaces.

    Then we have the error, RS232 was NEVER limited to 15 m (this is an urban myth), there was a comment WRONGLY read by many people that stated that when using a fully loaded 25 way connection scheme, and very lossy cable (high resistance/m and high capacitance between conductors), the noise level went up. It did NOT say it would not work.

    I know of people who did experiments 30 years ago, using reels of bell wire (you know your front door bell type wire), transmitted an RS232 voltage levels continuous signal through 2 reels (1km in total) and received the signal correctly at the other end.

    Shame most people who think they do embedded are only playing with toys, having done embedded for many years from gun sights to medical systems I find some of the stories on embedded written from a desktop programmers perspective, like two embedded projects I am currently getting a lot of WTF and copy/paste nightmares out of. Let alone relying on libraries and OS for their embedded projects without understanding the limitations.

    Rant over go back to discussing your web apps and similar

  • Concerned individual (unregistered)

    TRWTF is a CodingSOD marked as a Featured Article

  • sizer99 (google)

    I do machine control and embedded, and we do use RS-232/RS-485 (and CAN bus, EtherCAT, or other abominations) where required. Often you don't get to choose. The device supports X, you use X. All the devices we actually make have 3-pin serial or USB serial for debug (and optional control) because it's dead easy, cheap, anything can talk to it, and you don't need a USB stack on the device.

    And I'd have to say TRWTF is doing your low level machine interfaces in Visual Basic.

  • Angela Anuszewski (google) in reply to sizer99

    When I see industrial interfaces and Visual Basic, I automatically think OPC.

  • Just another Embedded Designer (unregistered) in reply to Angela Anuszewski

    VB and industrial talking to embedded I think OMG

    Having seen one guy get a 32 bit command integer and constructed the different commands by lots and lost of Mid( ) and CHR$( ) as a 32 character string then convereted to 32 bit number. Oh he had functions one of these long functions for EACH command type.

  • (nodebb)

    All this "serial" talk reminds me of nice ASR33 teletypes. If you were smart, you used the carrier detect pin to turn on the motor, and then the Bell 103 modem only needed DTR (pin 20) to work correctly. All this interconnection stuff made me go out and get a nice LED box that showed the status of the critical interface signals.

    Then IBM came along with the 9 pin connector (actually called "DE-9") which assigned the signals to wildly different pins (why didn't they use the same pins for most of the signals??). But serial communications are here to stay and for the life of its 60 years has been a great ride.

    Life goes on.

  • sizer99 (google) in reply to Angela Anuszewski

    Yeah, and I know these days VB is just another front-end for .NET, so at the CLR level it doesn't matter if you used C#, VB.NET or IronPython. But I still can't shake the days of when everyone who didn't know anything about programming used VB by default.

  • tlhonmey (unregistered)

    longer distances don't take all that much hoop jumping. Use those adapters that let you turn a DB-9 or DB-25 into RJ-45 and use twisted-pair cable. Hook them up so that TX and RX each use one wire from two separate pairs. Attach both of the other wires from those two pairs to ground on both ends. That eliminates most of the interference and lets you get 9600baud or greater over hundreds of feet, even in relatively noisy environments.

  • staticsan (unregistered)

    I nearly had a stand-up argument with a comms guy over a null-modem cable. He insisted that the control signals had to be reflected back, leaving just three wires between each end. But I had a situation where one end needed the hardware flow control, so I needed all of the lines crossed. I eventually made the requisite cable myself.

  • Little Bobby Tables (unregistered) in reply to Andrew

    ... and "occured".

  • (nodebb) in reply to herby

    In the days when dinosaurs walked the earth (and communicated with Teletype and Selectric 2741 terminals), I once worked for a University Computing Center. Next to the Computing Center, was a Graduate Research tower, and located on the 6th floor of that tower, was a researcher who wanted a terminal connected to our timesharing system. Said researcher did NOT want a modem connection.

    I was instructed to run an RS-232 connection from the 6th floor of the tower to the mainframe. At least 200-300 ft. (70- 00m). It was done, and it worked. Reliably.

    We were all very impressed. The researcher was happy. I went back to my job of maintaining the UCC's Model 33 Teletypes.

  • Oops (unregistered)

    Serial can easily do 30m or more, without much thought.

    I had it working at 50m with very little effort, or signal noise.

  • sizer99 (google) in reply to ka1axy

    Since we've gone down the hole... there are basically four things that govern how far you can run RS-232

    1. Voltage levels. Standard says +/- 15V, a lot of stuff these days uses +/- 3V TTL. You'll go farther with the high voltage version.
    2. Cable quality is the #1 thing. You want low capacitance shielded with a grounded shield. Try not to make any sharp bends (you get crosstalk and induced capacitance). @tlhonmey had good advice if you must use TP cable.
    3. Whether the sender/receiver use pull-up resistors to boost their sensitivity.
    4. Baud rate. The slower you go, the further you can go.

    In your case, if it was a Selectric 2741 that's 150 baud (at max speed). You had the pull-ups (IBM was quality in those days). So with decent cable I'm not terribly surprised you got 2-300 ft.

  • hung out to dry (unregistered) in reply to herby

    "Actually called DE9" only by Wikipedia. Back in the day, actual users, retailers and specifying buyers called it DB9

  • Richard Wells (unregistered)

    I used to do a lot of RS-232 stuff in my first job (mid 80s). We had a home-brew CAD system, and I was the device guy. I had some fun tracking down a bug in the serial communications part of the IBM BIOS; it would check for CTS before checking to see if the send buffer was empty. So it was possible that CTS was on, after which the send buffer would empty, filling the other device's internal buffer, causing it to drop CTS. But since CTS was already checked, the next byte was sent anyway, and data would get lost.

    This was usually fine, since most pen plotters (the main serial devices we used) would drop CTS when there were still a few bytes left in the buffer. But we had one sufficiently old plotter with a 16-byte buffer (Calcomp 960?) that would drop CTS when the buffer was exactly full. It took me several hours with a serial line analyzer to track that one down. That bug was the reason I learned to write DOS device drivers.

  • Jon (unregistered)

    As far as a fiendish way to sell more expensive cables, I had a friend in college who bought a few boxes of neon green Cat5 and made "XBox Cables." He sold them at about 5x the price of a normal network cable.

  • Gumpy_Gus (unregistered) in reply to sizer99

    Wasn't 2741 actually 134 baud, with some weird pauses needed to do case-shift? Long ago I had a 2741 technical manual and the number and kind of timing kludges and character mappings you had to implement were awesome.

  • Gumpy_Gus (unregistered) in reply to Richard Wells

    The IBM BIOS serial port code was crappy. Not interrupt driven, so 300 baud or higher was an adventure in dropped characters. The first "super" serial cards had a 16-character input buffer, which did not work. National Semi had to put out a 16550-A version of the chip where the serial buffers actually worked. You had to write your own assembly-language code to enable the serial buffers too, and mediate the interrupt state transitions. Not good times.

Leave a comment on “Exceptionally Serial”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article