Speeding up Serial Communication?

[cornwaab]

Hello,

I want to know if there is a way to increase the speed of PureBasic serial port (RS-232) communications. Although my application is pretty specific there may well be other uses involving computer to microprocessor serial communications where speed is important.

My project is to construct what I call the 'software defined antenna analyzer' for amateur radio. I am still assembling and testing the components which will include:

- microcomputer running a PureBasic program for sweeping frequencies and reporting in various ways on voltage measurements taken at an antenna; in this case the microcomputer is a netbook

- direct digital synthesizer oscillator and low-power RF amplifier (a DDS-60 module using an AD9851 DDS chip) to transmit to an antenna

- SWR bridge (resistors, capacitors and diodes) to provide forward and reflected antenna voltages at given frequencies

- PICAXE 14M2 microprocessor to:
. receive frequency control data from a microcomputer and set up the DDS chip to produce the frequency
. measure voltages (there are three of them) for the frequency at the SWR bridge and send the measurements back to the microcomputer.

I am at the stage of this project where the microprocessor is receiving frequency control data from the microcomputer. The microprocessor is telling the DDS to produce the correct frequency, and is reporting back voltages to the microcomputer (just dummy test voltages for now, the SWR bridge has yet to be added). No more than 32 characters are exchanged each way. Communication between the microprocessor and the microcomputer is by serial port via a RS232 to USB adaptor plugged into one of the the microcomputer's USB ports. To test this arrangement I've kludged together a console program to sweep 30 frequencies (1 mHz to 30 mHz) and display the corresponding voltages in the console window.

My problem now is that the turn-around time for communication between the microcomputer and microprocessor is slow. I am hoping to achieve a sweep rate of at least 100 frequencies per second (in theory the DDS can handle the rapid frequency updates), but the time between the microcomputer sending frequency control data to the microprocessor and receiving the voltage measurements back is too long. In order to make the program work reliably (i.e. receive voltages, if at all, corresponding to the frequency) I have to put in a delay of about 90 milliseconds between sending frequency control data request and receiving voltage measurements; this implies a sweep rate of about 10 frequencies per second. The program delay statement can be seen in the accompanying snippet the PureBasic test code, showing serial communication and timer elements.

According to the "ElapsedMilliseconds()" timer it appears that the microprocessor uses only a few milliseconds of the total time between the microcomputer sending the frequency control data and receiving the voltage values in return. The rest of the time for the transaction is consumed by the delay statement. (I doubt the exact accuracy of the "ElapsedMilliseconds()" timer, however, because sometimes the timer duration is less than that of the delay statement.)

I've tried a number of things to speed up communication turnaround time, consistent with reliable measurement reporting. These include:

- cranking up the microprocessor speed to 32 MHz and serial port speed to 38,400 baud; this helped. Speeding up the microprocessor and serial port usually required shorter delay times. (At 8 mHz and 9600 baud the delay is approx. 300 ms, at 38,400 baud it is 90 ms.)

- playing with values of *Buffer and the Open statement buffers; this made no difference

- using shorter delay times in the PureBasic program; there is a fairly critical point where making the delay time shorter screws around with properly receiving voltage measurements

- change the program to poll AvailableSerialPortInput() until some characters are received then transferring them to the *buffer ( ReadSerialPortData(0,*Buffer,port_data) ), but for some reason this did not work very well (I may not have known what I was doing)

If you have experience with PureBasic serial port functioning can you advise me on how to speed it up? Or can it be speeded up?

I will be writing a windows-based PureBasic user control and reporting program. Does serial port communications work faster or slower when not in console mode?

I appreciate any help.

--- Andy

Code: Select all

 Program Snippet Below:

;Using Purebasic 4.61 (x86) on a netbook computer, communicating with a PICAXE 14m2 over RS232 port via a
;serial to USB adapter.
; Dots ('.') mean code segments have been removed to highlight serial com. and timer elements.

