|
|
View previous topic :: View next topic |
Author |
Message |
Alanis
Joined: 28 Sep 2007 Posts: 13
|
Outputing binary data |
Posted: Fri Oct 05, 2007 5:45 am |
|
|
Hi.
If the digital data is represented in 1 and 0 then logical low would be 1 or 0. Unbelievable huh
What i want to do is to pass this digital data per port A4, at 19200 b/s but on the way that i can be sure when fall / up edges are defined as they should.
Am not receiving, i want to generate and send this data as output.
Is there any example on this. ? |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Fri Oct 05, 2007 7:34 am |
|
|
The output on PIN_A4 is of the Open Collector type on many PIC processors. Add a pull-up resistor.
Read the #rs232 command in the manual for an example. |
|
|
alan_ Guest
|
|
Posted: Sat Oct 06, 2007 3:25 am |
|
|
Code: | #include <12F675.h>
#use delay(clock=4000000)
#fuses NOWDT, XT
#use rs232(baud=9600,xmit=PIN_A2,ERRORS)
|
I changed the Xmit pin to A2.
What i dont understand in this low - high level sampling.
How to make this ?.
I mean, i guess this should be done on this way
1.) define sampleLevel function under ADC,
2.) pass this sample function to A2.
---------------------------------------------------------
Is this OK or should i use some other way ?
In end effect, i should be able to detect this sample signal on my terminal. So i must be sure that the sampleLevel is passed OK and equal to levelPattern on my terminal, becuse i have to make sample comparation. |
|
|
Humberto
Joined: 08 Sep 2003 Posts: 1215 Location: Buenos Aires, La Reina del Plata
|
|
Posted: Sat Oct 06, 2007 7:18 am |
|
|
Quote: |
I mean, i guess this should be done on this way
1.) define sampleLevel function under ADC,
2.) pass this sample function to A2.
---------------------------------------------------------
Is this OK or should i use some other way ?
|
NOP.
Luckily it is much easier:
Code: |
#include <12F675.h>
#FUSES NOWDT //No Watch Dog Timer
#FUSES XT //Crystal osc <= 4mhz
#FUSES NOCPD //No EE protection
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOMCLR //Master Clear pin used for I/O
#FUSES PUT //Power Up Timer
#use delay(clock=4000000)
#use rs232(baud=9600,parity=N,xmit=PIN_A2,bits=8,ERRORS)
void main()
{
setup_adc_ports(NO_ANALOGS|VSS_VDD); // This is because by default
//the AD inputs are analogs
setup_adc(ADC_OFF); // switch off the internal ADC module
setup_comparator(NC_NC);
setup_vref(FALSE);
while(1) // forever lop
{
printf("Hello world\r\n"); // take out the bits through the defined Tx pin
delay_ms(2000); // just a delay
}
}
|
Set the Comm settings in your terminal to 9600/N/8/1 and you will be able to receive
the sent string.
Anyway you will need to learn how this is done. there are very good books for beginners
regarding PIC MCU and C.
Humberto |
|
|
alan_ Guest
|
|
Posted: Sun Oct 07, 2007 6:43 am |
|
|
Muchas gracias Humberto and others.
You are now passing the Hello World string.
How can i pass the Low - High Signal instead this string?
E.g.
I have predefined levels that look like this:
L H H H L L H L H H L L L
H H L H L H H L H H L H L
etc.
How to send this levels instead string ( at speed of 19200 ).
Can i make this automatically or do i have to make some binary conversion , so that my output would look like predefined levels. |
|
|
Humberto
Joined: 08 Sep 2003 Posts: 1215 Location: Buenos Aires, La Reina del Plata
|
|
Posted: Sun Oct 07, 2007 10:40 am |
|
|
A string or a HLHL level as you say are all binary numbers. The difference is that in a string
they are formatted in a know standard that represent alphanumeric characters.
Quote: |
I have predefined levels that look like this:
L H H H L L H L H H L L L
|
The predefined levels that you have:
Code: |
L H H H L L H L H H L L L H L H has its binary equivalent:
0 1 1 1 0 0 1 0 1 1 0 0 0 1 0 1 that can be arranged in groups of nibbles:
0111 0010 1100 0101 that has an hexadecimal equivalent:
7 2 C 5 that give an hexadecimal number:
0x72C5 which can be represented by an unsigned long integer.
|
To print such value:
Code: |
int16 value;
value = 0x72C5;
printf("%Lx", value);
|
Pls read the CCS Reference manual to know the compiler capabilities.
Humberto |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Mon Oct 08, 2007 8:14 am |
|
|
I don't think he wants to print ascii representation of the hex.
He wants the putc the value and get the HLHLHLLLHL out the serial port.
I think all you need is to figure out the
start and stop bits and parity parts to do this.
I sorry, but I've never done this.
But I bet Humberto,ckielstra, or neutone could help.
Is the sending(PIC) uart conected to another uart?
I ask because then the start and stop bits won't be important, I mean to say, they are take care of by the uarts.
OR
Are you connecting the PIC uart to some other (weird) circuit? |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Mon Oct 08, 2007 4:32 pm |
|
|
Alanis,
I'm a bit confused. Can you tell us more about what you want to do? You say you want to transmit data at 19200 baud but is this normal serial data or something special?
- You give all the HHLHL.. sequences. What kind of data is this?
- What kind of device are you transmitting to?
- What voltage levels for the output? |
|
|
alan_ Guest
|
|
Posted: Tue Oct 09, 2007 2:09 am |
|
|
Before i write some explanation on this project, i must say that this forum is THE best one!. Your wish to help is really something that each of us can be proud of!
Quote: | He wants the putc the value and get the HLHLHLLLHL out the serial port. |
-- correct. So i can detect the whole "signal"
Quote: | start and stop bits and parity parts to do this |
-- 19200 , 8, even, 1
Quote: | Is the sending(PIC) uart conected to another uart |
-- here comes the first problem. I know i would need the max232 for data communication between uart's, but this is something that i cant use ( for now ). So i got this situation:
- I have to pass the signal frame to my other device
- the other device is waiting for signal detection on NON tx/rx line ( it's just I/O line ).
Quote: | the HHLHL.. sequences. What kind of data is this |
-- this is data string defined with 2 bytes. ( A , B )
-- byte A is described as : (0 0 ) 10110 ( 16 Hex ).
-- byte B is described as : (0 0 ) 10111 ( 2F Hex ).
The time between sending of the first and second byte is 0,5 sec.
Quote: | voltage levels for the output |
-- TTL
- i can not use max 232 but i think that there is no need to use one ?
Quote: | Additional question: |
I dont know, but is it possible to output this signal ( at this speed ) to some other port without max232 ?
Alan |
|
|
Ttelmah Guest
|
|
Posted: Tue Oct 09, 2007 7:40 am |
|
|
OK.
So this is standard serial data. Software routines to receive this, and send this, are available on any pin on the PIC, using the #use RS232 statement, and on the hardware UART pins using the same statement.
The MAX232, has nothing to do with the actual sending of the data. what you are describing is standard ASYNC serial communications. These comms, can be sent over a wole 'range' of different interface 'types', after they leave the PIC. The MAX232, is needed if the communication signalling levels want to be RS232 levels. However between devices on the same board, exactly the same software can be used to send the comms over TTL data lines, or using a different buffer, over RS485 etc.. It is really a 'misnomer' in the compiler to talk about the chip generating RS232. It doesn't.
On the hardware pins, the signalling standard is the form needed by the RS232 buffer chips. So, the lines 'idle' 'high', and drop to signal the start bit, then data is sent with a high level giving a '1', and a low level a '0'. This can be reversed on the software pins, using the 'INVERT' keyword.
Now, there is a bit problem. The two 'data sreams' shown, start with different bits. This is not legitimate. Both must start with the same bit, or you will never be able to detect the 'start' of a character, without external signalling. After all, if the line idles 'high', then you cannot tell where the second stream starts, while if it idles low, you cannot tell where the first stream starts.
Data is sent over standard async serial,in order LSbit first, followed by the parity, and finally the stop bit(s).
Now the poster at one point says he wants 8 bit, even parity, one stop bit. This will require each transmitted character to be 11bits long (one start bit, 8 data bits, one parity bit, one stop bit), but the bit sequences shown, are thirteen bits long. One or the other statement is wrong...
So, you need to start by identifying what the real bit sequences are, and whether the line idles high or low between the sequences. My suspicion would be that the sequences shown, are 'snipped' out of a full length sequence, with parts missed (possibly the first start bit), and then they contain data from more than one transmitted byte. The other possibility, is that this is a custom interface, using non standard comms, the '8E1' staterment is wrong, and then a custom bit shift/output routine will be needed. However to generate this, the real details of the signalling will be needed, not a 'guess', based on some logic levels possibly sampled using a scope...
Best Wishes |
|
|
Alanis
Joined: 28 Sep 2007 Posts: 13
|
|
Posted: Tue Oct 09, 2007 9:44 am |
|
|
@Ttelmah
There is just one small part that i want to talk about per PM.
Please be so kind and send me PM ( cuz i dont know if you are registred ), so i can explain you the main thing behind this data communication.
@ckielstra
I have send you PM too and humberto is the next one :-)
anyway i will continue to write this per forum but there is just few things that i can not write. Hope you all understand...
The MAX232, is needed if the communication signalling levels want to be RS232 levels
-- they dont need to be. I just have to find a way to read/generate them.
generating RS232. It doesn't.
-- i understand what you mean.
'high', then you cannot tell where the second stream starts
-- you are partly right. This part is standard used in card communication.
require each transmitted character to be 11bits long
-- damn this forum is great!. Correct again.
sequences shown, are 'snipped' out of a full length
-- the sequence is partly equal to one sequence send by chip card (ATS)...
All in one, you can look at this like onto some normal communication with the simcard and external device ( in my case the board with PIC ). |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|