[HN Gopher] The RS-232 protocol [video]
___________________________________________________________________
The RS-232 protocol [video]
Author : EgoIncarnate
Score : 241 points
Date : 2022-11-05 15:06 UTC (7 hours ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| bmitc wrote:
| Having worked with a lot of instrumentation and control stuff, I
| really, really like RS-232. It _just works_. I made the mistake
| on one project to go all USB, and it was a complete nightmare.
| Basically, anything you can think of went wrong, from USB
| controllers maxing out on number of devices (despite the number
| of devices being a mere fraction of the allowed devices in the
| USB spec), devices causing other devices not to work if on the
| same hub, devices disconnecting, etc. I couldn 't even get
| manufacturers to tell me how many USB devices their USB
| controller supported. I often had to use tools like USB Device
| Tree Viewer (https://www.uwe-sieber.de/usbtreeview_e.html) to
| understand what was going on. There was another USB debug tool
| that I used that I've forgotten the name of (maybe USBDeview).
| And if USB devices disconnect, the only way to guarantee getting
| back to them is to restart the OS process, which makes your
| software very fragile. Same thing with cameras with USB vs
| something like Camera Link. A camera's USB driver crashing would
| make you restart your entire program, making it very hard to
| build systems. Camera Link, another serial protocol, also just
| works.
|
| RS-232 and RS-485 are just so reliable. The higher voltage of
| +/-12V makes it more resilient to noise, and the protocols are
| just simple. It isn't the fastest around, but it can still be
| pretty fast depending on how the protocols are implemented.
| guenthert wrote:
| > I really, really like RS-232. It just works.
|
| Hmmh, I rather have a love/hate relationship with it. It
| depends on context, I suppose. In an earlier era, Unix servers
| (and non-Unix Minis before that) and other equipment (some
| network routers and switches to this day) offered their system
| console via RS232. 9600baud 8n1 was _common_ , but not
| universal. The developers in charge of our enterprise file
| server were impatient and hard coded the console to 115200baud
| (because that was the maximum speed PCs generally supported at
| that time), which not all "console servers" were able to cope
| with ...
|
| Then was the question, how is it wired? DTE or DCE, i.e. do I
| need a null-cable? Flow control? And if it's not a DB9 or DB25
| connector, but a RJ11 all bets are off and you need to find the
| manufacturer's cable.
| tonyarkles wrote:
| > but a RJ11 all bets are off and you need to find the
| manufacturer's cable.
|
| Here's looking at you, Cisco, for using an RJ45 serial
| connector on devices covered in RJ45 Ethernet jacks.
| fuzzfactor wrote:
| >It just works.
|
| No software drivers needed either.
| fuckstick wrote:
| I like RS-485 - RS-232 is not particularly electrically robust
| - I have a hard time calling it reliable except in ideal
| conditions. +12V single ended, is still 12V single ended.
| Ethernet is a pretty good sweet spot of robustness, speed, and
| cost I think (PoE is nice as well) - and I've ended up using it
| for a number of industrial asynchronous data communication
| systems throughout the years. Also: It is so ubiquitous that
| installation and test equipment is readily available (that
| moreover can be used by technicians) when things inevitably go
| wrong.
| inetknght wrote:
| > _I really, really like RS-232. It just works._
|
| Well... as long as everyone has their configuration correctly
| hand-configured. As the video states, RS-232 doesn't have any
| way to transmit a clock. So if one end is talking 9600 baud and
| another wants to talk at, say, 56000 baud, then... no it
| doesn't _just work_.
| pdntspa wrote:
| I've yet to encounter a situation where this is truly as
| issue.
| vardump wrote:
| Lucky you.
|
| Issues like one device got a slightly different baud rate,
| enough to make it either not work at all or having a lot of
| transmission errors?
|
| I have, and I'm sure a lot of other people have their own
| horror stories.
|
| Having a clock signal, like in I2C, solves that.
|
| Oh and that "oops, just connected 12V RS-232 to a 3.3V
| device," and see the magic smoke getting away...
| pdntspa wrote:
| When I was doing embedded work all our terminals simply
| remembered the last settings and it was like we would set
| it once and not have to think about it again.
|
| The voltage thing is real (and real stupid IME) but we
| never ran into clock issues that would skew baud rates
| one way or another.
| exmadscientist wrote:
| You do need decently stable clocks for 232 and friends.
| Anything clocked by an RC oscillator is probably going to
| cause some sadness eventually.
|
| I2C is terrible in so many ways. (Don't send it off-
| board. Just don't. Ever. Trust me on this one. I don't
| care what you read about the bus capacitance spec, _do.
| not. do. this._ ) Sending out a clock on a 400pF on-card
| bus isn't too bad, but when you have a kilometer-long
| cable... yeah, we'd rather not send a clock down that,
| thank you. Hence the use of self-clocked or pray-we-have-
| similar-clock-frequencies protocols.
|
| 3.3V or 5V devices aren't RS-232 and people need to be
| careful about that. They're just UARTs with regular old
| logic levels. RS-232 or 422 or 485 are Serious Business
| levels to go out and do battle with the mean Real World
| and the only place they should ever land is at a
| dedicated transceiver. Full stop.
| megraf wrote:
| I've done a bunch of work with RS232 in the machining
| industry (CNC). Getting my mind around both software /
| hardware control sequences was the most challenging part.
|
| You can overcome the baud challenges with scripts that loop
| through common baud rates until alpha numeric characters are
| found.
|
| It's also nice that the same few windows applications have
| been in use for 20 years or so (I specifically worked with
| RS232 to TCP/IP).
| bmitc wrote:
| It does because that is solved trivially by documentation. By
| just work I didn't mean plug and play. (USB isn't really plug
| and play anyway by virtue of it being terrible.)
| sgtnoodle wrote:
| You can also design the protocol to auto-determine baud
| rate. Some protocols even transmit 0x55 at the start of
| every packet, allowing for clock synchronization.
| sgtnoodle wrote:
| My favorite was the time we received a new batch of
| controllers from a vendor, same revision number, and their RX
| and TX pins were swapped. When working with RS232, it's best
| to have a handful of null adapters and gender changers in
| your pocket.
| unboxingelf wrote:
| This brings back memories. We called them "gender benders".
| reaperducer wrote:
| Different item. While Gender benders could optionally be
| built with a null modem inside, as a single item their
| purpose was to link incompatible male and female ports.
|
| Having both a null modem and a gender bender end-to-end
| was common.
| dgfitz wrote:
| Still is! I carry around gender-benders, null modem
| adapters and 120ohm CAN db9 resistors every day, along
| with usb-to-serial, peak can to usb, kvaser to usb, and
| ixxat to usb.
|
| These aren't dead technologies by any stretch, not that
| you were implying that.
| cathdrlbizzare wrote:
| Null modems.
|
| Laplink cables had DB-9 and DB-25 on both ends with the
| crossover built-in.
|
| There were some male to male cables that had crossover
| while others didn't. Then there were null modem adapter
| dongles for straight through cables. They were either male-
| female or male-male depending.
|
| Reminds me about older Ethernet: before Auto-MDI/MDIX on
| most NICs and switches, crossover RJ-45 cables were needed.
| guenthert wrote:
| And a breakout box (breakout tester)!
| raggles wrote:
| I like it too, but as a comms engineer working in electrical
| substations I have encountered many, many situations where it
| didn't just work, rs485/22 too. Issues with inter-chatacter
| delay, timing of control signals, different earth potentials,
| electrical interference, mangling of signals when going through
| multiplexers or media converters are common. Now that
| everything is fibre Ethernet my commissioning times are waaaay
| faster.
| adrianmonk wrote:
| > _mangling of signals_
|
| As I recall, there was a 1990s Macintosh where the serial
| port used a proprietary connector (of course) with fewer
| pins, so Apple decided to double up and use one pin for both
| Data Terminal Ready (DTR) and Clear to Send (CTS). (Or we had
| cables that connected two pins?)
|
| Many modems would hang up if you dropped DTR. Enabling this
| is a good practice to prevent the modem from accidentally
| staying connected after you're done.
|
| Enabling hardware flow control is also a good practice. If
| the Mac can tell the sender to wait for a moment, that's
| better than dropping data.
|
| Perhaps you can see where this is going. If you enable both
| of these, everything appears to work fine for a while. That
| is, until the Mac falls behind (scrolling a lot in a terminal
| window, for example) and needs to actually use hardware flow
| control. Then, rather than pausing the flow of data, it hangs
| up the modem.
|
| And your first thought when a modem hangs up out of nowhere
| is that it's a modem issue: noise on the phone line, a bad
| modem implementation, an incompatibility between two
| different modems, etc. So you waste time looking at those as
| causes.
|
| The solution was to either disable hardware flow control or
| to configure the modem to ignore DTR and use +++ ATH to hang
| up instead. Disabling hardware flow control makes PPP (etc.)
| perform horribly because packets get corrupted and re-sent.
| And this is _another_ deceptive problem because the modem
| speed appears to have plummeted but actually the modem is
| working fine.
| ale42 wrote:
| > Camera Link, another serial protocol, also just works.
|
| USB is also a serial protocol on the wire ;-) But there are so
| many layer of complexity on the top that make it indeed a
| nightmare in many situation.
|
| I worked with a control system using USB, where the connection
| to the controller had to last for weeks. Regularly, the device
| stopped working (usually entirely disappearing from the device
| list) and I had to add support on the software to transparently
| allow the device to return (and people had to unplug and replug
| the board when receiving the "device disappeared" alert). Same
| stuff on RS-232 just worked without a single issue...
| bmitc wrote:
| I understand USB is a serial protocol, but it's the worst I
| have ever used. (Was just clarifying for Camera Link.)
|
| Your example is exactly the type of stuff I had in mind. We
| had the same issue with a camera. We also wanted to power
| cycle part of the system, since the camera was water cooled
| to turn it off, but this was basically impossible with the
| USB communication without farming out the camera
| communication to an entire other OS process/program such that
| the communication could be restarted. That manufacturer, for
| whatever reason, only implemented streaming the images over
| Camera Link but didn't implement their settings over Camera
| Link. And I swear to god, another USB camera in the same
| system wouldn't work through a hub and only worked reliably
| when directly attached to a specific USB port on the
| computer. Mindblowingly frustrating.
| tyingq wrote:
| Interesting comment on the video:
|
| _" The negative voltage requirement of RS-232 is why some ATX
| power supplies still provide a negative voltage reference on one
| of the pins. The power supply manufacturers want to provide it in
| case the end user has a motherboard that uses on board RS-232
| (some industrial motherboards still use it). usually the
| available current for the negative voltage reference is pretty
| small though (around 1 amp or less)"_
| bogantech wrote:
| I'd be surprised if any modern board didn't use something like
| a MAX232 or something similar though
| tyingq wrote:
| The context being that a MAX232 only needs +5vcc, right?
|
| Edit: Apparently called 'Integrated charge pumps'
| bloggie wrote:
| Yes, there are low current requirements, so typical uart to
| rs232 transceiver ICs include the electronics necessary to
| provide the higher voltage +- supplies.
| hbogert wrote:
| I should really pick up his vids, they are worth their thumbs up
| in gold
| fuzzfactor wrote:
| Looks like this would be RS-232F.
|
| It was way back in RS-232B when the Mark and Space were reversed.
|
| And the standard called for robust performance with all circuits
| not affected by any miswiring up to +/- 25 VDC on any pin at any
| time. Must not requie powering down before
| connecting/disconnecting.
|
| DCE really meant Data Communication Equipment, i.e. primarily
| Bell-approved acoustic telephone modems (to be operated back then
| no faster than 300 baud when using their monopolized land lines).
|
| So a DTE was Data Terminal Equipment which means a regular "dumb"
| terminal which is just a keyboard and CRT display with an RS-232
| input/output having the D-sub (male) pinout according to the DTE
| pinout scheme. A PC is a lot more powerful but with a terminal
| app or the correct tty i/o your keyboard, display, and
| motherboard 9-pin D-sub (if available) will do it better than
| ever.
|
| In the video, he's connecting only the transmit pair from his
| terminal, not shown would be the handshake lines which are, as
| seen, actually "optional". Not really but with lots of hardware
| if the recieving DCE end were not able to signal Data Carrier
| Detect (DCD), Data Set Ready (DSR), and Clear to Send (CTS) on
| the proper handshake lines back to the DTE terminal, there was
| going to be no data coming out of the terminal from pin 2 for
| you.
|
| I would expect in the software of his RS-232 adapter, that he has
| continuously enabled the handshake lines needed by the PC to
| recognize that his external device is ready to recieve. So he
| therefore needs no extra conductors between the devices to
| accomplish that handshake purpose.
|
| The DTE terminal would ideally signal power on and buffer ready
| on the DTR and RTS pins or the modem would speak not.
|
| On the DTE the outputs are Data on pin 2 and logic on DTR and
| RTS. The inputs are Data on pin 3 and logic on DSR, DCD, and CTS.
|
| On the DCE the outputs are Data on pin 3 and logic on DSR, DCD,
| and CTS. The inputs are Data on pin 2 and logic on DTR and RTS.
|
| The default concept was supposed to be a cable with straight
| connections between pins 1, 2, 3, 4, 5, 6, 7, 8, and 20 of a male
| and female D-sub 25 connector at each end. On the hardware, the
| DCE modem had the female D-sub and the DTE terminal had the male
| D-sub, so it was just a straight cable. Multiple cables could be
| used as extension cords. Good for hundreds of feet with careful
| wiring considerations. In the abscence of handshakes only two
| conductors needed for one-way communication.
|
| On the first PCs there were two D-sub 25 pin connectors on the
| back, the female was a (ribbon cable) bus parallel port for the
| printer, and the male was an RS-232 serial COM port for use to
| connect to a telephone modem.
|
| When the mouse came along they were RS-232, most people did not
| have a modem yet (why would you want to connect to someone else's
| computer anway?), so there was an available port. Connector was
| downsized to 9-pin with partial pin renumbering.
|
| Actually you could always connect two PC's together and bypass
| the handshake settings in software if your buffers were adequate,
| you only needed 3 conductors; a ground with 2 & 3 crossed over.
| There is also the optional XON/XOFF software handshake otherwise
| which is signaled within the data stream instead of needing
| excess conductors in the cable. Or you put a local jumper between
| some handshake pins at one or both ends of the cable to force the
| handshake logic if you didn't truly need the extra logic
| conductors between your target devices.
|
| On any one connector, there should be a couple handshake pins
| (other than communication pins 2 and 3) where, in the abscense of
| intentional hardware signal changes, these pins remain at a
| constant positive or negative voltage. So either voltage is
| available at either end of the cable for _local jumpering_ in
| order to fake a handshake if necessary to coerce data flow in one
| or both directions. Small (sometimes unique) rats nest of wiring
| inside of one or both ends of "proprietary" RS-232 cables under
| the hood is normal, to get by with fewer conductors since most
| serial devices are not modems any more and have lesser logic
| needs.
|
| For one-way communication he's wise to use only two conductors
| between devices and skip the confusing "null-modem" fake-
| handshake approach I have seen so much of. Fortunately modern
| (1990!) RS-232 software allows you to enable various handshake
| lines at the terminal.
|
| Here's some example wiring workarounds showing that almost
| anything goes:
|
| https://www.perle.com/support_services/cabling/documents/db2...
|
| At slow baud rates like 300 or less if available, your data can
| be visualized in real-time without an ocilloscope. With bypass of
| the hardware handshakes enabled in your communication software,
| ideally connect a bipolar LED (having an appropriate current-
| dropping resistor in series) between only male pins 2 & 5 of the
| PC's D-sub 9-pin connector. Although an ordinary (unipolar) LED
| can be good too, then alternatively reversed in polarity, showing
| only the marks or the spaces either way. This could just be
| popped into the breadboard in the video. As you press a key when
| terminal i/o is to that COM port it's almost like Morse code on
| the LED. These are the same two pins he is using to connect from
| his COM port to his breadboard.
| teh_klev wrote:
| Perle is a name I've not heard of in a while. In another
| lifetime during the mid 90's I was a field engineer and I used
| to look after Perle remote access controllers for IBM
| mainframe/mini customers.
| 63 wrote:
| > Please don't do things to make titles stand out, like using
| uppercase or exclamation points, or saying how great an article
| is. It's implicit in submitting something that you think it's
| important.
|
| > Otherwise please use the original title, unless it is
| misleading or linkbait; don't editorialize.
|
| https://news.ycombinator.com/newsguidelines.html
| dang wrote:
| Changed now. Thanks! (Submitted title was "Ben Eater is back
| with a new video (after almost a year)!")
| OJFord wrote:
| May I suggest _slightly_ editorialising, in this case? I
| honestly only clicked in because I thought (post-title-
| change) 'that sounds like a Ben Eater video, I wonder', and
| since Youtube isn't working for me on mobile at the
| momentcame looking through the comments for this.
|
| Tl;dr I think 'Ben Eater is back' _is_ an interestintg post
| in its own right, possibly more interesting than this
| particular video considering the typical [video] reception.
|
| (Longer-term higher-complexity suggestion: could YouTube
| links have the channel name somehow, like we now have /<name>
| for GitHub, Twitter, et al.?)
|
| A concrete suggestion:
|
| > Ben Eater's back: RS-232 protocol [video]
|
| Or to be more subtle, just append '(2022)' (and confuse
| people who aren't familiar or aware of the absence):
|
| > Ben Eater: RS-232 protocol (2022) [video]
| scarecrowbob wrote:
| I will watch this one later, but I can totally understand the
| excitement.
|
| Just for some background: in college I took an introductory
| digital logic class and loved it, but then I moved over to a
| humanities degree and lost a lot of that information. Then I
| started programming again, but mostly as a "self-taught" web
| developer-- not to undercut my high school and college work (I
| was on a HS programming team that was competitive), but most of
| what I use in my day to do day life are things I picked up from
| having to do increasingly difficult projects/tasks as a
| programmer interspersed with ocasional seasons of motivations
| where I'd pick up new techniques (functional programming, server
| management, front end web rendering frameworks, etc).
|
| Ben Eater's long series on building a computer out of 65c02 and
| then his longer series on building a microprocessor from TTL
| logic chips hit an incredibly sweet spot for me.
|
| I'd spent some time trying to teach my kids how to do basic
| electronics (building things like 555 timers or little robots
| with pi's for controllers, so I have some familiarity with the
| topic.
|
| I suppose if I had the time and were motivated, I could have
| gotten some textbooks and learned the same material. However, his
| material was setup in a way that made it very easy to grasp as a
| passive consumer of the video. It feels like it covered the topic
| as deeply as I was interested and answered a lot of questions as
| it went along.
|
| So, as a person who has enough familiarity with the concepts to
| find it interesting but no pressing need to master the material
| deeply, I highly recommend his work.
| [deleted]
| ThrowawayTestr wrote:
| This is the guy that made a video card from scratch, neat.
| geoffeg wrote:
| This guy also made a video card from scratch.
| https://www.youtube.com/watch?v=K658R321f7I&list=PLFhc0MFC8M...
| unboxingelf wrote:
| Started my career in software building automation systems around
| RS-232, IR, and ethernet. RS-232 was always my favorite because
| compared to the other protocols it just worked; IR was often
| unreliable and ethernet had much more complexity. I think I could
| still wire a db9 pinout from memory.
| geerlingguy wrote:
| His visual exploration into various protocols is eye-opening. I
| love the style and always learn a few things when looking at
| protocols from a signal-level perspective.
| rvense wrote:
| He's a fantastic teacher. I particularly like his breadboarding
| videos where he does something obvious but wrong, and then
| backs up and explains why.
| [deleted]
| stephc_int13 wrote:
| Imagine a world where simple point to point data link would still
| use a backward compatible and improved RS-232 and where
| everything else was using Ethernet.
|
| I would be curious to see an evaluation of the collective cost of
| USB + Bluetooth over the decades since their inception.
|
| I've seen the guts of USB drivers a long time ago, I could not
| describe the horror.
| gorgoiler wrote:
| One of my proudest hacker moments was also one of my first:
| debugging a noisy console session whose transport was RS232.
|
| Long story short (it was 30 years ago so I also can't remember
| the precise diagnosis) there was corruption on the line in that
| sometimes when you typed a space it would come out as something
| random. Few other characters were corrupted as often, if at all.
| It was almost always spaces that were showing up as random other
| characters.
|
| My observation was that space was encoded as 00000 -- all low,
| the printed character most susceptible to line noise -- and that
| something wasn't grounded. Smarter people took my observation,
| figured out what was wrong, and soon all was fixed. It felt like,
| for the first time, I understood the system with a depth I'd not
| had before. It was cool.
|
| Oh, and playing DOOM for the first time over RS232, too. Another
| precious memory indeed!
| spookthesunset wrote:
| His homebrew CPU was the best explanation of how microprocessors
| work I've seen!
| davidpfarrell wrote:
| Just FYI what fun thing is explored in the video:
|
| > This video explores the electrical and timing characteristics
| of the RS-232 protocol.
| joneholland wrote:
| I posted this on the YouTube comments as well. I'm pretty sure
| there is minor bug in how he uses 7 cpu cycles to try to read
| from the middle of each pulse. It should be about 50. He divided
| the 13 cycle wait in half but the reason he used 13 cycles
| originally is because the read logic was already using many
| cycles. In practice this doesn't matter because the state
| transitions are stable enough with his particular device.
| terramex wrote:
| He does not wait for 7 cycles but for 7 iterations of loop
| taking 5 cycles.
| ddalex wrote:
| that is 35 cycles instead of 53 cycles he was supposed to
| wait
|
| I mean, it's close enough and it works
| rektide wrote:
| Is there a word to describe the +/- signal behavior of rs232?
| It's like a differential signal, but with a pesky common ground,
| bother.
| ajross wrote:
| My understanding is that it was for driver circuit
| compatibility with older current-loop TTY devices. Early
| Teletype et. al. terminals were designed to run over
| potentially long wires with high resistive losses[1], and to be
| received by 1960's electronics with very low impedances (the
| ancestral devices were mechanical switches!). So the idea was
| you'd just switch a big DC supply onto the lines and figure it
| would be enough to get 20 mA at the other end, so that it could
| see it.
|
| When RS-232 came along, they deliberately specified a very wide
| band of allowed voltages so that in many cases manufacturers
| could just cable the current loop device in parallel with a
| resistor and be compliant.
|
| Don't quote me though, I don't remember where I read this.
|
| [1] So... yeah, it's basically solving the same problem as
| differential signaling but at a different scale.
| kevin_thibedeau wrote:
| Bipolar NRZ.
| Animats wrote:
| It's not differential, just polarized. -12V or +12V originally.
| Extracting signal polarity is more reliable than triggering on
| a threshold, or it was before electronics got good.
|
| It's a telco thing. Polarized signaling goes back to the
| original Edison stock ticker. Polar relays were once used on
| Teletype circuits.
| robinsonb5 wrote:
| I'd probably go with "anachronistic" - RS232 predates TTL
| logic!
|
| Interesting that the bit-level protocol is still very widely
| used today, even if the signalling is now more likely to be 5v
| or 3v3 TTL signalling bridged to USB.
| masswerk wrote:
| It's up to +-25V, a voltage swing of 50V. (I believe, +-12V
| was common for TTYs.)
| fuzzfactor wrote:
| Low voltages near zero on any pin either + or - side are
| ignored, below a certain threshold of absolute voltage either
| way it's no-man's land. Signals are only considered real if
| they are boldly above the threshold, preferably close to +/-
| 12VDC either way to reliably qualify as a space or a mark, but
| no higher amplitude than +/- 25VDC.
|
| This helps to compensate for unavoidable differences in
| absolute ground potential between remote locations.
|
| The data signal is basically just square waves since it's ones
| & zeros, but hook a speaker up properly and that's the
| unforgotten audio sound of dial-up internet.
| birktj wrote:
| Yesterday I was configuring a usb to serial converter to
| communicate with a CNC controller (over RS232). However I was
| unable to transmit any data and so I brought the oscilloscope to
| see what was happening. I disconnected my converter and connected
| the oscilloscope and all the data was there and my oscilloscope
| had no problems decoding it with the same parameters i had used
| with my usb converter. Confused, I disconnected my scope and
| connected my converter back up again, but sill nothing. After a
| few times back an fourth I ended up connecting my scope up while
| the converter was still connected and crucially I also had a cat
| /dev/ttyUSB0 running and as expected the data was right there at
| the scope, but to my big surprise it was also there in my
| terminal! I then tried to disconnect my scope resulting in no
| more data being sent to my laptop.
|
| The only explanation I could think of was a faulty ground
| connection. The scope was grounded through the wall socket same
| as the CNC and thus had the same ground potential. My laptop on
| the other hand was running on battery and only shared ground with
| the CNC through RS232 pin 5 (signal ground). However it seems
| this pin was not correctly connected on the CNC side and thus I
| was unable to transmit any data. Experimenting a bit I tried to
| connect ground to the connector shield instead and everything
| worked perfectly.
| anonymousiam wrote:
| Nice informational video (after such a long time) and I don't
| mean to be pedantic, but RS-232 is not a protocol, it is an
| electrical/physical standard. RS-232 says nothing about the bits
| on the wire, other than how they might be synchronized as long as
| both ends of the point-to-point link agree on settings.
| 0xmarcin wrote:
| Great to hear that. BTW in meantime other ppl also posted amazing
| content. Right now I am following this guy (https://www.youtube.c
| om/watch?v=VvyUAaRTsww&list=PLcGZbzUhfc...), he builds x86
| breadboard computer, but does so with much more tech detail &
| compiler/liner mastery than Ben.
|
| (If you are interested into x86 breadboard stuff, please check
| The 8088 Project Book - which is a great intro befor jumping into
| more advanced stuff).
|
| BTW I have a PoC of using C with Ben Eater computer -
| https://github.com/marcin-chwedczuk/ben-eater-6502-ansi-c I do
| not have time to dig deeper into it yet, but looks promising. The
| only problem with 8-bit processor is that they use first page of
| memory to pass extra variables because stack is too small (256
| values in total, yup).
| royjacobs wrote:
| You might also enjoy llvm-mos, which allows you to use very
| decent versions of clang on the 6502!
|
| https://llvm-mos.org/wiki/Welcome
| louwrentius wrote:
| This video is made by Ben Eater. He has virtually disappeared
| online for almost a year now (give or take). I hope he is OK and
| I really miss his videos.
| louwrentius wrote:
| I thought it was an old video but apparently he's back!
___________________________________________________________________
(page generated 2022-11-05 23:00 UTC)