OpenConsole()
.
.
*Buffer=AllocateMemory(512)
.
.
.
;Open the RS232 Serial Port
If OpenSerialPort(0,"com"+comport$,38400,#PB_SerialPort_NoParity,8,1,#PB_SerialPort_NoHandshake,256,256)
  Debug "Com"+comport$ + " is open"
Else
  Debug "Com"+comport$ + " Failed"
  End
EndIf
. 
.
.
;Send frequency to PICAXE
for n=1 to 30
.
.
StartTime = ElapsedMilliseconds()

WriteSerialPortString(0, output_string$ ,PB_Ascii)

Delay (90)

volts$="" 
port_data=AvailableSerialPortInput(0)
ReadSerialPortData(0,*Buffer,port_data)
text_in$=PeekS(*Buffer,port_data)
volts$=text_in$

ElapsedTime = ElapsedMilliseconds()-StartTime 

PrintN (Str(n)+" volts "+volts$ +"Timer ms "+Str(ElapsedTime))

Next n

[infratec]

Hi,

a first optimization:

Code: Select all

SerialPortTimeouts(0, 0, 0, 0, 0, 0)

For n=1 To 30


  StartTime = ElapsedMilliseconds()

  WriteSerialPortString(0, output_string$ ,PB_Ascii)
  
  Timeout = 1000
  Repeat
    Delay(1)
    Timeout - 1
    port_data=AvailableSerialPortInput(0)
  Until Timeout = 0 Or port_data <> 0
  
  If port_data
    ReadSerialPortData(0, *Buffer, port_data)
    text_in$ = PeekS(*Buffer,port_data)
    volts$=text_in$
  
    ElapsedTime = ElapsedMilliseconds()-StartTime
  
    PrintN (Str(n)+" volts "+volts$ +"Timer ms "+Str(ElapsedTime))
  EndIf
  
Next n

But that's not the optimum.

Why not a higher baudrate?
Why you send ASCII text and not binary data? (reduce size and time to transmit by 2)

Also in this snippet, you don't know if the volt$ is complete.

if the length of the received data is fixed, you can

Code: Select all

Until Timeout = 0 Or port_data = #FixedLength
If port_data = #FixedLength

Also it depends on your USB converter.
This stuff is always a bad idea, because you don't know when the send data is send
and when it transmits the received data to the PC.
A real com port is always faster.

Bernd

[dhouston]

A real com port is always faster.

I did some testing a few years back (@115200) comparing straight RS232 with USB-RS232 when downloading firmware to an Atmel AVR microcontroller and the former was more than twice as fast. This may seem odd given the high speed of the USB bus but there are two translations needed - one on each end of the link. With today's faster USB ports the advantage may be less but I would guess that straight RS232 will still be faster.

BTW, I'd be very interested in using your setup to test an antenna I use for home automation applications.

[cornwaab]

Thank you dhouston and infratec for responding to my query.

- I am have to use a RS232 to USB adaptor. A lot of antenna analyses is done in the field, which means using a laptop (or netbook in my case) computer. These days laptops do not have built-in serial ports. I was heartened, dhouston, that you were able to use a RS232 to USB adaptor to download to an Atmel microprocessor with only a 50% speed penalty compared to a real serial port. A 50% reduction is not a game-ender, and maybe the adaptor is not an insurmountable obstacle for my project.

- I was under the impression that a baud rate of 38.4 Kbs, based on a 32 Mhz clock speed for the PICAXE 14M2, is the limit for this microprocessor. The PICAXE manual, however, states that this class of chip can be clocked to 64MmHz with a baud rate of 78.8 Kbps. I will try cranking up the speed. But there is a penalty for being in the fast lane, with the chip drawing more power; by how much I do not yet know.

- Doing communications in binary, that is bianry-ascii characters, is a good idea. My current use of decimal digits stems from testing the microprocessor's program with terminal programs, such as the PICAXE Editor terminal and Hypertext, that do not show nor accept binary-ascii characters in meaningful human readable form. This morning I experimented with binary-ascii characters for the PureBasic - microprocessor exchange of values, and was able to reduce the character transfer of data, total both ways, from about 32 characters with decimals to about 10 binary-ascii characters. At 38.4 Kbs this means a reduction in communications time by about 6 ms. Unfortunately, using binary did not allow decreasing the delay statement significantly below 90 ms.

- Infratec, thank you for the alternative PureBasic serial port communications code. I will try it just after I increase the microprocessor speed and baud rate.

Any more suggestions and ideas? Anyone?

--- Andy

[cornwaab]

This morning I took a different tack and looked at the PICAXE 14M2 microprocessor for the cause of delays between my PureBasic program sending it frequency control data and subsequent voltage readings being received back by the PureBasic program. For a test I programmed the microprocessor to do essentially nothing - read the control data and echo them back out. The delay required by the PureBasic program needed to reliably handle this transaction dropped to 20 ms. This compares to 80 ms when the microprocessor is asked to set-up the DDS and read voltages. Interestingly, when I added the chore of reading voltages to the microprocessor test program the delay did not change appreciably from 20 ms, thus the microprocessor's manipulations to parse the frequency control data and send it to the DDS is taking up most of the time.

I do not know if PureBasic's serial communication speed presents a bottleneck to the fast frequency scanning I want to do with my software designed antenna analyzer project. I have yet to try out infratec's coding suggestions to improve PureBasic's communications speed. At this stage, however, I have to put more effort in making the microprocessor work more efficiently. It appears that the 14M2 does not run with a clock rate faster than 32 MHz despite my understanding of the PICAXE manual. So simply putting more horsepower under the hood does not seem to be a solution.

For a time yesterday I examined the possibility that the RS232 to USB adapter might be a serious bottleneck. The specifications for my two adapters state data transfer rates of up to 0.5 or 1 mega bits per second. I played around with the adapters' driver settings without making much difference. I even tried using an adapter with a theoretically faster computer than my netbook, but it was slower (i.e. the PureBasic program required a longer delay) than the netbook. The adapter may still cause some serial communications slowdown, but it is not now the most likely suspect.

Thank you for your help. If anyone is interested I will report back here on my progress.

--- Andy

[dhouston]

It appears that the 14M2 does not run with a clock rate faster than 32 MHz despite my understanding of the PICAXE manual. So simply putting more horsepower under the hood does not seem to be a solution.

I took a few days to study the PICAXE system a few weeks ago and decided that the PICs they use have been dumbed down to the point where they have only 10% or so of the power inherent in the same PIC w/o the PICAXE system. It's as if they have had a prefrontal lobotomy. Even worse, their support people appear to peddle deliberate disinformation to keep the members of the cult from grasping that the PICs could do much more.

Have you considered using the same PIC with Mikrobasic for PIC (free for programs <2KB) or Great Cow Basic (free but it may not support the latest PICs)?

You might also look at ZBasic's ZX-328n. The chip costs $10 but the compiler is free. You would need to use the hardware USART but it can do 115200. There are a couple of people who frequent their forums that might find your project of interest and might suggest methods/techniques. However, it is a 28-pin chip which may be a factor.

[cornwaab]

I took a few days to study the PICAXE system a few weeks ago and decided that the PICs they use have been dumbed down to the point where they have only 10% or so of the power inherent in the same PIC w/o the PICAXE system. It's as if they have had a prefrontal lobotomy. Even worse, their support people appear to peddle deliberate disinformation to keep the members of the cult from grasping that the PICs could do much more.

Have you considered using the same PIC with Mikrobasic for PIC (free for programs <2KB) or Great Cow Basic (free but it may not support the latest PICs)?

Thank you, dhouston, for suggesting alternatives to the PICAXE line of microprocessors. My experience with microprocessors in general is almost non-existent. I used a PICAXE for one previous project, where speed was not an issue. Learning PICAXE programming is easy and I was drawn to that aspect. I will continue to see if I can make my 14M2 chip do the job, but based on my recent experience and the results of your research it may not be wholly satisfactory. In the meantime I can use the 14M2 to get both the yet to be constructed SWR bridge and the yet to be written PureBasic set-up and antenna analyses program working.

I briefly looked at the MicroBasic and Great Cow Basic websites. They are impressive in distinct was, and operate with the PIC family of chips. The PICAXE 14M2 is based on the PIC16F1824 chip. Assuming I can learn to program one or other of these languages, I might be able to simply remove the 14M2 and plug in the PIC with only minimal wiring changes to the board (it is hand-wired). My current microprocessor program does very little and takes up only about 300 PICAXE bytes (but the libraries are already burned on the chip), so a comparable program may be under the 2K bytes limit for using the free version of MicroBasic. A potential advantage of MicroBasic is it has a USB library that might function with that of PureBasic.

Have you had any experience with either MicroBasic or Great Cow Basic?

--- Andy

[cornwaab]

OOPS! In my previous post I referred to mikroBasic as MicroBasic. 'mikroBasic' is correct.

--- Andy

[aaron]

USB is only fast when you are transmitting large chunks of data. When you send smaller packets, the overhead starts to become a larger factor. USB is a framed protocol, meaning that it buffers up some data and sends that out on a schedule (1kHz packet rate for standard USB speeds, maybe faster for USB3?). That doesn't help either, particularly when you are sending small chunks of serial data.

I've ran the FTDI serial to USB adapters with Purebasic at 2Mbits per second, streaming large chunks of data. It worked quite nicely. But once you start ping-ponging small 32 byte packets of data, you are going to start seeing some delays. Regular RS232 gives better performance in that case, but sadly has disappeared from most machines.