Skip to main content ↑ ↓
Topic: Higher serial speeds? (Read 6023 times) previous topic - next topic

Higher serial speeds?

Hi,

i was just wondering if it was possible to implement higher serial speeds in the pic to talk to the ftdi chip.

It looks to me that hyper term supports 200, 400 and 900K speeds. (see pic for actual speeds)

and the older version of the ds30 bootloader has 128k ans 256k speeds as well.

so it looks like the only thing stopping it would be the bus pirate firmware. now from memory the bus pirate supports speeds upto 2mb on the uart

anyway. just a thought i had which was jolted after reading about the write/read times for the spi roms in another thread

Re: Higher serial speeds?

Reply #1 –
The question is, given the tolerance of the internal oscillator that the Bus Pirate uses, will most Bus Pirates be able to communicate at the higher speed? I've been wanting to add them for a long time, but I haven't done the math to find out what the tolerances are. That's the main thing that's kept me from upping the speed. 256Kbps, probably, but I'm not sure they can all do 1Mbps. I don't want people to be upset if they have BPs that are at the low end of the tolerance and can't do the high speed modes.

Robots used 1Mbaud in the OpenOCD mode though.

The bootloader and firmware operate independently, so it's not an issue to have a different speed for the firmware and the bootloader. The FTDI drivers adjust to whatever the originating application requests of the serial port.
Got a question? Please ask in the forum for the fastest answers.

Re: Higher serial speeds?

Reply #2 –
maybe a "beta" firmware could be created for testing the speeds and see what percentage work.

Re: Higher serial speeds?

Reply #3 –
I remember from the bootloader the setting was 0x22 or 0x23 (depends on which version silicon you got) so when this is set to 0x01 the speed would be around 7372800 baud. I Dunno how about the accurasy.

It is easy to test in base.h around line 131 the baud settings are stored, change them to something higher. divide 34 by 2 and the baud is multiplied by 2 etc etc. I think 230400 is the max (0x17 can't be divided by 2 anymore)

edit: as ian says.

We could leave the bl with max 115200 (preferaable) and make it selectable in the firmware (perhaps ask the user for the exact hex value?)

Re: Higher serial speeds?

Reply #4 –
Maybe the higher speeds could use a baud rate auto adjust. This would require that after switching to this speed the user would send a repetition of known characters that have only two level changes.  The pic could time this and calculate a prescaler value that fits this speed. If it receives at least n times the correct character after the prescaler adjustment it sends a prompt back so that the user knows the higher speed is now in effect.

Klaus Leiss

Re: Higher serial speeds?

Reply #5 –
Unfortunately, the auto baud is defective at high speeds (BRGH=1) on several PIC revisions (thus the recent bootloader update) :) It's a logic puzzle to be sure.
Got a question? Please ask in the forum for the fastest answers.

Re: Higher serial speeds?

Reply #6 –
just trying to work out what speeds are theritically capable. but looking at base.c either the formular im using is wrong of the numbers mentioned are wrong.

Code: [Select]
//Initialize the terminal UART for the speed currently set in bpConfig.termSpeed 
 static unsigned int UARTspeed[]={13332,3332,1666,832,416,207,103,68,34,};//BRG:300,1200,2400,4800,9600,19200,38400,57600,115200 
 void InitializeUART1(void){ 
     U1BRG = UARTspeed[bpConfig.termSpeed];//13332=300, 1666=2400, 416=9600, 34@32mhz=115200.... 
     U1MODE = 0; 
     U1MODEbits.BRGH = 1; 
     U1STA = 0; 
     U1MODEbits.UARTEN = 1; 
     U1STAbits.UTXEN = 1; 
     IFS0bits.U1RXIF = 0; 
 } 
 

according to the datasheet it should be  brg = ((frquency/baud)/4)-1

by my calcs i get a brg value of 68 for 115200, where you seem to have 34.

am i doing something wrong?

Re: Higher serial speeds?

Reply #7 –
I usually use this guy: http://www.micromagicsystems.com/#/pic-baud/4523812801

But I think maybe you're using Fcyc (16000000) instead of Fosc (32000000) for the frequency constant.
Got a question? Please ask in the forum for the fastest answers.

Re: Higher serial speeds?

Reply #8 –
The other way around :) Fosc instead of Fcyc

Fcyc=Fosc/2, so the equotation (page 160) becomes:

Ubrg=((Fosc/2)/(4*baud))-1

(it puzzled me also a bit ;))

Re: Higher serial speeds?

Reply #9 –
ok i was using 32Mhz , but it seems i should be using 16Mhz .

yep i wasnt dividing by 2. so i was using 32000000. im guessing thats something to do with the 2 clock per instructions.

Re: Higher serial speeds?

Reply #10 –
well the most interesting value i have found so far is a brg of 3, should = 1M with a 0%error not allowing for the osc error.

i can understand why they are using it in the OpenOCD port. i wonder if terra term or other comms programs can use 1Mbuad.
Interestingly when i entered the top speed of hyperterm i got the same brg, but with a 8% error.

I think it would be worth implementing this speed for at least custom scripting apps and see how it goes.

i might have a play and see what speeds work. I guess the question would be how do i reset the serial speed if its not responding?

Re: Higher serial speeds?

Reply #11 –
Reset the buspirate? :D

You could alter the source to accept a value which get written to ubrg

Re: Higher serial speeds?

Reply #12 –
You want higher speeds? You got it ;) 

In bootloader firmware
Change the following lines (they already exists)
.equ    UARTBR,    0
;.error "Baudrate error is more than 3%. Remove this check or try another baudrate and/or clockspeed."
;bset   UMODE, #BRGH      ;enable BRGH

In GUI
Baud rate: 1000000

With the above settings, the entire flash is written in 6,9s on my pirate/computer.