Okay, today we are going to talk about connecting our PIC10F200 to our computer via a UART or
universal asynchronous receiver transceiver?
Receiver transmitter.
Between the two of these and basically figured out I think right now we're going to be focusing
quite a bit on what that is in general and that communications protocol.
But of course we'll also go through how we program the PIC10F200 in assembly to actually
execute it.
Now the PIC10F200 does not have a UART hardware portion in it.
So it is all going to be bit-banging.
It's all going to be done in software, which is going to be lots of fun, really exciting.
So we have my computer that's hooked up with a USB to serial converter and then this serial
converter goes to an RS 232 converter, which takes that serial communication and changes
it to the same voltage levels that you would expect from the UART.
Because really serial communications and RS 232 communications and UART use the same protocol.
Call and they're just a different, different voltages.
And there are some other minor differences as well, one of the things that you might
notice is that this is a DB9 connector.
And so that means there's nine pins, whereas we're only going to be worrying about basically
two or three things.
And that's ground connecting it and then receive/transmit.
And that's really all we need to worry about the rest of the other six pins are just hardware
control and some sort of stuff to make sure that everything's working great, which for
us, we don't care about.
So again, we just got this Sparkfun thing that I bought years and years ago, I'm sure
they're still selling this or something like it.
And then I also bought this USB to serial thing years and years ago, I don't remember
what it is Sergey has in the written tutorials, his recommendations and what he used for those
for the written tutorial.
But for us, this is all we're using.
So let's get into what a UART or universal asynchronous receiver transmitter actually
is.
Now, universal just means universal like you're going from a microcontroller and actually
are able to talk to a computer so assuming that's what the universal talks about, or
what it means.
The asynchronous is different though, notice how we only have the receive and transmit,
that means that there's not a line that is providing a clock, because that clock would
synchronize everything.
And the way this works and the way it works asynchronously is that you say, in this case,
particularly, we want to communicate at 9600 baud.
And you make sure your computer is set up to receive and transmit at that speed and
make sure your microcontroller is setup.
And then, once either one sends a start, but after that, it just waits a certain amount
of time and says, okay, it's been a certain amount of time measure, measure, measure.
And so if you have any differences in the baud rate, it's not going to work because
one's going to be saying, hey, you should be measuring every, I don't know 20 microseconds,
and the other one says, Okay, I'm measuring every 30 microseconds, so you're gonna be
off with that.
Let's look really quick on what a UART waveform looks like.
Now it is a active low, so when your voltage is typically high, and when you're actually
sending the signal it drops down.
So the first start bit, the thing that says, hey, I'm about to send some information and
let's start our internal asynchronous clock, it drops down.
So on the receiving end, it says, Hey, something just dropped, let's wait a predetermined amount
of time and then take a sample is this a one or zero, and then wait a predetermined amount
of time, one, or zero, or one or zero.
And most of these packets are eight bits.
So you have one bit to say, start.
You have eight bits of information.
And then one bit that says stop.
And that's the end of the packet.
And that's really it.
UART...
I've heard other people say that it's difficult.
that's never been the case for me.
I've always found the UARTs and this form of communication to be very, very straightforward
because it you don't have to have that clock.
You can just set the baud.
It's fast enough for sending little packets of data.
And it's just great.
So I don't know, other people may disagree with me, but I think you are is very straightforward.
Okay with that out of the way.
Let's look at this again really quick.
You'll notice that it's not just the communications equipment.
We have switch on here, or button, excuse me, and then we have an LED.
And what we're doing here is I'm going to use the button.
So when we press the button, it will send a message to the computer, basically just
saying hello.
And then on the other side, I can send a one or a zero to turn the LED off and on.
So we're going to show that we can go both ways on this.
So that is the hardware we have set up here.
And if you want to see that schematic we'll either flash it up on the screen at some point,
or you can just go to circuitbread.com and look in the tutorial because we'll have all
of this stuff up there actually, it is already up there.
So you can just go and look at that one final word of warning.
And I think perhaps the most confusing thing with not only a UART but any communications
is receive and transmit, go opposite.
So one is transmitting.
One is receiving, the other one is receiving the other one's transmitting.
So you got to make sure that you're not hooking transmit up to transmit receive to receive,
because if you do, it's not going to work and it's going to be terrible.
Actually, I'm totally kidding.
There's not going to be any problems.
It's just not going to work.
And one of the first things if after setting something up, it doesn't work and you're not
sure, you can just swap them.
And if that still didn't fix it, I'd swap it back.
It's not going to hurt anything.
But that is the most common thing that most that I've seen people.
Oh, which, which one?
It gets even more confusing once you have this in here like Oh, is that the receive?
Is that where I'm supposed to be hooking the receive up for the microcontroller?
I don't know.
Don't worry about it, take your time.
And even if you get it wrong, it's not gonna break anything, you can just swap it and try
it again.
So with that, let's move on to the hardware.
By that I mean software.
Okay.
Now in the software, we have our initial, everything is normal on the first 15 lines.
We don't even need to worry about it.
I will say one thing that line 16 we set GP2 as high and GP2 is our transmit so our microcontroller
is transmitting from that.
And since, again, active low, we want it to be high when it's just idle.
So that is what we're doing here in 16 is we're setting GP2 as output high.
Now the rest of it, we have a loop from lines 17 to 44.
In this loop is going through, and just one checking to see if the button is pushed, and
two checking to see if we've received a command from the computer.
And we'll get into the details there.
But past that we only have two other sections, we have 46 through 66, which is our subroutine
that transmits data from the microcontroller.
And then we have our subroutine, our receive byte from 68 to 93, which is how our microcontroller
receives data from the computer everything from 94 and below I'm not even going to worry
about at this moment because it's all delays and we've talked about delays in several other
previous tutorials.
If you're still confused about those, go back and check those out.
So let's go back and look at our loop.
So this is our main function.
And from this main function we call the transmit byte and the receive byte subroutines.
So number 18, we have our bit test file, skip if clear.
And so basically, we're checking GP3, which is the button that we have right here.
And it's checking to see, hey, has anybody touched the button, if it has been pushed,
then you skip 19.
Otherwise, if it's not been pushed, it jumps from line 19 to go to wait receive, which
is down in 41.
And at that point, it checks to see if we've received any messages from the computer.
So let's imagine that we have pushed the button.
So in line 18, we skip down to 20.
And we do our debounce delay.
So hey, that actually happened was that a real thing?
And once it goes through, and we've verified that we've actually gotten a message going
through all of those debounces until line 26 once it's 26, the microcontroller says,
Hey, I know I got something.
So I'm going to send the message through the UART.
And so each one of these lines is basically saying, okay, we want to transmit the 'H'
so we're going to move that literal into the working register and then the call transmit
byte.
So call transmit byte, then, which we'll get into a little bit later, then transmits what
is in the working register.
And then we go through if you look through, it's H, E, L, L, O, and then basically two
commands and ASCII code that say, give us a new line.
So you also know that we have 'H' in single quotes.
And by doing that, instead of sending the H, the compiler knows to take that 'H' and
send the ASCII equivalent of the 'H', which I don't know off the top of my head, but whatever
that is, it's sending that and so both the microcontroller and the computer when it receives
an ASCII code, it knows Oh, hey, that's a capital H. And then that's a lowercase 'e',
oh, that's a lowercase 'l'.
And so using those single quotes makes it so you don't have to look at the ASCII table
and saves a lot of time.
And it's fantastic.
So that is basically it for sending the message.
And we'll get into the transmit byte subroutine more in just a second.
But it's pretty straightforward, whereas the wait receive just goes and checks to see if
the GP1 level is set or skipped, and GP1 is the receiving pin that is checking to see
if we're getting any messages from the computer.
So if it does get a computer, it calls the receive byte subroutine.
Otherwise, it goes to the GOTO loop and jumps back up to line 17.
So that's the basic overarching structure of the subroutine.
Basically, check to see if the buttons been pushed, if it hasn't checked to see if it's
received the message.
If it hasn't started that over again, if the button has been pushed, send the message message.
If it has been pushed, the first thing it does, as soon as it sends that message to
the computer is then check to see if the computer sent anything back.
And so that's basically it.
So now let's jump into the transmit and receive byte.
So line 46 and transmit byte.
And remember, a byte is eight bits.
So we are sending one eight bit byte, which is the length of an ASCII code.
So here we take the information that was in the working register, and we put it into the
transmit data register, we clear the count, because we're going to have to send each individual
bit by itself and so we need to count how many bits we've already sent.
So we clear that count, we then take GP2 and we drop it down.
As I mentioned, that is the signal like oop, okay, we're about to get something.
So it drops it down.
And then it calls the UART delay, because again, we are going to do this at 9600 baud.
And that's slower than our microcontroller can think.
So it says, okay, drop it down, sit around for a little bit, and then go to the next
thing sit around a little bit.
So that's why we need all of these delays.
So once we've finished with that delay, we then go to starting to shift the database.
And so the thing we do first is we see if the bit we're looking at is a zero or a one
and using the BTFSC.
So if it's a zero, then we skip line 53.
And if it's one then we have a GOTO setting the bit.
So all we're doing at this point is saying is this is one or zero and depending on what
it is, then we either set the output as a high or low and then once we go through that
we're now on line 58 where we are delaying we have that delay.
We take that data that we have in there, and we shift it by one bit, increment the count
register, check to make sure that the count hasn't already hit eight, because if we've
already done eight, then we're done.
And if we haven't already done eight, then we start this internal process over again,
send the next bit, shift, check, send the next bit shift, and then keep on going.
And then once it's all done in line 66, we RETLW.
And we jump out of the subroutine and go back into the main loop.
And so that's that's really it is all we're doing in 46 through 66 is looking at that
eight bits, taking a sample, shifting, taking a sample shifting, taking a sample and making
sure that we're pausing in there enough time that it is matching up the timing of what
the computer is expecting when it is receiving that sample.
So let's jump into the receive by really quick, and then we'll be done with all this we'll
do a demo really quick and we'll be done with this and you will feel so much smarter.
So the receive byte is basically the opposite of the transmit byte but there one important
thing I'd like to point out in 69, there is the call half UART delay.
And that is simply something where if we noticed that we are getting the start bit from the
computer, we want to wait just a little bit so that we are taking samples in the middle
of the cycle and not on the edges.
Because if we're on the edges, then it's more likely that we might, if we're a little bit
too fast, we're going to get the previous data for a little bit too slow, we're going
to get the next data or something along those lines.
So we want to have that delay to put us right in the middle.
But other than that, it's the same concept.
And all you're basically doing is taking the data as it comes in and saying, Okay, put
the first piece of data there, shift, put the first second piece of data there, shift,
put it there.
And each time you're doing that you're checking the count to make sure that you haven't run
out, and then you're out of space and you're not sampling the right thing anymore.
And that's really it.
So I'm not going to get into detail on the receive byte because it's just the transmit
byte in reverse with that delay is something that you should worry about.
So with that, let's take this program, download it, put it on here, and I'm going to show
you show it to you in operation.
Okay, now we have it set up.
So on here, since I'm using a Mac, I'm used to the Windows machines where I used hyperterminal
or whatever.
But on Mac, there's a pretty cool program.
It's called Serial.
I've only used it to do this and so I don't have a whole lot of experience with it.
But I love just how quick it was just plugged it in, and it just worked.
So as you can see on the screen capture right here, there is the window where I should be
receiving data in the window where I can send data.
So let me press this button here and see what pops up.
Oh, it just popped up Hello, you so you see how it popped up said hello and now it's on
a new line.
So if I push Hello again, it's doing a lot doo doo.
And then down here I can type a one to turn it on and a zero to turn the LED off.
So let me put the one in, press Enter.
Now the LED is on.
Now let me put a zero.
Now the LED is off.
So you can see communication both ways - receiver transmitter, that's pretty simple but at the
same time, you can get really powerful and make very interesting interfaces where you
can get a lot of good, easily readable data from your microcontroller.
And I remember the first time I was able to get my UART to communicate with my computer,
I felt like top of the world I think it's 11:30 at night, and my kids were asleep and
I was jumping around super happy because I've been banging my head on it because I didn't
know Sergey at the time, so he couldn't help me figure stuff out.
It's just a wonderful feeling to be able to see actual, "Hey, I did this and it's showing
up here and hey, I'm doing this and coming over there."
Maybe I'm just crazy.
That's entirely possible.
But I hope that was a good overview of what what the UART is and also how to bit bang
or create your own software your interface and can communicate between your microcontroller
the PIC10F200, specifically, and your computer.
If you enjoyed this video, give it a like, subscribe to our channel and we will catch
you in the next one.