Software com speed

[sturgessb]

Hi Guys

Hope you all had a great christmas.

Im a bit annoyed with myself. I've spent all day building a board with the zx328n as a cpu and stupidly didn't realise that it only has 1 hardware serial port.

I have a gps to hook up to it that has a default baud of 38400, and obviously because software com ports only go up to 19200 i cant communicate with the gps to change it baud. Pretty annoying as I really dont want to scrap everything and build a new board around 24n.

Is there any way i can get the software ports to run at 38400, even if just for a short period so i can change the baud rate of the module?

Any ideas?

Cheers

Ben

[dkinzer]

Is there any way i can get the software ports to run at 38400, even if just for a short period so i can change the baud rate of the module?

No, that speed is just too fast for the 4-channel bit-bang serial implementation. The Direct Bit-Banged Serial I/O routines that I posted may work. They were tested as fast as 115.2K baud.

On the other hand, the easiest solution may be to connect the GPS to a PC serial port using a level translator and send it commands using a terminal emulator.

[mikep]

Why not use COM1 port on the zx328n or for that matter using one of the serial ports on any of the other devices you have. You only need a short program to change the baudrate which you can load in temporarily. As Don say you could also use the PC. Just make sure you have a level converter as necessary to invert the signals whatever you use to connect to the GPS.

[sturgessb]

thanks Don, i feared as much.

The problem with the pc route is that when power is removed the unit resets to default baud of 38400

Sorry, when I said temporarily, i meant at power on of the micro.

Will have a look at the direct code

Ben

[sturgessb]

Yeah thanks for the heads up Don, but i dont think reading the gps sentance via the bit banged route is going to work.

Bugger. Only solution I see is hooking it up to com1 and then using a software com port for debuging instead. I presuming I cant use a software com port for downloading? So i will have to make sure i can switch the gps data off, so as not to mess up downloads.

Ben

[sturgessb]

Hmm maybe i'm being dumb here...

I could just hook up com1 to the rx of the gps, and the output of the gps to software com.

Then I could use com1 to change baud at boot, as i shouldnt need to communicate with the gps again after that, just receive from it.

Ben

[dkinzer]

I presuming I cant use a software com port for downloading?

That is correct. Downloading is done via a specific hardware USART that is hard coded in the bootloader of the device. The AVR Flash memory is partitioned into two spaces: the bootloader (usually 2K) and the application space. When the bootloader is running, e.g. downloading code into the application space, the application space can't be used because it will be overwritten by the newly downloaded code. The bootloader is a fairly simple program due to the necessity to keep it small. There isn't enough leftover space for the software UART drivers to be included.

I could just hook up com1 to the rx of the gps, and the output of the gps to software com.

Assuming that the GPS doesn't get confused by the other data it will see during downloading, that may work.

[Don_Kirby]

I could just hook up com1 to the rx of the gps, and the output of the gps to software com.

Yes, there's no reason that the TX and RX lines need to be on the same port. I recently did something similar. Don't forget to add pull-up or pull-down resistors to the lines to avoid floating them in the absence of an actual connection. I spent way too much time hunting down a non-existing bug due to this little detail.

You may find it necessary to add circuitry to switch the GPS in and out of the Com1 line so that it doesn't interfere with software downloads. This could be as simple as a single transistor and a logic pin.

-Don Kirby

[mikep]

You may find it necessary to add circuitry to switch the GPS in and out of the Com1 line so that it doesn't interfere with software downloads. This could be as simple as a single transistor and a logic pin.

This was exactly the rationale I had when I created the first ZBasic devices that contained a manual DPDT switch which allowed both TTL and RS232 output levels. In one position you could do RS232 serialdownloads (via pins 1-4) and in the other you could connect to a TTL serial device (via pins 19/20). I'm not sure everyone understood the versatility of such a design.

The newer Oak Micros devices now have USB for host connect and only TTL serial output - which would also solve the OP problem as well.