Acessing the UARTs OEM RF End Device

[BitManip]

I wish to talk to the UARTs of the OEM RF Engine with my own microcontroller with its own UART.

Is the UART Ports autosensing for Baud Rates and how low will they go (like 0.256 or 0.512 KBAUD)?
What is the bit size 8 or 9 and Parity?
What happens in the Sleep mode to the Port lines?
Are there HOOKS written already or do I need to do it from scratch?
Am I assuming correctly that the pinouts of the RF End Device OEM Engine at the Serial Communications Interface Level?
Do I ask too many questions? Maybe I need to call you.:rolleyes:
Thanks in Advance

[kbanks]

Q) Are the UART Ports autosensing for Baud Rates?
A) No, you just pick a fixed baudrate when you initialize the serial port.

The corresponding Snappy API function is initUart(uartNum, baudRate), where "uartNum" is 0 or 1 (for the first or second UART), and "baudRate" is the desired baudrate (300 = 300 baud, 38400 = 38400 baud, etc.)

Q) How low will they (the baud rates) go (like 0.256 or 0.512 KBAUD)?
A) Because it is a numeric value (not an enum), you are not limited to standard baudrates. However, the lowest we have tested is 300 baud.

I'm sure there is some lower limit in the hardware (some maximum divisor value that can be loaded into the internal baud rate generator), but I will have to do further research to completely answer this question.

Q) What is the character size (8 or 9 bits) and Parity?
A) The built-in initUart() function programs the UART for 1 start bit, 8 data bits, no parity, and 1 stop bit.

If for some reason you need some other character format (7 bit, Odd Parity for example) then you would have to directly "poke" values into one or more CPU registers from your Snappy script (after doing the initial setup using the initUart() function).

You would probably want to team up with a Synapse engineer to get the details of which register(s) to poke, but if you are technically savvy all you really need to know is that the RF Engine is based on the Freescale 9S08 processor.

This sort of "extension via peeks and pokes" is used whenever we need to access additional hardware capabilities of the processor, but do not want to burn "core" code space on something we consider non-standard.

Q) What happens in the Sleep mode to the Port lines?
A) The I/O pins are "held" at their current levels while the processor is sleeping, but all internal clocks (including the baud rate generators) are stopped. (We are sleeping in the lowest power sleep mode available on this hardware).

So, output signals will be maintained through a sleep period. However, we currently do not support "wake up on receiving serial data".

The closest substitute would be to run the RX signal to GPIO1 or GPIO2 *in addition to* running it into the "real" RX pin. The "low" value of the initial start bit could wake the processor up, and your Snappy script could then process the *remainder* of the incoming characters.

In other words, I am saying that you probably would NOT receive all of the incoming characters if using this trick .You could compensate for this by using a more robust serial protocol between the RF Engine and your other device (retries, etc.)

Q) Are there HOOKS written already or do I need to do it from scratch?
A) I don't completely understand your question, but will take a stab at answering it anyway. Please re-ask your question in a different format if I completely miss the mark.

Portal/SNAP Pro comes with some example Snappy scripts, which may provide a basis for your custom applications. Snappy (the SNAP Pro scripting language, which is a modified subset of the popular Python programming language) supports "hook" functions for events like:

100 milliseconds elapsed (a timer tick if you will)
Serial data received
Serial TX complete
Remote Procedure Call (RPC) invoked successfully

So for example, if you need to do some periodic processing every 100 milliseconds, you are not starting completely from scratch (you do not have to program the clock hardware, and install an interrupt service handler). However, you DO have to define a handler function in Snappy, plus tell the system WHAT event the function is meant to handle. Here is an example:

def timer100msEvent(currentMs):
global secondCounter

secondCounter += 1
if secondCounter >= 10:
doEverySecond()
secondCounter = 0

snappyGen.setHook(SnapConstants.HOOK_100MS, timer100msEvent)

Again, please re-ask your question if necessary.

Q) Am I assuming correctly that the pinouts of the RF End Device OEM Engine at the Serial Communications Interface Level?
A) Another case where I am unsure of the question being asked.

If you are asking about the actual RF Engine "serial port" signal levels, they are "logic level" (3.3 volt), NOT "RS-232 level".

Note that here I am talking about the signal levels at the actual RF Engine headers.

Please be aware that we also sell various "carrier modules" for RF engines.

The SN163 Bridge Demonstration Board adds on the "line driver" chips to make the first serial port be Universal Serial Bus (USB), and the second port be full RS-232.

The SN111 End Device Board only has the RS-232 interface (second serial port).

The SN171 Proto Board also adds a RS232 interface to the second serial interface (the first serial port is only available as logic levels).

Q) Do I ask too many questions? Maybe I need to call you.
A) Certainly it is not too many questions. It might be more managable in the future if you split them into multiple posts.

As for calling, if you POST your questions then other forum members will get the benefits of the dialog.

Kevin Banks

[kbanks]

The baud rate divisor in the RF Engine is a 13 bit modulo divisor, so possible divisor values are 1-8095 (a value of 0 means "off").

Loading the maximum divisor of 8095 results in a (non-standard) baudrate of approx. 150.381.

So, at the bus clock we are using, baud rates below 151 are not attainable, including 150 baud and 110 baud.

Kevin Banks

[BitManip]

Thanks for the answer so fast. I looked up the specs sheet from Freescale and my calcs for a modulo 13 in base 2 is 8191 reserving the zero state as an off condition. The Baud of 148.618508 should be available when I back calculated for your bus clock of 19.4777347 MHz. or am I missing something?

[kbanks]

I got in too much of a hurry, obviously.

You are correct, the maximum divisor is 8191, not 8095.

However, using the CORRECT maximum divisor I still come up with a minimum baud rate of 152.57164xxxxxx

Baudrate = BUSCLK / (divisor * 16)

BUSCLK = 19995429

Sorry for the confusion - Kevin Banks

[Rick Martindale]

Based on something I read, and I can't recall where, I believe the UART will function reliably if you are within a few percent of the desired baudrate.

I have not verified this to be true at low speeds but it is definitely worth trying.