Thanks James. This is a perfect companion to the CPU. UART is one of those terms I heard way back, I know their function, but never really considered it from this perspective.Take Care.
I watched this thinking it was part of the planned enhanced IO for the CPU build. That would be so cool. In any case, asynchronous serial data transmission is quite an impressive feat. I look forward to seeing what you do next :D
These videos are really good and informative. What would really help those who are still learning, is if you added a Shematic at the end of the video so it makes it easier for us to understand whats going on.
Lovely video, as usual, thank you! I'd like to see this getting hooked up to your CPU, mainly because I want to see how you handle buffering, interrupts and crossing clock domains. I see a couple of other people have commented on the Elegoo breadboards, and I'd second their concerns. I've used 15 of them so far in my CPU prototyping, and about half have been fine, the other half terrible (very poor contacts that make or break contact as you add components at the other end of the board, for example). The BB830 ones I switched too recently were a revelation. Fingers crossed yours don't give you trouble.
I am curious to hear all the comments about the Elegoo boards, the other ones I was using occasionally had dodgy contacts but they also changed the specifications occasionally (I had two groups of boards that wouldn't join with each other). I have enough of these for finishing the UART, I'll pass my judgment on them then.
Thanks David! This maybe the shape of things to come, I'll probably do Sound and Video as separate mini series, and then integrate them into the cpu build.
Thanks Frank! I was actually thinking while editing that some of the serial terminals at college were 7bits, but 8bits covers pretty much everything I've touched of late.
Love it! I would like to see how you connect it to the CPU. Your design choice will be interesting to see (memory mapped IO, or dedicated IO instruction, or whatever you decide). I really enjoy how you are exploring the concepts and implementing them. I don't think that having to accept a variable baud rate is really worth the time or effort though.
Thanks Bob! I already have a basic io instruction that I use for the lcd display, I'll probably do something similar. In this case I'd need 1 output and 2 input ports (There would need to be a status to report waiting data and a busy send circuit). Variable baud rate would just be a matter of having a selectable clock divider circuit between the crystal and first counter, I wasn't planning on doing that unless people asked for it though.
I bought a load of Elegoo breadboards for my original 8-Bit CPU build but had nothing but trouble with them, so changed to BusBoard 830 boards even though they were a lot more expensive. That was over 18 months ago, so the Elegoos may have improved by now. Let me know how you go with them.
Interesting, All things are relative of course, my previous ones may just have been really rubbish. So far these have been good, but it's just been the one breadboard, couple of holes had to be loosened up but that's common on all breadboards.
Awesome as always. Receive is going to be a bit more tricky I think, since you have the synchronisation to deal with, ie the loading has to start on an external pulse. I'd like to see all of the build in at least this level of detail. :) Makes me want to write a simple UART in VHDL, something I've not yet attempted.
Thanks Lawrence! Receive is indeed the more difficult of the two, but I don't think it's going to be that bad. I look forward to your reaction to my circuit.
@oH well,lord! [NB: I am a s/w guy, not H/W; this is my un-informed vision] I have always envisioned a 16x oversample implemented as a divide by 16 counter which is reset when the the start bit arrives. That reset synchronizes the output of the /16 with the incoming clock signal. (16 is a bit arbitrary. It needs to be at least 2x (Nyquist); but larger values are more tolerant of differences in clocks.) It may be the reset should set the /16 counter to 8, so that the the sampling occurs in the middle of the bit?
Pretty much, the start bits always being low and the stop bits (and resting state) always being high guarantee you a high to low transition at the start.
Great as always James. To answer your question, I'd like to see you build a full fledged bi-directional serial port connected to your cpu (using interupts for instance) so that you can have some sort of serial user interface to it. It's ok for me if you hardwire the speed such as 115kb/s 8N1 because there is no great value in handling all the details of variable baud rate or parity or other. But then you would need some sort of CPU supervisor to handle the interface.
Thanks Ced! I'll definitely get as far as a bi-directional, I've already said that I'll not be implementing interrupts (On this cpu build) so it will need to be polled (Just like the early micros).
I bought a couple of tiny OLED displays (I'm talking 1cm x 1cm) and they have only control pins: VCC, GND, SCI, and SCA. Since you are doing serial, I believe you could find a way to hook up one of these displays to your CPU so you could print out text/render images with the CPU. If you are going to get some displays, don't make the mistake I did and get the tiny ones... Another idea would be some serial input, like adding a keyboard. I know the receiving is much more difficult to implement than the transmission, but seeing as this barely took 1 breadboard to make - I think you're up for the challenge.
I suspect your lines are actually SDA and SCL, these would be the data and lock lines of a I2C connection. This is slightly more complicated than UART but I might take a look at it in the future. Certainly for a basic TTL cpu build I would stay away from I2C, not least because they are very modern components that don't really feel "in the spirit" of designing from the ground up. I will indeed be doing receive, a ps2 keyboard interface would actually be quite easy, the receive should be easier than UART because it comes with a clock so you don't need to do any clever synchronization.
I’d love to see a UART circuit hooked up to your CPU with code to echo the input out to your little LCD display. It would be neat and probably very useful for future coding projects on it.
Interesting, my thinking was that it would be nice to get my test programs outputting to a serial terminal. My prime number finding program is "assumed correct" because I've paused it a bunch of times and checked what was on the 4 line display, with a serial output I could capture it and actually check them all.
Thanks Paula! I definitely want to get send/receive going from the cpu. Driving a serial terminal would make for a more interesting test display than the lcd. How is your build going?
I found Elegoo breadboards to be horrible. Hopefully they've fixed things by now, but when I bought them, the springy contacts were atrocious. Loose, poorly aligned such that it was often difficult to plug components in... Hopefully you will have better luck! You might get less ringing in the edges of the clock signal if you use a shorter ground lead. Ideally your probes came with some little spring like ground leads that hook on to the end of the probe, usually results in a much cleaner waveform. Breadboards are commonly quoted as being fine up to about 10MHz.
So far they seem ok, so things might have improved. The ringing is really high, I know a shorter ground lead helps but I've had far sharper edges on the breadboards without shortening the ground leads.
@@weirdboyjim maybe this oscillator has really fast edges (rise/fall times). Could try probing through a resistor of 50 or 100ohm perhaps. Would take some of the bite out of it.
@@weirdboyjim It could be the power supply to the oscillator. Running power and ground to the same power rail on the breadboard should help a lot. You could also solder one end of a cap to the body of the oscillator(should be GND) and plug the other end into 5v.
As well you should! Just as I should feel guilty for using custom pcb's rather than wire wrap, and we should both be ashamed for not cooking our own transistors. ;-) It's an honor Bill, your build is an inspiration. Maybe when I'm finished with this thing we can do a collaboration to compare architectures.
@@weirdboyjim Glad to know!! Eagerly waiting for it as we re trying to follow your exact instructions while making the same ! you are Excellent at it !
Cool, maybe I will use this principal for my transistor-based computer. 7:29 Indeed, any quad flipflip out the 7400 serie will do the trick, no special need for a 74**193, I guess that a 74**193 costs more because the extra circuitry inside.
I've not noticed a significant difference in the pricing. Manufacturing a dip part at scale I doubt it makes much difference, I don't like unused functionality though.
why do you use LS on the breadboard and HCT on the PCBs? is there some fundamental difference between TTL and CMOS that makes one more suited for breadboard applications? som cursory research implies that HCT has superseded LS for almost all use cases.
The most direct answer to that is actually that I probably would have used LS on the pcb's had I been able to get all the parts but in smd (which I wanted to use on the pcb's for compactness) they were all easily available. HCT in this context was a bit of a compromise that allowed me to intermix with the LS on the breadboards as I gradualy converted from one to the other. In the final build when it's all PCB HC would have been better, but HC would have been a complication to the breadboard build for a couple of simple reasons. LS was what I had, and LS is far more tolerant of unused inputs being left floating so it's better suited to dabbling on a breadboard.
It would be nice to get string print over serial so I can capture the entire output from the primes demo. With Ansi codes it would actually be possible to start writing games targeting a serial terminal.
Wonderful test of concept but won't work with your CPU as this circuit have a timing issue and actual UART have a data buffer to compensate. You will also need a T flip-flops or state machine for automating start and stop bits. Thanks for sharing ✨✨✌
What "timing issue" do you think the circuit has? Interfacing this to the cpu should be fairly easy, but it does need a couple of extra chips than I have here. You don't need special circuitry for the start and stop bits, you just hardwire their inputs to the shift register so it "load's" 0 and 1's in the right places alongside the data for sending. Receive gets a little more complex and you do need to be able to buffer at least one byte of input.
@@weirdboyjim I think he's referring to the oscillator not being synchronized with the start bit. There is a very small chance that the other side transmits data right on the edge of a clock pulse. If I remember correctly those converters start their clock only when rx goes low so sending shouldn't be a problem. I don't have a big can oscillator with enable, can you check if yours does and if it does how long it takes to enable it? Awesome video!
1Mhz / 16 is actually 62500. That's a very nonstandard baud rate. Your usb->serial device may not reproduce that properly. I strongly recommend you get a 1.8420 oscillator or one of the others that it is a good multiple of a common baud rate. It will be far easier to test. Do you have an oscilloscope? You should be able to confirm the output looks right regardless.
@@weirdboyjim Yes I checked, it gives 62.5kHz indeed. Thanks for pointing that out. I’ll see if I can get a multiple of common baud rates because I can’t find your Oscillator anywhere 👍🏻
@@davidrosset4457 the 1.8432's are common. Some of the bigger suppliers only have SMD ones though. The through hole ones are still widespread though. I recently ordered some smaller ones on ebay to save some board space.
I've watched this playlist and then compared what you did here to the design of the UART I did a year ago for my redesign of a PDP-8 I also did back then. I had to add synchronization logic to handle the crossing of the two clock domains or else the length of the startbit could vary up to 1/16 (6.25%). I don't see anything for that here. Do you consider that a non-issue or is it solved inherently in the design here>
You mean on the transmit? It's kind of a non issue in this design, the first bit sent is actually high so that bit being of varied length depending on where in the uart clock the operation happens doesn't matter. The start bit is the second bit in the shift register. On the receive that is indeed a potential misalignment of 1/16th of a clock. The bits are read at the midpoint of the bit rate clock so I don't think there is much cause for a problem. All that aside, the new fifo circuits I'm in the process of adding will actually simplify things a bit further, they will a literal buffer between the clock domains and eliminate the theoretical race conditions I might be open to at the moment.
Ok I got a 1.8432 Mhz Oscillator but I don’t seem to be getting any output on the 74LS165… the clock gets divided fairly though to 115200 baud. Any clues what might be wrong?
Have you got an oscilloscope? Check the clock inhibit line is low (pin 15) then make sure the load line goes low with the right data on the inputs. Are you definitely getting nothing out of pin 9?
@@davidrosset4457That sounds very wrong. Pin 15 should be fully ground, that sounds like you have an output line fighting your ground. Have you got a different 74LS165 to try? That sounds like your chip maybe broken or mislabeled.
Interesting question. You can try, I use counters here to divide the clock down. You would need to play around with the maths and see if the device you want to talk to supports a bit rate that you can achieve with the clock you have.
Thanks Leonardo, I'll definitely do this, I don't know if I'll include the serial port in the final build of the cpu but having it as an interfacing demonstration makes a lot of sense.
Only seen 8 bits... you mean in modern times using terminal to talk to your microcontrollers and such? Back in the 8-bit era, you might recall 7E1 when dialing into BBSs and using peripherals.
I didn't hit the bbs scene until the late 80's and everything was 8-bit by then, may have been different in the UK. I've only hit 7bit (or less) working with some legacy teletype / terminal hardware.
@@weirdboyjim Could you tell me what would be the voltage levels I would get if I buy a usb to db9 cable as I am using the usb I guess it will be 5V but I dont have it and I dont want to buy it just to check that. Sorry for asking so much
6:30 You are putting a low-impedance source (the crystal oscillator) into a high-impedance sink (the oscilloscope), and you wonder where all the ringing comes from... And why a bypass capacitor between VCC and GND doesn't help it. The ringing comes from source and sink not being impedamce-matched even remotely. You can put a 1K resistor between output and ground, that would already improve things. Also, bypass capacitors shouldn't really be viewed as DC stabilizers. Rather the switching of active components causes high-frequency AC signals that travel away from the component. In order to avoid them traveling to other components and/or reflecting back, a bypass capacitor simply shorts AC components to ground, by forming a low-impedance path to ground. In this example here, it has no effect on the output because it's literally the only component on the breadboard, which in itself has already quite a lot of capacitance, and the USB-UART that powers it will also have caps that short out AC signals emittes from the oscillator back into VCC. For reference, you could just put your second oscilloscope channel on VCC directly near the oscillator, and see that it stays stable at 5V, while the output reaches voltages higher than 5V. That's signal that gets reflected back, the oscillator itself can't drive the output higher than VCC. Same with the underswing below GND.
Reads like you have taken exception to a side observation of mine at the time. You have to remember that I am a hobbyist, my purpose with the scope in this video was to visualize the uart signals which was achieved. I know just enough about the analogue side to know I know next to nothing.
@@weirdboyjim It is meant as a helpful comment to understand why the ringing is happening, and why it's not a problem with the power supply. I'm also mostly a digital guy, but it's helpful to view capacitors as frequency-variable resistors in the AC domain, and signals as energy that moves along the transmission line, and has to go somewhere. The oscillator is driving the output line, but the energy has nowhere to go, as the oscilloscope presents only an insignificant load. Have been binging your series and greatly enjoying it!
I post most of my schematics after the pcb's have been made and tested over on Easyeda. easyeda.com/weirdboyjim/UART These are a more complete version of the circuit from later videos
Would love to see an implementation of SPI from scratch; seems like it'd be relatively similar to this project. I've wanted this for my homebrew computer projects but haven't put in the time :P
In many ways it's much simper than the UART since you don't have the complexity of managing clock synchronization or unexpected receiving. Big decision to make would be clock source. If you used the processors main clock the circuit can be really simple, but you would have to deliberately wait a few cycles between write and read.
I have built a computer similar to Ben Eater's design. I am trying to implement SPI to interface with a little SD card reader I have. My hope is that I can get it working, write basic ROM code that will read a kernel off of the card into RAM and run it, thereby skipping the constant programming of the EEPROMs. It would also allow for other things like an RTC.
now do it with only 1 serial shift register! if you use the carry bit as a start bit and activate the shift register when the carry is high and you shift in high 1s it might actually work.
Shifting in high ones definitely works but I don't see anyway to "use the carry bit as a start bit", it's only low for half the cycle duration. I can see a few ways to add the extra bit on the front with additional chips but if I'm doing that I find the shift register to be the neatest way to do it. That especially will make it easier to inject the parity bit later.
Anything specific you are suggesting? Most of my videos are already in play lists, the most important ones are the main cpu (What is running the code) - ruclips.net/p/PLFhc0MFC8MiCDOh3cGFji3qQfXziB9yOw and the uart (How it's talking to the terminal) - ruclips.net/p/PLFhc0MFC8MiCs8W5H0qZlC6QNbpAAe_O-
It gets me, on projects like this, how difficult it is to communicate your achievement to your friends.... it's like "look look, I did it!"... "what you made a terminal window go '@@@@@@@@@@'..... i can do that by holding one key down"..... I wish i still had my old RS232 dumb terminal.... because as soon as you've got something in a PC terminal window, it seems so much harder to overcome the "so what factor"...... but enough waffle.... I'd love to see a hand built UART incorporated into the CPU build..... but that might lead to the CPU wanting a boot loader to load code straight from the assembler into the CPU RAM???
Indeed! The classic example of that is the different interpretations of the phrase "I built my own computer". Most people will think you screwed a motherboard and video card into a case.
Nice Video easy on the brain cells :), would it be better to make a user port, and just bit bang the RS232 in software. Hardware TX is always going to be easier than RX. Rx is easy if you know the baud rate in advance. otherwise you need to sync on something. I always find serial input hard, even with uarts, unless you have a defined end of transmission character. E.G carriage return / line feed. random length message are just a pain.
"Better" you say? I would agree it would be much easier to get to this point but this is more about the journey than the destination. I once had to "bit bang" a UART inside a routine that was doing some unrelated work, that involved breaking the work down into cycle perfect chunks that matched the clock rate divided by the baud rate, needless to say I would have appreciated a clock tied shift register at the time.
@@weirdboyjim I agree the journey is the best bit, but the road map for receive with it's clock sync and data buffers is full of twists and turns, i'd let the train take the strain.
Ouu crystals finally getting used. I can't think how to integrate this or do other things with it yet (well apart from some sort of controller for rapid button press game cheating.
Nice design Mathias, I thought about using a max232 to do the line conversion but I come across TTL level signals more often these days. Did you attempt receive?
@@weirdboyjim Thanks, I have since bought the same serial cable. so the max chip is not needed anymore. I did not attempt a receiver, to complicated. I moved to a 68B50 instead. I am very curious to your the next video.
@James Sharman Be also advised that these cables are probably fake they do work and there is nothing wrong with them. but I both 2 of them and they had the same serial number, which is a problem when you want to use them both and have uniq identifiers for each port. they are cheap of course :) . see www.starlino.com/ftdi-chip-real-of-fake-how-to-spot-a-fake-rt232r-rt232rl-and-others.html
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
I think this is one of your best videos. You essentially created a crude UART with only four chips and a canned oscillator.
Thanks CB, that one was quite rewarding.
I look forward to the receive and interface videos.
And yes, definitely add this to your CPU! That'll be very cool.
Thanks Brandon, not sure how many videos this mini-series will turn into at the moment but I'll definitely cover receive and cpu interfacing.
Thanks James. This is a perfect companion to the CPU. UART is one of those terms I heard way back, I know their function, but never really considered it from this perspective.Take Care.
Thanks Jerril, hope you enjoy the rest of this side quest.
I watched this thinking it was part of the planned enhanced IO for the CPU build. That would be so cool. In any case, asynchronous serial data transmission is quite an impressive feat. I look forward to seeing what you do next :D
Thanks Kyle, I'm actually at a strange point where I have lots of different things I could do next, it's hard to decide what to do sometimes.
Thank you sir for your CPU series you showed us practically how CPU works....we appreciate your effort....god bless you...
Thanks! I'm really pleased people are interested in what I'm doing!
That is soooo cool! I would have never have thought of doing that. :-)
Thanks William! Glad you liked it!
These videos are really good and informative. What would really help those who are still learning, is if you added a Shematic at the end of the video so it makes it easier for us to understand whats going on.
In some of the videos I do provide a schematic as I go.
You’re awesome! And I love it by the minute even more of your work!
Glad to hear you are enjoying the videos!
What an awesome new project!
Thanks Seon, I really appreciate that!
Lovely video, as usual, thank you! I'd like to see this getting hooked up to your CPU, mainly because I want to see how you handle buffering, interrupts and crossing clock domains.
I see a couple of other people have commented on the Elegoo breadboards, and I'd second their concerns. I've used 15 of them so far in my CPU prototyping, and about half have been fine, the other half terrible (very poor contacts that make or break contact as you add components at the other end of the board, for example). The BB830 ones I switched too recently were a revelation. Fingers crossed yours don't give you trouble.
I am curious to hear all the comments about the Elegoo boards, the other ones I was using occasionally had dodgy contacts but they also changed the specifications occasionally (I had two groups of boards that wouldn't join with each other). I have enough of these for finishing the UART, I'll pass my judgment on them then.
Awesome new series!
Thanks David! This maybe the shape of things to come, I'll probably do Sound and Video as separate mini series, and then integrate them into the cpu build.
Lucky you! I had to change some software as recently as two years ago to support 7 bit serial :)
Nice work!
Thanks Frank! I was actually thinking while editing that some of the serial terminals at college were 7bits, but 8bits covers pretty much everything I've touched of late.
@@weirdboyjim Mitsubishi HMI still use 7E1, brand new ones in fact.
Lovely bit of tinkering. And yes to all the suggestions ;-)
Thank you olavl, I'll see what I can do.
Love it! I would like to see how you connect it to the CPU. Your design choice will be interesting to see (memory mapped IO, or dedicated IO instruction, or whatever you decide).
I really enjoy how you are exploring the concepts and implementing them.
I don't think that having to accept a variable baud rate is really worth the time or effort though.
Thanks Bob! I already have a basic io instruction that I use for the lcd display, I'll probably do something similar. In this case I'd need 1 output and 2 input ports (There would need to be a status to report waiting data and a busy send circuit). Variable baud rate would just be a matter of having a selectable clock divider circuit between the crystal and first counter, I wasn't planning on doing that unless people asked for it though.
@@weirdboyjim Ah yes.. I remember that now (so many videos :-) )
I bought a load of Elegoo breadboards for my original 8-Bit CPU build but had nothing but trouble with them, so changed to BusBoard 830 boards even though they were a lot more expensive. That was over 18 months ago, so the Elegoos may have improved by now. Let me know how you go with them.
Interesting, All things are relative of course, my previous ones may just have been really rubbish. So far these have been good, but it's just been the one breadboard, couple of holes had to be loosened up but that's common on all breadboards.
Awesome as always. Receive is going to be a bit more tricky I think, since you have the synchronisation to deal with, ie the loading has to start on an external pulse. I'd like to see all of the build in at least this level of detail. :) Makes me want to write a simple UART in VHDL, something I've not yet attempted.
Thanks Lawrence! Receive is indeed the more difficult of the two, but I don't think it's going to be that bad. I look forward to your reaction to my circuit.
@oH well,lord! [NB: I am a s/w guy, not H/W; this is my un-informed vision] I have always envisioned a 16x oversample implemented as a divide by 16 counter which is reset when the the start bit arrives. That reset synchronizes the output of the /16 with the incoming clock signal. (16 is a bit arbitrary. It needs to be at least 2x (Nyquist); but larger values are more tolerant of differences in clocks.) It may be the reset should set the /16 counter to 8, so that the the sampling occurs in the middle of the bit?
Pretty much, the start bits always being low and the stop bits (and resting state) always being high guarantee you a high to low transition at the start.
Great as always James. To answer your question, I'd like to see you build a full fledged bi-directional serial port connected to your cpu (using interupts for instance) so that you can have some sort of serial user interface to it. It's ok for me if you hardwire the speed such as 115kb/s 8N1 because there is no great value in handling all the details of variable baud rate or parity or other. But then you would need some sort of CPU supervisor to handle the interface.
Thanks Ced! I'll definitely get as far as a bi-directional, I've already said that I'll not be implementing interrupts (On this cpu build) so it will need to be polled (Just like the early micros).
Lovely experiment, and yes to more tests!
Thanks Andrew! Glad you are find it interesting!
Kind of thing you could cobble together with bits (no pun intended) after the world ends to interface with old gear. Very nice explanation
Thanks Twobob! I enjoyed putting these circuits together.
Awesome! Now i'm waiting for the receiver part!
Thanks! I predict the circuit will be a surprise to everyone who thinks receive will be much more complicated than transmit.
I bought a couple of tiny OLED displays (I'm talking 1cm x 1cm) and they have only control pins: VCC, GND, SCI, and SCA. Since you are doing serial, I believe you could find a way to hook up one of these displays to your CPU so you could print out text/render images with the CPU. If you are going to get some displays, don't make the mistake I did and get the tiny ones... Another idea would be some serial input, like adding a keyboard. I know the receiving is much more difficult to implement than the transmission, but seeing as this barely took 1 breadboard to make - I think you're up for the challenge.
I suspect your lines are actually SDA and SCL, these would be the data and lock lines of a I2C connection. This is slightly more complicated than UART but I might take a look at it in the future. Certainly for a basic TTL cpu build I would stay away from I2C, not least because they are very modern components that don't really feel "in the spirit" of designing from the ground up. I will indeed be doing receive, a ps2 keyboard interface would actually be quite easy, the receive should be easier than UART because it comes with a clock so you don't need to do any clever synchronization.
I’d love to see a UART circuit hooked up to your CPU with code to echo the input out to your little LCD display. It would be neat and probably very useful for future coding projects on it.
Interesting, my thinking was that it would be nice to get my test programs outputting to a serial terminal. My prime number finding program is "assumed correct" because I've paused it a bunch of times and checked what was on the 4 line display, with a serial output I could capture it and actually check them all.
FAB! would love to see your CPU sending & receiving data from serial.
Thanks Paula! I definitely want to get send/receive going from the cpu. Driving a serial terminal would make for a more interesting test display than the lcd. How is your build going?
Thanks a lot!
You're welcome!
I found Elegoo breadboards to be horrible. Hopefully they've fixed things by now, but when I bought them, the springy contacts were atrocious. Loose, poorly aligned such that it was often difficult to plug components in... Hopefully you will have better luck!
You might get less ringing in the edges of the clock signal if you use a shorter ground lead. Ideally your probes came with some little spring like ground leads that hook on to the end of the probe, usually results in a much cleaner waveform. Breadboards are commonly quoted as being fine up to about 10MHz.
So far they seem ok, so things might have improved. The ringing is really high, I know a shorter ground lead helps but I've had far sharper edges on the breadboards without shortening the ground leads.
@@weirdboyjim maybe this oscillator has really fast edges (rise/fall times). Could try probing through a resistor of 50 or 100ohm perhaps. Would take some of the bite out of it.
@@weirdboyjim It could be the power supply to the oscillator. Running power and ground to the same power rail on the breadboard should help a lot. You could also solder one end of a cap to the body of the oscillator(should be GND) and plug the other end into 5v.
Very nice! Makes me feel just a little guilty for using off-the-shelf UARTs for my Magic-1 HomebrewCPU.
As well you should! Just as I should feel guilty for using custom pcb's rather than wire wrap, and we should both be ashamed for not cooking our own transistors. ;-) It's an honor Bill, your build is an inspiration. Maybe when I'm finished with this thing we can do a collaboration to compare architectures.
We are trying to build a UART from scratch ourselves can you help us with this circuits diagram and specifications?
There will be another video soon adding buffering, schematics will be available one I've converted it to pcb.
@@weirdboyjim Glad to know!! Eagerly waiting for it as we re trying to follow your exact instructions while making the same ! you are Excellent at it !
Cool, maybe I will use this principal for my transistor-based computer.
7:29 Indeed, any quad flipflip out the 7400 serie will do the trick, no special need for a 74**193, I guess that a 74**193 costs more because the extra circuitry inside.
I've not noticed a significant difference in the pricing. Manufacturing a dip part at scale I doubt it makes much difference, I don't like unused functionality though.
why do you use LS on the breadboard and HCT on the PCBs? is there some fundamental difference between TTL and CMOS that makes one more suited for breadboard applications?
som cursory research implies that HCT has superseded LS for almost all use cases.
The most direct answer to that is actually that I probably would have used LS on the pcb's had I been able to get all the parts but in smd (which I wanted to use on the pcb's for compactness) they were all easily available. HCT in this context was a bit of a compromise that allowed me to intermix with the LS on the breadboards as I gradualy converted from one to the other. In the final build when it's all PCB HC would have been better, but HC would have been a complication to the breadboard build for a couple of simple reasons. LS was what I had, and LS is far more tolerant of unused inputs being left floating so it's better suited to dabbling on a breadboard.
Definitely would love to see this interfaced with your CPU so you could do more than just the LCD for comms.
It would be nice to get string print over serial so I can capture the entire output from the primes demo. With Ansi codes it would actually be possible to start writing games targeting a serial terminal.
Wonderful test of concept but won't work with your CPU as this circuit have a timing issue and actual UART have a data buffer to compensate. You will also need a T flip-flops or state machine for automating start and stop bits.
Thanks for sharing ✨✨✌
What "timing issue" do you think the circuit has? Interfacing this to the cpu should be fairly easy, but it does need a couple of extra chips than I have here. You don't need special circuitry for the start and stop bits, you just hardwire their inputs to the shift register so it "load's" 0 and 1's in the right places alongside the data for sending. Receive gets a little more complex and you do need to be able to buffer at least one byte of input.
@@weirdboyjim I think he's referring to the oscillator not being synchronized with the start bit. There is a very small chance that the other side transmits data right on the edge of a clock pulse. If I remember correctly those converters start their clock only when rx goes low so sending shouldn't be a problem. I don't have a big can oscillator with enable, can you check if yours does and if it does how long it takes to enable it? Awesome video!
I tried using a 1MHz Oscillator and a baud rate of 6250 with Putty, (1MHz / 16 = 6250) but it won’t show any output. Any clues what’s wrong?
1Mhz / 16 is actually 62500. That's a very nonstandard baud rate. Your usb->serial device may not reproduce that properly. I strongly recommend you get a 1.8420 oscillator or one of the others that it is a good multiple of a common baud rate. It will be far easier to test. Do you have an oscilloscope? You should be able to confirm the output looks right regardless.
@@weirdboyjim Yes I checked, it gives 62.5kHz indeed. Thanks for pointing that out. I’ll see if I can get a multiple of common baud rates because I can’t find your Oscillator anywhere 👍🏻
@@davidrosset4457 the 1.8432's are common. Some of the bigger suppliers only have SMD ones though. The through hole ones are still widespread though. I recently ordered some smaller ones on ebay to save some board space.
I've watched this playlist and then compared what you did here to the design of the UART I did a year ago for my redesign of a PDP-8 I also did back then. I had to add synchronization logic to handle the crossing of the two clock domains or else the length of the startbit could vary up to 1/16 (6.25%). I don't see anything for that here. Do you consider that a non-issue or is it solved inherently in the design here>
You mean on the transmit? It's kind of a non issue in this design, the first bit sent is actually high so that bit being of varied length depending on where in the uart clock the operation happens doesn't matter. The start bit is the second bit in the shift register. On the receive that is indeed a potential misalignment of 1/16th of a clock. The bits are read at the midpoint of the bit rate clock so I don't think there is much cause for a problem. All that aside, the new fifo circuits I'm in the process of adding will actually simplify things a bit further, they will a literal buffer between the clock domains and eliminate the theoretical race conditions I might be open to at the moment.
Ok I got a 1.8432 Mhz Oscillator but I don’t seem to be getting any output on the 74LS165… the clock gets divided fairly though to 115200 baud. Any clues what might be wrong?
Have you got an oscilloscope? Check the clock inhibit line is low (pin 15) then make sure the load line goes low with the right data on the inputs. Are you definitely getting nothing out of pin 9?
I get maybe 200mV on pin 9. I did notice the ground in pin 15 is actually about 1.6V. Can this be influencing results?
@@davidrosset4457That sounds very wrong. Pin 15 should be fully ground, that sounds like you have an output line fighting your ground. Have you got a different 74LS165 to try? That sounds like your chip maybe broken or mislabeled.
@weirdboyjim I think chips are broken. I’ll order some more and tell you the results.
@@weirdboyjim I made it work. Turns out I had problem with the bridge connection of the breadboard, I replaced bridge cable and it worked.
Very interesting, could you show the full circuit sometime? I find it hard to follow along without one to look at, thanks
I've have a planned tweak to the circuit, one that's done I'll share the full schematic out alongside the pcb.
@@weirdboyjim that’s great, thanks 🙂 Btw if you look up some of the early Kansas cassette interface designs, they were a primitive version of this
Can I do this with a 1MHz Oscillator or 2 MHz?
Interesting question. You can try, I use counters here to divide the clock down. You would need to play around with the maths and see if the device you want to talk to supports a bit rate that you can achieve with the clock you have.
Awesome video. It will be nice if you combine this circuit with your CPU to have a serial text generator.
Thanks Leonardo, I'll definitely do this, I don't know if I'll include the serial port in the final build of the cpu but having it as an interfacing demonstration makes a lot of sense.
@@weirdboyjim And of course for interactive debugging, ie. a machine code monitor. You *must* write one. :)
Only seen 8 bits... you mean in modern times using terminal to talk to your microcontrollers and such? Back in the 8-bit era, you might recall 7E1 when dialing into BBSs and using peripherals.
I didn't hit the bbs scene until the late 80's and everything was 8-bit by then, may have been different in the UK. I've only hit 7bit (or less) working with some legacy teletype / terminal hardware.
Does the USB to UART cable work in Windows 10 I am about to buy and would like to know that, thanks for your amazing knowledge
The one I have does, I know some have issues.
@@weirdboyjim Where did You buy yours ? I can't seem to find it on Amazon. Thanks for answering, really appreciate it
@@weirdboyjim Could you tell me what would be the voltage levels I would get if I buy a usb to db9 cable as I am using the usb I guess it will be 5V but I dont have it and I dont want to buy it just to check that. Sorry for asking so much
6:30 You are putting a low-impedance source (the crystal oscillator) into a high-impedance sink (the oscilloscope), and you wonder where all the ringing comes from... And why a bypass capacitor between VCC and GND doesn't help it.
The ringing comes from source and sink not being impedamce-matched even remotely. You can put a 1K resistor between output and ground, that would already improve things. Also, bypass capacitors shouldn't really be viewed as DC stabilizers.
Rather the switching of active components causes high-frequency AC signals that travel away from the component. In order to avoid them traveling to other components and/or reflecting back, a bypass capacitor simply shorts AC components to ground, by forming a low-impedance path to ground. In this example here, it has no effect on the output because it's literally the only component on the breadboard, which in itself has already quite a lot of capacitance, and the USB-UART that powers it will also have caps that short out AC signals emittes from the oscillator back into VCC.
For reference, you could just put your second oscilloscope channel on VCC directly near the oscillator, and see that it stays stable at 5V, while the output reaches voltages higher than 5V. That's signal that gets reflected back, the oscillator itself can't drive the output higher than VCC. Same with the underswing below GND.
Reads like you have taken exception to a side observation of mine at the time. You have to remember that I am a hobbyist, my purpose with the scope in this video was to visualize the uart signals which was achieved. I know just enough about the analogue side to know I know next to nothing.
@@weirdboyjim It is meant as a helpful comment to understand why the ringing is happening, and why it's not a problem with the power supply. I'm also mostly a digital guy, but it's helpful to view capacitors as frequency-variable resistors in the AC domain, and signals as energy that moves along the transmission line, and has to go somewhere. The oscillator is driving the output line, but the energy has nowhere to go, as the oscilloscope presents only an insignificant load.
Have been binging your series and greatly enjoying it!
Great video. Do you can post de full schematic ?
I post most of my schematics after the pcb's have been made and tested over on Easyeda. easyeda.com/weirdboyjim/UART These are a more complete version of the circuit from later videos
@@weirdboyjim Understood, thanks. And nice project
Would love to see an implementation of SPI from scratch; seems like it'd be relatively similar to this project. I've wanted this for my homebrew computer projects but haven't put in the time :P
In many ways it's much simper than the UART since you don't have the complexity of managing clock synchronization or unexpected receiving. Big decision to make would be clock source. If you used the processors main clock the circuit can be really simple, but you would have to deliberately wait a few cycles between write and read.
I have built a computer similar to Ben Eater's design. I am trying to implement SPI to interface with a little SD card reader I have. My hope is that I can get it working, write basic ROM code that will read a kernel off of the card into RAM and run it, thereby skipping the constant programming of the EEPROMs. It would also allow for other things like an RTC.
now do it with only 1 serial shift register! if you use the carry bit as a start bit and activate the shift register when the carry is high and you shift in high 1s it might actually work.
Shifting in high ones definitely works but I don't see anyway to "use the carry bit as a start bit", it's only low for half the cycle duration. I can see a few ways to add the extra bit on the front with additional chips but if I'm doing that I find the shift register to be the neatest way to do it. That especially will make it easier to inject the parity bit later.
You need to make playlists!
Anything specific you are suggesting? Most of my videos are already in play lists, the most important ones are the main cpu (What is running the code) - ruclips.net/p/PLFhc0MFC8MiCDOh3cGFji3qQfXziB9yOw and the uart (How it's talking to the terminal) - ruclips.net/p/PLFhc0MFC8MiCs8W5H0qZlC6QNbpAAe_O-
Incrível, saudações do Brasil.
Obrigado!
Seriously cool. Too easy indeed.
Thanks Troy! The receive circuit will be a little less easy, but interesting as well.
It gets me, on projects like this, how difficult it is to communicate your achievement to your friends.... it's like "look look, I did it!"... "what you made a terminal window go '@@@@@@@@@@'..... i can do that by holding one key down".....
I wish i still had my old RS232 dumb terminal.... because as soon as you've got something in a PC terminal window, it seems so much harder to overcome the "so what factor"...... but enough waffle.... I'd love to see a hand built UART incorporated into the CPU build..... but that might lead to the CPU wanting a boot loader to load code straight from the assembler into the CPU RAM???
Indeed! The classic example of that is the different interpretations of the phrase "I built my own computer". Most people will think you screwed a motherboard and video card into a case.
Nice Video easy on the brain cells :), would it be better to make a user port, and just bit bang the RS232 in software. Hardware TX is always going to be easier than RX. Rx is easy if you know the baud rate in advance. otherwise you need to sync on something. I always find serial input hard, even with uarts, unless you have a defined end of transmission character. E.G carriage return / line feed. random length message are just a pain.
"Better" you say? I would agree it would be much easier to get to this point but this is more about the journey than the destination. I once had to "bit bang" a UART inside a routine that was doing some unrelated work, that involved breaking the work down into cycle perfect chunks that matched the clock rate divided by the baud rate, needless to say I would have appreciated a clock tied shift register at the time.
@@weirdboyjim I agree the journey is the best bit, but the road map for receive with it's clock sync and data buffers is full of twists and turns, i'd let the train take the strain.
Trying hard to wing it again James `?
(with the wings of an ...)
Always Nico! Always!
"AAAAAA" an implementation of Infinite_scream in hardware! Haha
AAAAAAAAAAAAAAAAAA
Ouu crystals finally getting used.
I can't think how to integrate this or do other things with it yet (well apart from some sort of controller for rapid button press game cheating.
Thanks Adam! I've actually realized there would be a way to interface this that's even easier than my first thought. ;-)
Actually, I thought you were building it to interface with the CPU in order to load RAM with contents rather than the cumbersome chip pulling circus.
I do indeed plan on a debug/development interface for the cpu, but this isn't it.
I made something very similar a wile back:
www.reddit.com/r/beneater/comments/cepxk3/uart_module/
Nice design Mathias, I thought about using a max232 to do the line conversion but I come across TTL level signals more often these days. Did you attempt receive?
@@weirdboyjim Thanks, I have since bought the same serial cable. so the max chip is not needed anymore. I did not attempt a receiver, to complicated. I moved to a 68B50 instead. I am very curious to your the next video.
@James Sharman Be also advised that these cables are probably fake they do work and there is nothing wrong with them. but I both 2 of them and they had the same serial number, which is a problem when you want to use them both and have uniq identifiers for each port. they are cheap of course :) . see www.starlino.com/ftdi-chip-real-of-fake-how-to-spot-a-fake-rt232r-rt232rl-and-others.html