Printable View
Hi. I am 15, and I quite a newby in PICs.
I am working on a LED cube project, and need to send 32, 64, or 96 bytes through serial communication. Which is the higher speed I can get running at 20 Mhz??? And running at 40 MHz???
Also, is it better to use the USART module??? How does it work???
I hope you cal help me!!! This is a great forum!!!!
Thanks
Manuel
PS I hope i posted this thread in the right place!
Yes, it is better to use the USART-Hardware.
What speed is your PC able to handle on his serial port ?
I think, the PIC will manage it also!
Hi. Thank you for your answer. I have no idea what serial speed my serial port can take. I may also end up using a USB - to - Serial adapter just in case i burn everything!!! ahah.
Is it possible to reach speeds like 115200 bits per second with pics???
Sorry for my english!! Spanish is my first languaje!!!! ;) Thanks
Manuel
Yes, you can get 115.2kbps from a PIC. You can get all the way up to 2.5Mbps (40mhz clock / 16), but you'll barely have any time left over to move data around and otherwise process it.Quote:
Originally Posted by manumenzella
Hi skimask! Thank you for your answer!!! I don't need the data to be receiver all the time. Just about 96 bytes twenty times every second. By the way, I think there is something i don't understand about the USART: is it like the serin/out, in which the pic has to do OLNY the serial transmission, and cannot do anything else, or is it like HPWM, a background process??? (I dont think i made that very clear.. my english is not that good.. :)Quote:
Originally Posted by skimask
Sorry to bother you again!!! And thanks!!!!!!!
Manuel
Quote:
Originally Posted by manumenzella
Serin/Serout is a 'bit-banged' routine, all bits are checked/timed using software, delays, loops, etc. Once you're in the middle of a Serin/Serout command, that's all you can do, nothing else.
HSerin/HSerout is a mix between software and hardware, done somewhat in the 'background' but not entirely. Hardware handles receiving/transmitting the character, PBP software handles 'getting' or 'sending' it. Again, once you're in the middle of a command, you have to wait until it's finished.
The UART is completely hardware driven. You can either set up a loop and wait for certain bits to change, then act on the sending/receiving registers accordingly. Or you can do use the UART in the 'background' using interrupts to tell you when you need to receive or send characters.
Your PBP manual has a decent explanation of how to use the Serin/Serout/HSerin/HSerout and the PIC datasheets do well explaining the UART. Use them...they are your friend...
Manuel,Quote:
Originally Posted by manumenzella
The harware USART operates in the background, as does the HWPM. However, you do have to "feed" it the data, and that will essentially happen one byte at a time.
You say you need to send 96 bytes at a time, twenty times a second? From your previous mention of 40MHz clock speed, I would deduce you are using an 18F PIC. I don't know how you are "gathering" your 96 bytes of data, but you could feed the USART from an array using interrupts to determine when the USART is able to receive the next byte. You may also be able to poll the TXIF bit frequently vs using interrupts.
Hopefully, this is not sounding too advanced. Start by reading the PBP manual on HSEROUT and the datasheet for you pic (the USART section). Also, MeLabs has some sample programs that can also help.
The basics are:
1) Setup the USART through the approapriate DEFINEs and registers. Here is an example of what I use for a 18F4620:2) Use either:Code:' 'Setup for 115200 baud
DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
DEFINE HSER_SPBRG 86 ' 86 = 115200 Baud @ -0.22%
SPBRGH = 0
BAUDCON.3 = 1 ' Enable 16 bit baudrate generator
a) HSEROUT to send out the data, realizing that it can do some processing of the data before it is sent to the hardware. Also, that sending multiple bytes of data will force the PIC to process all the bytes to be sent out before it moves on to the next statement
b) Send the bytes directly to TXREG. This would allow for the use of interrupts/flag polling to send the data "in the background"
Hope this helps you get started in the right direction.
Steve B
Guess I was a little slow on the draw :) That's what happens when toddlers need to go to sleep!
Hi SteveB! Thanks so much for your answer!!! It was just what I needed. I was able to understand it right away. The PBP Manual was some help too!!!!
By the way, I would like to know what is the benefit of using the USART module, with hserin or hserout commands, as they cannot be done in the backgroud. The benefit is clear, though, when using the module just like the datasheet says.
Perhaps you can achieve greater speeds using the USART??? Or less error percentage???
Well, thats all for know!!! Thanks again steve for your answer!!!!!
Manuel
Manuel,Quote:
Originally Posted by manumenzella
The advantage of the PBP HSEROUT command is that it has the flexability to
a) "format" the outgoing data as needed (such as sending the value 65 out as "65", "41", "A", or "01000001") and
b) send multiple bytes in sequence (such as HSEROUT [dec var_a, 10, "X", HEX2 var_b]) and
c) it uses the hardware USART, which speeds things along, since it change run at a higher baud rate and it can send out one byte in the background while the pic is processing the next byte in the foreground.
The disadvantange to the HSEROUT is that it will occuply the PIC if it has a large amout of data to send. Take, for example, the command:
HSEROUT ["This is a long string of data for the PIC to send out the USART!"]
This command, even though it uses the USART, would monopolize the PIC until the last byte was sent to the USART. So, it is very much running in the forground (preprocessing and queing the data), even though it uses the hardware USART in the background to actually send the data.
What about writing directly to the TXREG? If the data did not need any "pre-processing", and in combination with an interrupt driven queing scheme, this would likely be the fastest, most efficient method, leaving more time for foreground processing. The foreground task is only interrupted, when the USART is done sending the last byte, long enough to write the next byte to the TXREG. It then resumes the foreground processing until the USART is done sending out that byte. This is not the "easiest" way to do things, just another alternative.
Now, what you need to determine is how critical timing and processing time are going to be in your application. If your forground tasks are not that demanding, the HSEROUT, sending a burst of 96 bytes would be the easiest. Otherwise, you may need to set up an interrupt based scheme which will take maximum advantage of the USART.
As for percentage of error, since the HSEROUT uses the USART to send the data, the timing error is the same. How it compares to the timing error of PBPs bit-banged serial commands? I haven't got any data on that.
Steve B
Hi Steve. Thanks again for all your time.
I forgot to add int the first post that the PIC that is having to do some foregroud task is the one that is receiving the data. (sorry :( )
As for what I understood from the datasheet, and please correct me if I'm wrong, the USART can receive two full bytes berore you have to read them using the register. But that is only 140 us, not even enough for a single loop to be processed in the program im using. Is this correct???
By the way, what I am trying to do is a LED cube, with the LEDs multiplexed, so if the transmission takes long enough, there will be flickering in the leds.
Thanks a looooooot!!!
Manuel
...which is why you use the hardware UART and some interrupts and write your own buffer routine to pull out the data received when you can spare the time to do it. I'm multiplexing & PWM'ing 306 RGB LEDs (918 total) on a 921.6kbps serial line while at the same time receiving 9600 bps control data over an RF link...all using a bunch of 16F628A's and a master 18F2620. I don't see any flickering.Quote:
Originally Posted by manumenzella
Don't count on that 'receive 2 full bytes before you have to read them' thing, because it WILL bite you later on when you least expect it.
Hi. Thanks for the input. That must be a great project!!! What is it about???
Can I see a picture??? :)
About the USART, i think I will do what you told me. I didnt undersatand the part where you say that I shouldnt count on that "two full bytes" thingy
Do I have to read the data every byet??? Thanks again.
Manuel
The 2 bytes - I'm just saying that PBP might get busy doing something else and you think you might have enough time to grab that 2nd byte and BAM! in comes the 3rd one and now you've lost data.Quote:
Originally Posted by manumenzella
The LEDs - I've got pictures of them on my site, no movies yet, and the pic's are actually pic's of the old LEDs all running in sync with each other. I'll have a good movie up there eventually.
Another way to think about this is that the 2nd byte capability is short term overrun protection. This way, the first byte can be read while the second byte is being recieved. As skimask says, if a third byte shows up, and the recieve register has not be read (the 1st byte), on overrun will occur and data will be lost.Quote:
Originally Posted by skimask
Steve B
Hi Manuel,
Whenever a byte is received by the USART it is made available in the receive buffer while the other byte (2byte buffer) still gets stuffed. You must read the byte before your another byte is full. If not, your USART faces a buffer underrun condition and an error is raised.
The USART supports interrupts and it is fired as soon as a byte is ready. You might be in middle of something but still can grab the data in your own buffer and resume. Later you can check for newly available data and modify your display. If you are doing multiplexing then you might be needing interrupts anyway to get good timings and display stabilty.
It is better if you have some sort of hardware block diagram.
Hi,
I don't mean to be picky here but the 'buffer' is actually two bytes so a third byte can be 'on its way in' without buffer over run. As soon as the third byte is clocked in, though, you'll get a buffer over run error.Quote:
Whenever a byte is received by the USART it is made available in the receive buffer while the other byte (2byte buffer) still gets stuffed. You must read the byte before your another byte is full. If not, your USART faces a buffer underrun condition and an error is raised.
There's a document on the Microchip website called Usart.pdf (no document number or anything) that explains the operation in asynchronous mode. The following is an extract from it:
Hope it helps.Quote:
The use of a separate receive shift register and a FIFO buffer allows time for the software running on the PICmicro MCU to read out the received data before an overrun error occurs. It is possible to have received two bytes and be busy receiving a third byte before the data in the RCREG register is read.
/Henrik Olsson.
Hi. Thanks once again for all your help!!! With all the info you gave me, I was able to compile some program to transfer 8 bytes using USART, to another PIC and perform PWM to them (not multiplexing yet)
I have not been able to try the code out yet, because I do not have two 16F877A right now. Anyway here are the TX and RX codes. Im sure they have quite a lot of errors, but a start is a start, isnt it?? :)
(Please check also the regs at the beginning, I wasnt sure of some bits...
This is the TX code:
DEVICE 16F877A
ALL_DIGITAL = TRUE
XTAL = 20
DIM PWMDATA[8] AS BYTE 'VARIABLES FOR DATA TRANSMISSION
'LOAD PWMDATA FROM SOMEWHERE ELSE...
DIM INDEX AS BYTE 'INDEX FOR DATA RECEPTION FOR PWMDATA
DIM X AS BYTE
TXSTA = %00100110 'ASYNCHRONUS, HIGH SPEED, TRANSMISSION ENABLED.
RCSTA = %10010000 'USART ON, 8-BIT, NO ADRESS DETECTION, CONTINOUS RECEIVE
SPBRG = %00001010 'SET BAUDSPEED TO 113200 (HOW DO YOU CALCULATE THE ERROR?)
MAIN:
FOR INDEX = 0 TO 7
TXREG = PWMDATA[INDEX]
WHILE TXIF = 0 : WEND
NEXT INDEX
GOTO MAIN
/////////////////////////////////////////////////////////////////////////////
And this is the RC code:
DEVICE 16F877A
ALL_DIGITAL = TRUE
XTAL = 20
TRISD = $00
DIM PWMDATA[8] AS BYTE
DIM INDEX AS BYTE
DIM X AS BYTE
FOR X = 0 TO 7 'INITIATE PWMDATA
PWMDATA[X] 0 = 255
NEXT X
INDEX = 0
TXSTA = %00100110 'ASYNCHRONUS, HIGH SPEED, TRANSMISSION ENABLED.
RCSTA = %10010000 'USART ON, 8-BIT, NO ADRESS DETECTION, CONTINOUS RECEIVE
SPBRG = %00001010 'SET BAUDSPEED TO 113200 (HOW DO YOU CALCULATE THE ERROR?)
MAIN:
PORTD = $FF
FOR X = 0 TO 255
IF X = PWMDATA[0] THEN CLEAR PORTD.0
IF X = PWMDATA[1] THEN CLEAR PORTD.1
IF X = PWMDATA[2] THEN CLEAR PORTD.2
IF X = PWMDATA[3] THEN CLEAR PORTD.3
IF X = PWMDATA[4] THEN CLEAR PORTD.4
IF X = PWMDATA[5] THEN CLEAR PORTD.5
IF X = PWMDATA[6] THEN CLEAR PORTD.6
IF X = PWMDATA[7] THEN CLEAR PORTD.7
IF RCIF = 1 THEN GOSUB RECEIVE
NEXT X
GOTO MAIN
RECEIVE:
IF INDEX = 8 THEN INDEX = 0
PWMDATA[INDEX] = RCREG
INDEX = INDEX + 1
RETURN
Thanks for all your help!!!
Manuel
That's some of the strangest PBP I've seen in awhile...must be that new version... :)Quote:
Originally Posted by manumenzella
Hi. Yes I know. I don't know why my compiles uses those commands. A relative of mine taught me basic and he tought to me like that. :( Is it at least readable by you guys??? I hope so!!!
Manuel
Hey by the way, in the RC code, there is an extra 0 that should be there.
Instead of :
FOR X = 0 TO 7 'INITIATE PWMDATA
PWMDATA[X] 0 = 255
NEXT X
INDEX = 0
It should be:
FOR X = 0 TO 7 'INITIATE PWMDATA
PWMDATA[X] = 255
NEXT X
INDEX = 0
Thanks
Manuel
Maybe because it's not PBP?Quote:
Originally Posted by manumenzella
Ohhh Youre right! This was my uncle computer and he left the compiler installed!!! It says PBP compiler, but in About... it says proton!!!!!!!!!!!!!!!!!
Its quite similar though. The language, i mean.
Manuel
Hi,
Thanks Henrik for correcting me.
BTW manuel could you please describe your project in a little bit more detail.
Hi. Yes of course. Im sorry i didnt before.
What I want to do is a 4x4x4 RGB LED cube that is commanded, via serial, from a computer. Each color of each RGB LED will be PWMed (4 bits) so I would need to receive 96 bytes (4 bits per LED).
Right now, instead of using a computer to send the data, I would like to try to do it with another PIC, so as to simplify it for now.
Thanks again!!!
Manuel