Faster serial comms

[FFMan]

Back to the laptimer with the GPS decode.

I'm using a ZX24a for testing the GPS part, with a view to moving it to a 328n when all the modules come together.

However, both these device have only 1 hardware serial port and that is com1. I presume this is the port used for downloading and debug.print so I don't really want to use this for the GPS comms.

In testing it seems that 19200 may not be quick enough, so i need to consider using a device with another h/w serial port. Given I don't have SMT skills what are my options ideally keeping the costs down ?

I presume also if i use a h/w serial port there will be less load on the cpu ? Is this a significant amount ?

thanks

[dkinzer]

Given I don't have SMT skills what are my options [...]?

The ZX-24p and ZX-24n both have two hardware USARTs as do their DIP-40 counterparts (ZX-40p and ZX-40n).

I presume also if i use a h/w serial port there will be less load on the cpu ? Is this a significant amount ?

When one or more of the software UART channels is open, the SW UART timer generates an interrupt at a rate of 4 times the maximum baud rate. At 19.2K baud, that will result in an interrupt every 13uS. Even if no characters are currently being sent or received, there is still significant time consumed in the SW UART interrupt service routine. The test program below (written for a 24-pin ZX device) demonstrates the effect. If you run the test program with the OpenCom() call commented out, it reports a result of about 2388. Run it again with OpenCom() not commented out and it reports a result of 779 suggesting that about 67% of the processing power is consumed in the SW UART ISR. In contrast, if you run it again with a baud rate of 4800 the result is 1985 suggesting that about 17% of the processing power is being consumed in the ISR.

Code: Select all

Dim iq(1 to 40) as Byte
Dim oq(1 to 40) as Byte

Sub Main ()
  Dim uval as UnsignedLong
  uval = 0

  ' prepare the software UART channel
  Call OpenQueue(iq)
  Call OpenQueue(oq)
  Call DefineCom(3, 13, 14, &H08)
'  Call OpenCom(3, 19200, iq, oq)

  ' prepare Timer1 to time execution of the loop below
  Register.TCCR1A = 0
  Register.TCCR1B = 5  ' divide-by-1024 prescaler

  ' execute the loop for a defined period of time
  Do While &#40;Register.TCNT1 < 1000&#41;
    uval = uval + 1
  Loop

  ' display the result
  Debug.Print "accumulator = "; uval
End Sub

[dkinzer]

I forgot to mention in my last post that you need a pullup resistor on the pin used for the SW UART receive side. I used an external pullup in my test but you could just as easily enable the internal pullup.

Code: Select all

  ' prepare the software UART channel
  Call OpenQueue(iq)
  Call OpenQueue(oq)
  Call DefineCom(3, 13, 14, &H08)
  Call PutPin(13, zxInputPullup)

[FFMan]

thanks don - comprehensive as ever and as i suspected, the sw uart is hungry and not the way forward in this project.

i'll look into the options for other devices.

[spamiam]

You might find the Oak Micros variants have something you need.
-Tony

[mikep]

The ZX-24p and ZX-24n both have two hardware USARTs as do their DIP-40 counterparts (ZX-40p and ZX-40n).

If you need more I/O pins than the ZX-24p/ZX-24n then you can also consider the Oak Micros ZX-24pu or ZX-24nu which have all of the necessary components including a USB serial port integrated into a circuit board no larger than a 40-pin DIP chip.

However, both these device have only 1 hardware serial port and that is com1. I presume this is the port used for downloading and debug.print so I don't really want to use this for the GPS comms.

There are some other options here. You could use COM1 for the GPS and then COM3 at 4800/9600 baud for debug output. Debug.Print is hardcoded to use COM1 but you just as easily write you own debug output routine that directs output to COM3. You would need an extra (temporary?) TTL to RS232 converter for that COM3. For prototyping purposes you could use a DPDT switch (or even jumpers) so that COM1 can be connected to the host PC for downloading new code. Presumably by the time you get to the ZX-328n (or Oak Micros ZX-328nu) most of the code has been debugged and the only problems left are porting errors, if any. I have not found any issues with porting code from one ZBasic platform to another providing you take note of the different I/O pin numbering and that larger task stack sizes needed for native mode.

