Well, the data flow is going from the PIC to the PC. The PIC (16F877) talks to two 16F876 other PICs with I2C. This way I have 24 AD Channels, 4 Capture inputs, 8 PWM outputs and other data collection. All this data is packed (30 bytes/packet) and sended to the PC, 100 times a second. The PC sends data to the PIC also, but this is much less tighted flow, and I have no problems here. I am now trying to get all this data through an RF link, and here is where the problems arise. 30 bytes/packet, 100 packets/second, and 57600 baud gives 52% RF "upload" usage. This way it is not possible to do Manchester encoding of the data (this would give 104%), so I code each 6 bits in one byte, and get around 69.4% RF usage time, with 0 DC bias. This way the RF link works properly, but there is a 3us uncertainty at the end of each byte lenght, due to errors in the bit slicer of the RF receiver. This error added to the 2,13% from the 8 bits SPBRG is a makes of 21% error. This error is admisible, but I am working in the lab, and I hope this error to increase with external noise in the final application. This is the reason to try to get the 2,13% (actually 2,13*10bits=21.3%) error down. The VB code works fine decoding the data from the PIC. The input buffer of the PC UART does a nice job holding the data while Windows is doing it's things... Thanks for your help, and sorry for the long mail, Alvaro Deibe Diaz. P.S.: All this CCP, PWM, AD, I2C and USART job in the PIC is done in 6 interrupt routines. This makes it difficult to do a bit-banged UART. ----- Original Message ----- From: "M. Adam Davis" To: Sent: Saturday, March 09, 2002 1:28 AM Subject: Re: [PIC]; UART baud rate and Visual Basic > Well, for one you'd have to change a crystal (or clock source) going to > the UART on the computer to get it to do any easy division of 16MHz. > Most modern PCs have the uart on an asic, and you won't likely be able > to modify it. > > Furthermore, VB and windows are not real time systems, so even if you > could send a byte or packet exacty every 10mS, your VB program won't > receive them even 10ms. More likely it'll get a bunch of them every > 50-200mS. > > You don't need to get the pic to generate better than the 2.13% error > you've calculated. I've calculated that you could go up to a 5% error > and still have no problems getting correct data on nearly every PC. > 2.13% will be accepted by the PC and your VB program just fine. The > reason you can have such a high error is that the communication is > asynchronous, and the timing is reset every time you send a byte. A > full byte is 10 bits, with a start bit, 8 data bits, and a stop bit. If > you have a 2.5% error, the last bit will be off by 25%. That means that > it will be valid 75% of the time, and the PC generally checks the data > right at the halfway mark. Some machines check each bit in three > places, and take the two that match, which would also give the correct > data for an error rate of 2.5%. > > What are you trying to accomplish that needs to be synchronized so tightly? > > -Adam > > Alvaro Deibe Diaz wrote: > > >I know it, but I need my 16MHz crystal to generate "exact" 10ms sample > >periods in my project. If I use a crystal that generate standard RS2 > >baud rates, I can't get exact 10ms... > > > >This is the reason for trying to "force" the PC to talk in other baud > >rates. I thought perhaps the 16XXX of the PC UARTs have clock generation > >with more than the 8 bits of SPBRG in the PIC. This way I could get less > >than 2,13% error between both baud rates. > > > >Thanks, anyway, > > > >Alvaro Deibe Diaz. > > > >----- Original Message ----- > >From: "Bob Barr" > >To: > >Sent: Friday, March 08, 2002 7:45 PM > >Subject: Re: [PIC]; UART baud rate and Visual Basic > > > > > >>On Thu, 7 Mar 2002 21:55:40 +0100, Alvaro Deibe Diaz wrote: > >> > >>>Hi, > >>> > >>>Do you know of some kind of OCX for Visual Basic that > >>>allows it to "talk" in baud rates that can be obtained > >>> > >>>from standard (4MHz, 8MHz, 10MHz, 16MHz, 20MHz) xtals > >> > >>>without errors? > >>> > >>You may be better off using a crystal that can generate exact baud > >>rates rather than trying to tweak the PC end of things. IIRC, the > >>UARTs in the PC use a fixed clock frequency to derive their baud > >>rates. > >> > >>The crystals that you have listed can be called 'standard' only in the > >>sense that they are exact numbers of MHz. There are many other > >>standard crystal frequencies available. > >> > >>Digikey, for example, has Citizen crystals with frequencies of > >>3.6864MHz, 7.3728 MHz, 9.216MHz, 14.7456 MHz, and 18.432 MHz. > >> > >>Unless you really need the additional speed of the slightly higher > >>frequncies that you've listed, each of these crystals will generate > >>standard baud rates in the PIC's USART. Just pick the appropriate one > >>so as to not exceed the speed rating of your PIC. > >> > >> > >>Regards, Bob > >> > >>-- > >>http://www.piclist.com hint: PICList Posts must start with ONE topic: > >>[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads > >> > >> > >> > > > >-- > >http://www.piclist.com hint: PICList Posts must start with ONE topic: > >[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads > > > > > > > > > > > > -- > http://www.piclist.com hint: PICList Posts must start with ONE topic: > [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads > > > -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body