Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.
Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.
When I send Hex numbers from my PIC to a PC, I have to convert the received data with ASC(var) for the data to be preserved. The PC's serial port does its tx/rx data in character strings. Sending out 'A' from pc will serially shift out decimal 65. Sending out 65 will serially shift out 54 + 53
I do not know what programming language you are using to send the data, but try converting the data at the PC before sending it to the PIC.
1.
A = 255
serial_out(CHR(A))
2. use the modifier DEC VAR in the PIC serin line to convert the data into character code.
Pure 35 instructions PIC assembly code is the only way to go.
You should be able to read pure binary data from the PIC UART. The ascii 'a' is the same as the number 97 (the binary is the same) whether it an 'a' or 97 is entierly up to your program. So if the computer sends a binary number you can read that number in the PIC.
The fact that the ascii characters have tha same binary as numbers lets you do some interesting things; adding 'A' to 'B' is perfectly valid (though it doesn't really do anything useful).
A software UART works just as well, with the advantages that you can use any pin, and don't have to use a MAX232 for it's inversion.
I don't use PIC BASIC, so I comment on that, but there's no reason why it's software UART can't send out binary data. My software UART routines (and the hardware ones) both handle binary data perfectly - it's only a question of sending the data (from 0x00 to 0xFF) out of the pin - any limitations are probably in your compiler. As far as the UART is concerned, there's no difference whatever you send through it - all data is identical, and all data is binary.
A question, are you forwarding the input to and LCD display? If so, you may need to ad 0x30 to numbers prior to outputing to an LCD display. How is serin sending data?
where can i find a uart software?
or how to do it could you give me a hint
about the question if i'm using lcd no
i just want to put binary data from pc to pic using 16f84
i don't know how to do the hardware of connecting pc to pic what do i use?
please if somebody can help me i'm very thankful
where can i find a uart software?
or how to do it could you give me a hint
about the question if i'm using lcd no
i just want to put binary data from pc to pic using 16f84
i don't know how to do the hardware of connecting pc to pic what do i use?
please if somebody can help me i'm very thankful
That will put the into MYVAR the value transmited. So if you transmit an "A" from the PC, MYVAR will have a binary 1000001 (or dec 65). if you want to receive more that one character, then you can add MYVAR2 after MYVAR to allocate space on that variable, and so on.
I believe you are a little bit confused with the whole transmitting stuff serially.
In a nutshell, serial transmition can be done asynchronous or synchronous, all that means is wheather or not you supply a clock. Since you are talking to the PC you normally use asynchronous (no clock siganl supplied). The Serin command handles asynchronous transmitions only.
Asynchronous transmitions have a format or "protocol", to understand better you need to do some research, but the protocol is that when a transmitions begins the first serial bit sent is a START bit. Then it sends a Parity bit (some error checking), then the DATA is sent. The data consists of only 8-bits, so you can only send numbers from 0-255 or in other words binary 11111111., then the last thing sent is a STOP bit. So [START]-[PARITY]-[DATA]-[STOP] is the packet sent serially each time.
Since the DATA is 8-bits, that is where the ASCII enters. ASCII stands for American Standard Code for Information Interchange. IT is just a STANDARD that everyone has agreed on and so that you know if you receive a decimal 65 (which is the same as binary 1000001, hex 41) you can interpret it as an A (not lower case a). Do you have to interpret it as an A? No if you don't want to, but you know that if you use hyperterminal and you type an A, you know that your pic will receive a dec 65. The ASCII codes go from decimal 0 (NULL) to decimal 255(empty). Check https://www.asciitable.com for all the values. Can you guess why do they go to 255 only?
So after all these my point is that it doesn't matter what the PC sends, is what you interpret it to be. ASCII are binary numbers with a meaning, but they are still binary numbers and you can give them any meaning. So if you want the PIC to start the Cold fusion machine when it receives binary 1000001 from a PC, then you make sure that the PC sends an "A" but when you receive it make sure that you check you received binary 1000001, which at the end is the same thing, just a standard :lol:
ok thank you for the help
but i still need to know what do i use to connect the pc and the pic
someone told me that i don't have to use max232 i didn't understand why?
Well, normally, a pc outputs a negative voltage (for example -10V) for a logic 0 and a positive voltage for a logic 1...
Since you only want to receive yo could just do with resistor in series with thez signal and a diode from signal to ground (after the resistor, Anode to ground)...
The resistor will drop the high positive voltage from the pc and make it safe for your pic, while the diode will connect the negative voltage to ground
You need 3 wires minimum :wink: Tramsit (Tx), Receive (Rx) and common.
Here is the deal. The serial port in the PC, uses voltages between -12 to +12V. So a 1 is represented by a -12V to -3V and a 0 is represented by +3V to +12V. So as you can see this is very different from your normal TTL logic, of 5V for 1 and 0V for a 0, and in a sense it is INVERTED.
There are two options to connect the PIC to the PC. The right way and the no so right way. The right way is to use a voltage converter that transforms these -12V to +5v for your 1 and +12 to 0V to for your 0. You use a MAX232 (or any of its friends) to do this. What this creates it is no INVERTED any more.
The no so right way to do it is to connec the serial pins straight to the PIC. So that when it receives a +12V or -12V the clamp diodes in the PIC will make sure that a +5V and a 0V is received instead. But as mentioned earlier the data you receive is INVERTED meaning that when the PIC sees a 5V it is not actually receiving a 1 but instead it is a 0. This is not the so good way because when the PC expects a 1 (-3V to -12V) you will be supplying it with 0V. These can cause errors, but by experience I have never had any errors as long as you keep the cable short, and there is not much noise, the PC hardware will take care of the rest and interpret the 0V as the 1 it was meant to be. In older computers it might not be true.
The Serin command of PIC BASIC allows you to adjust for this, you can chose wheather to accept INVERTED on NON-INVERTED transmition, by selecting the right MODE.
I forgot to mention before that you must make sure that you chose the right baudrate. Which only means that both devices are talking at the same speed. A 9600 baudrate is pretty normal to use, although there are faster rates. Then depending on how you connect your hardware you have to chose between 9600 inverted or not.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