[FFMan]

thanks mike. i had though about using com1 as you suggest - its an option and means i could use the 328n which is just $10

Ideally though i need the speed of native mode. a h/w uart other than com1 and a few more io pins than a 328n. i am using quite a few pins to drive the lcd in native 8 bit hitachi mode for speed.

thanks

[mikep]

The ZX-328nu (and ZX-32n) actually have two more I/O pins than the ZX-328n but these pins can only be used for ADC. That might be all you need.

If you are so tight on I/O pins then there are several alternatives:
1. Use a device with more I/O pins and a second UART such as the ZX-24nu or ZX-40n.
2. Use 4-bit mode for the LCD display. You will see a significant difference in performance between the ZX-40a ZVM and native mode devices such that 4 bit mode should be more than sufficient.

BTW $10 only buys you the chip. You still need the support circuitry and TTL to RS232 converter. If you add to that a RS232 to USB converter then you reach the same cost as a ZX-328nu. The advantage of course is integration of the ZX-328nu functionality into a single breadboardable module.

[FFMan]

i'll take a look into the options.

Is there anywhere, a table/spreadsheet that lists all the specs of all the various zbasic compatible devices from both suppliers ?

[GTBecker]

Not using COM1 for application I/O is a waste of the resource or, conversely, only using COM1 for programming and debugging is a waste of the resource.

I've found that COM1 works fine for GPS NMEA input - and output to COM1 is normally ignored by a GPS unless it is in NMEA sentence form that the device recognizes. Other stuff, like typical debugging messages, can be intermixed without harm, I'll bet you'll find, as long as there is nothing that looks like a command to the GPS. Worst case, if you need to: make your debug messages look like an NMEA sentence that you know the GPS will ignore, like $XXXXX,Your text here<CRLF>.

[mikep]

Of course. See here: http://www.zbasic.net/ZX%20Device%20Parameters.htm . It is referenced from the bottom of the main page and there is also a spreadsheet format if you prefer that. The ZX family diagram might also be useful.

Note that Oak Micros is an OEM. The software/firmware provided for our devices is licensed from Elba Corp and all devices are based on the same codebase. Oak Micros provides devices that are socketable/breadboardable and have different form factors/functionality. The on-board USB interface (rather than RS232) is an Oak Micros innovation.

[FFMan]

Thanks for the table Mike - most useful.

Tom:i was just coming round to this way of thinking as switching to a different device involves a touch of overkill and more expense - although I may change my mind again !

I presume I can't readily do this on my prototype zx24a can I as the com1 levels there are rs232 ? Is there access to TTL levels on a ZX24 ?

[dkinzer]

I presume I can't readily do this on my prototype zx24a can I as the com1 levels there are rs232 ? Is there access to TTL levels on a ZX24 ?

The levels on pin 1 of a ZX-24a (TxD) are inverted but they are not, strictly speaking, RS-232 levels (-3 to -15V for mark, +3 to +15V for space). If you add an external inversion stage you'll be back to ~5 for mark and 0 for a space.

[GTBecker]

COM1 _is_ TTL on pins 1 (TX out) and 2 (RX in) on the 24-pin devices.

[mikep]

I presume I can't readily do this on my prototype zx24a can I as the com1 levels there are rs232 ? Is there access to TTL levels on a ZX24 ?

The levels on pin 1 of a ZX-24a (TxD) are inverted but they are not, strictly speaking, RS-232 levels (-3 to -15V for mark, +3 to +15V for space). If you add an external inversion stage you'll be back to ~5 for mark and 0 for a space.

I hate to keep talking about Oak Micros devices but they include both TTL and RS232 serial/USB out. The first versions have a slide switch to allow switching between TTL out and true RS232 and the newest versions have both TTL and USB. The original motivation was for exactly the same reason as you need it - ability to drive a serial TTL device but still do downloads using the same single hardware UART.