zic2410 - Using both UARTs

[Kham]

This one had me scratching my head for a bit.
To use the 'second/other' UART, flow control has to be disabled on that UART.

ie, the default UART is 1.
If you want to use 0 for DS_STDIO and leave 1 as the endpoint for DS_PACKET_SERIAL

You need to turn off flow control for UART0.
Either by using
NV ID 11 - Feature Bits (pg95 in manual)
or in the script with flowControl. eg flowControl(0,False)

Sorry if this has already been posted, but I could not find it.

[kbanks]

I think what you are really seeing is

If flow control is ON, then somebody better be driving the RTS signal into the SNAP Engine.

Packet Serial is an exception, since that protocol ignores flow control completely.

But if you want to use DATA MODE or STDIO mode, either provide the needed handshake signals, or turn them off in software.

You are correct, they can be turned off via the Feature bits or via the flowControl() method.

Windows users may be familiar with this sort of thing from the Hyperterm program that used to come with Windows. If you tell Hyperterm to use Hardware Flow Control, and then don't provide the needed signals, it will "hang" waiting on the flow control handshake that you told it to wait for.

[njones]

I was excited when I saw this one, it changed to dissapointment when I realized this post wasn't about using both UARTS within a script at the same time ...

[Kham]

Depending on how you use them it might be possible.
It is a case of switching to the one you want when you need it.

And if you are listening to both ports for input maybe an interrupt could be used to initiate a port change?
Just some ideas, currently untested. :)

[njones]

I'm actually pushing for concurrent use of 2 (or more) ports. I have already dropped this in the "suggestion box" - I was just giving the tree a shake ...

[spazvt]

So the concurrent use of two ports ... or at least two 'pipes' within the switchboard.

I'm working on the 'bridge' for my application that would talk serial over a hardware UART to an FPGA on our board and then wirelessly send messages (via rpc calls) to our wireless handheld device. I'd still like to use DS_TRANSPARENT for sending debug messages back to the Portal, though. So the issue that I see is that "print" is the only command to send data out to DS_TRANSPARENT and the UART. So I was looking for a command that would send data to a specific interface so that I could avoid someone's previous solution of redirecting DS_STDIO every time I wanted to output data. Looking through posts, I see references to "sendData(addr, data)" but that command doesn't appear to be supported in the Portal version I'm using (v2.2.29).
Is there another feature I'm missing?

Also, I'm assuming that the format for Packet Serial protocol isn't openly published since I don't see any details. I just thought it might be more space efficient to use that protocol at my bridge instead of implementing my own protocol within SNAPpy.

[kbanks]

I see references to "sendData(addr, data)"

That's the command in Portal, not in SNAPpy. SNAPpy still only supports print.

[kbanks]

Also, I'm assuming that the format for Packet Serial protocol isn't openly published since I don't see any details.

Right, SNAP is proprietary and we do not publish any of the packet formats.

[kbanks]

On the topic of "more UART access", the ticket is still in the feature bucket...

We are having to trade off "ever more functionality" against "the bigger the core gets, the smaller the script space gets".

I don't know of any way of easily handling two independant INCOMING serial streams with the current SNAP. I'm toying with the idea of just adding a getInfo() option to ask "where did this data come from". This would have a pretty small code footprint.

In the outbound direction, I think you could get by with the existing core using something LIKE the following (not actual tested code, I'm just typing this straight in):


from synapse.switchboard import *

uart0Data = ''
uart1Data = ''

@setHook(HOOK_10MS)
def flushData():
global uart0Data, uart1Data
if uart0Data:
crossConnect(DS_UART0, DS_STDIO)
print uart0Data
uart0Data = ''
elif uart1Data:
crossConnect(DS_UART1, DS_STDIO)
print uart1Data
uart1Data = ''

def enqueueForUart0(str):
global uart0Data
uart0Data += str

def enqueueForUart1(str):
global uart1Data
uart1Data += str


You would have to experiment to see which timer hook gave the best performance for your application. Too fast and you might run the node out of memory buffers. Too slow and your strings might overflow.

[kbanks]

I was just giving the tree a shake ...

Definitely worth doing. We DO take the forum feedback into account when deciding what to add next...

[spazvt]

Thanks for the suggestion of switching the crossConnect back and forth. The workaround I just wrote was to create a function on the USB Stick (or any non-UART node) that connects STDIO to DS_TRANSPARENT and can be called by remote nodes to print text to the Portal console.

Code loaded on USB Stick (or any non-UART node):
from synapse.switchboard import *

@setHook(HOOK_STARTUP)
def startupEvent():
crossConnect(DS_STDIO,DS_TRANSPARENT)

def debugPrint(data):
print dataCode loaded on wireless node using UART:
from synapse.switchboard import *
PORTALSTICK_ADDR = "\x03\xBF\x08"

@setHook(HOOK_STARTUP)
def startupEvent():
crossConnect(DS_STDIO, DS_UART1)
initUart(1, 1) # 1=115200
stdinMode(1, False) # Char mode, no echo
rpc(PORTALSTICK_ADDR, "debugPrint", "Node1: test debug statement")The odd side effect is that other nodes in the network that have STDIO linked to DS_TRANSPARENT also echo the text. Not a huge issue and does what I need for now.


Personally, I'm also hoping for the port to the MC13224 which has more space at 96kB of SRAM.

[kbanks]

The odd side effect is that other nodes in the network that have STDIO linked to DS_TRANSPARENT also echo the text.

I think you are missing a line of script.

I see you doing a crossConnect() to associate DS_STDIO with DS_TRANSPARENT, but I don't see you specifying where DS_TRANSPARENT should go.

Please take a look at the mcastSerial() and ucastSerial() built-ins in the SNAP Reference Manual.

It sounds like your node is defaulting to multicast data mode.

[scootr]

I don't know of any way of easily handling two independant INCOMING serial streams with the current SNAP. I'm toying with the idea of just adding a getInfo() option to ask "where did this data come from". This would have a pretty small code footprint.


is just knowing where the stream came from the only issue with dual UART incoming streams? for instance, if I have one UART connected to a GPS device and the other connected to some other device and I'm comfortable that my STDIO parser routine will be able to distinguish which device a stream came from based on the preceding "$" (NMEA). Will the STDIO hook work for both streams? Then I only have to switch the outgoing stream (via uniConnect) depending on which device I want to send to.

As I understand the documentation, a destination may have multiple sources.. so the Standard In could have 2 UARTS (uni)connected to it simultaneously... correct?

[kbanks]

As I understand the documentation, a destination may have multiple sources.. so the Standard In could have 2 UARTS (uni)connected to it simultaneously... correct?

Yes.

As you said, the STDIN_HOOK handler would have to be smart enough to tell the data apart.

One thing that might help that is set the UART buffering timeouts so that the data tended to be pushed in "complete chunks" (bursts). Look at the Inter-character timeout for this.