ZBasic Forum

Posted: **25 February 2011, 6:37 AM**

I am having difficulty getting ZX-24n com ports to work. I tried HW port 2 and SW ports as well. I am trying to connect to a WiFly 134 chip and it works fine with a BS2 stamp processor using serin as follows:

SERIN RPin\FPin, 16468, [STR Result\MaxChar-1]
DEBUG "Msg: ", STR Result, CR

The 16468 parameter means the com channel is 8 bit, no parity, inverted, 1 stop bit. I used the BS2 to validate that the WiFly chip works - it does. Now I am trying to get it to work with the ZX-24n. All I need it to do initially is receive data,... so here is my code:

Const RcvPin as Byte = C.5 ' Comm port transmit pin (pin 7)
Dim RcvQue(1 to 20) as Byte ' Receive queue
Dim Msg as String ' Message from the queue
Dim TimeOut as Boolean ' Time out flag; if true timeout occurred

Sub Main()

Call OpenQueue(RcvQue, SizeOf(RcvQue))
Call ComChannels(2, 9600)
Call DefineCom(3, RcvPin, 0, &H88, 1)
Call OpenCom(3, 9600, RcvQue, 0)

do
debug.print"Waiting for data..."
Call GetQueue(RcvQue, Msg, SizeOf(RcvQue))
:
loop
:

I never return from the GetQueue call - which means (according to the document) I never get anything on the com port. I tried other software coms as well with no avail. I understand that with com 3 I do not have to use the call to ComChannels(). I also tried com 2 - again it doesn't work. I am using com 1 for downloading and debugging so I do not want to use that.

I have a couple of these ZX-24n processors and I really like them - this is the first issue I ran into and I am sure that I am screwing something up. Any help you could render would be helpful.

Posted: **25 February 2011, 7:53 AM**

lattanze wrote:I never return from the GetQueue call - which means (according to the document) I never get anything on the com port.

Actually, it means that the number of bytes you requested (20 in this case), is never present in the queue. This could be because the sending device doesn't send that many bytes or because that many bytes are not present in the queue at one time.

The problem in this case is that the queue is too small to ever contain 20 data bytes. A queue implemented with a 20 byte array only has space for 11 data bytes; the other 9 bytes are for queue management (head, tail, count, status, etc).

Unless you know for certain that the sending device will always send a number of bytes at least equal to the number requested, you shouldn't use the form you've chosen. Rather, it is best to either retrieve one byte at a time from the queue or use GetQueueCount() to find out how many bytes are available and request no more than that.

For more information, see ZBasic Reference: Queues and System Library Reference: OpenQueue.

Posted: **25 February 2011, 11:21 AM**

Here is a version that uses QueueCount():

Code: Select all

Const RcvPin as Byte = C.5     ' Comm port transmit pin &#40;absolute pin 7&#41;
Dim RcvQue&#40;1 to 20&#41; as Byte    ' Receive queue
Dim Msg as String              ' Message from the queue
Dim TimeOut as Boolean         ' Time out flag; if true timeout occured 
Dim QueCnt as Integer

Sub Main&#40;&#41;

    'Open the Receive Queue
    
    Call OpenQueue&#40;RcvQue, SizeOf&#40;RcvQue&#41;&#41;     
    Call ComChannels&#40;2, 9600&#41;
    Call DefineCom&#40;3, RcvPin, 0, &H88, 1&#41; 
    Call OpenCom&#40;3, 9600, RcvQue, 0&#41; 

    'Main control loop

    do 'forever
        debug.print"Waiting for data..."
        QueCnt = GetQueueCount&#40;RcvQue&#41;
        if &#40;QueCnt > 0&#41; then
            Call GetQueue&#40;RcvQue, Msg, QueCnt&#41;
            debug.print"Msg &#40;";QueCnt;"&#41; = "; Msg
        else
            Call Delay&#40;1.0&#41;
        end if                    
    loop
end sub

What happens here is that QueCnt always = 0. I have written a simple server task that is a java program that sends a string of any length I enter.

Posted: **25 February 2011, 12:12 PM**

lattanze wrote:Here is a version that uses QueueCount():

I have reformatted the code (removed tabs, made indenting uniform) and surrounded it with code tags in your most recent post. This makes the code much easier to read.

lattanze wrote:What happens here is that QueCnt always = 0. I have written a simple server task that is a java program that sends a string of any length I enter.

I assume that you mean a java program running on a PC. If that is true, how are you connecting the PC to the ZX? You must use appropriate level converters because the signal from a PC swings from perhaps -15 volts to +15 volts, grossly incompatible with the ZX signals.

Other comments:

The call to ComChannels() is not needed. If you intend to use an additional software UART channel later, it will be needed then.
You cannot use GetQueue() to read from a queue into a string. This fact is present in the description of GetQueue.

I've modified the program slightly as shown below and connected my PC to the ZX through a MAX232 level converter. After compiling and downloading, as I type in the terminal emulator, the characters are displayed in the Debug window of the IDE demonstrating that the code works.

Code: Select all

Const RcvPin as Byte = C.5
Dim RcvQue&#40;1 to 20&#41; as Byte

Sub Main&#40;&#41;
    'Open the Receive Queue
    Call OpenQueue&#40;RcvQue, SizeOf&#40;RcvQue&#41;&#41;     
    Call DefineCom&#40;3, RcvPin, 0, &H08&#41; 
    Call OpenCom&#40;3, 9600, RcvQue, 0&#41; 

    debug.print "Waiting for data..."
    Do
        If StatusQueue&#40;RcvQue&#41; Then
            Dim b as Byte
            Call GetQueue&#40;RcvQue, b, 1&#41;
            If &#40;b = &H0d&#41; Then
                Debug.Print
            Else
                Debug.Print Chr&#40;b&#41;;
            End If
        End If                    
    Loop
End Sub

Posted: **25 February 2011, 13:02 PM**

I am running a java app that is connected to our network. The wifly is connected to the ZXn-24 via com 3/pin 7 and to the same network as the PC. I have com 1 of the ZXn-24 connected to the PC so I can download programs and debug.

I implemented your suggested code snippit per your last post. I tried it as posted and then changed DefineCom() to match the com requirements of the wifly as follows:

Call DefineCom(3, RcvPin, 0, &H88, 1)

Still nothing - it never gets past StatusQueue(). I tried both ZXn chips with the same result.

As I said, I know the wifly works... it connects up to a BS2 in the same configuration described above and I able to send strings from the PC to BS2 via the network, to the wifly, and to the BS2.

Posted: **25 February 2011, 13:41 PM**

lattanze wrote:Still nothing - it never gets past StatusQueue(). I tried both ZXn chips with the same result.

Do you know what version of the compiler and the ZX Library you're using? There was as issue with inverted mode in versions 3.0.0 through 3.0.3 of the ZX Library. If you downloaded the ZBasic installer since 19 Oct 2010 you'll have the latest released versions with that issue resolved.

If you have a logic probe, oscilloscope or logic analyzer you can check to be certain that you are receiving a proper signal at pin 7. In inverted mode, the signal should idle near ground and make transitions to near +5 for zero bits of the transmitted character.

Does the WiFly device have 5 volt outputs or is it lower? When running on +5 the ZX won't recognize a signal as logic one until it goes above 3.0 volts. You may need to add a level converter between the WiFly and the ZX. A simple bipolar transistor or FET would suffice; this will give you a signal inversion however.

Posted: **25 February 2011, 14:55 PM**

I am using compiler version 3.1.

I tested the signal at the receive pin with a logic probe... found some interesting results.

On the BS2, I send data to the wifly and was able to observe the pin pulse between hi/lo on a logic probe as the data is sent to the BS2.

I tried the same experiment on the ZX-24n, but the pin remained in the low state when data was sent to the wifly.

If you look at the output of the pin when not connected to anything and send data to the wifly, it stays low.

The pin quiescent value on both the BS2 and the ZX is right around -.8v prettly close to zero. The logic probe is set for TTL. The BS2 requires TTL I/O as well and so far the BS2 and ZX have been compatible in this way.

So what ever is causing the pin to be pulled to ground is causing the problem. Its almost looks like the ZX pin is in a high impedance state or something?...

Posted: **25 February 2011, 15:45 PM**

lattanze wrote:I tried the same experiment on the ZX-24n, but the pin remained in the low state when data was sent to the wifly.

Add the line below to your code after the call to OpenCom():

Code: Select all

Debug.Print "DDRC=&H"; CStrHex&#40;Register.DDRC&#41;; ", PORTC=&H"; CStrHex&#40;Register.PORTC&#41;

The DDRC value controls the direction of each of the pins of Port C; a zero makes a pin an input while a one makes the pin an output. The PORTC value sets the output level (for a pin that is an output) or controls the pullup resistor (for a pin that is an input). Report back the values you get.

lattanze wrote:The pin quiescent value on both the BS2 and the ZX is right around -.8v prettly close to zero. The logic probe is set for TTL. The BS2 requires TTL I/O as well and so far the BS2 and ZX have been compatible in this way.

If you're measuring voltage on an input pin with nothing connected, the result is meaningless. Input pins have a high impedance and they will act like an antenna with nothing connected.

I agree that the BS2 have 5-volt compatible inputs. The issue that arises, however, is the minimum voltage that the BS2 or ZX recognizes as a logic 1 and the maximum voltage that they recognize as a logic zero. These logic thresholds may well be (and probably are) different between the BS2 (which is PIC based) and the ZX (which is AVR based).

Posted: **28 February 2011, 9:49 AM**

So the result of adding:

Debug.Print "DDRC=&H"; CStrHex(Register.DDRC); ", PORTC=&H"; CStrHex(Register.PORTC)

is this on the output...

ZBasic v3.1
DDRC=&H00, PORTC=&H00
Waiting for data...

I guess this means the port is an input port... The ZX-24n still won't talk to the wifly (or vis-versa)

Maybe I need to get an O-scope and put the wifly back on the BS2 and see what the logic levels are from the wifly.

Do I need a pull-up or pull-down resistor on the input of the ZX-24? I do not have one right now (I did not need one on the BS2).

Posted: **28 February 2011, 11:30 AM**

lattanze wrote:I guess this means the port is an input port.

The first value indicates that all bits of PortC are configured to be inputs. The second value indicates that the internal pullup resistors are disabled for all of the pins of PortC.

lattanze wrote:Maybe I need to get an O-scope and put the wifly back on the BS2 and see what the logic levels are from the wifly.

That would be useful information. We're flying blind now.

lattanze wrote:Do I need a pull-up or pull-down resistor on the input of the ZX-24?

If the WiFly actively drives its transmit output pin in both states, no pullup or pulldown is required. If it actively drives only one state, you'd need a pullup/pulldown to realize the other state. I'd have to check the datasheet for the PIC used on the BS2 to determine whether it has pullup resistors on some/all of its inputs.

Posted: **01 March 2011, 16:19 PM**

So I found out what the problem is... for some reason, the xmit pin must be held high on the wifly when you receive data. I spend the day with the system on the bench scoping every signal and comparing the interaction with the ZX-24 with the BS-2. I noticed that on the BS-2 lab set up all the pins on the serial port are connected, while on the ZX set up only the rcv and ground pins are actually connected to the processor. I pulled all the serial pins on the BS-2 except the rcv and ground and duplicated the failure. As soon as I connected the xmit (even though I am not using it) it worked. I measured the signal on the BS-2 and it was ground.

I moved the wifly back to the ZX, connecting the xmit to ground,... still no communication. For grins, I connected xmit to Vcc and bingo... it works. So it seems the ZX and my mother board was rock solid all along and the code was reasonably correct...

I just got it to work moments,... I still do not understand why, but will figure it out tomorrow,...

Thanks for all your help!

T.

Posted: **07 March 2011, 17:09 PM**

lattanze wrote:So I found out what the problem is... for some reason, the xmit pin must be held high on the wifly when you receive data.

I must say, the one datasheet I did find from Roving Networks was rather brief. It did show the pin out and not one of them (that I saw) was labelled as "xmit". What pin is it?

The last line of your message implys that the board only worked for moments, then stopped. Is that correct?

On the Stamp, does the "xmit" pin change state ever?

-Tony

ZBasic Forum

Issue using com ports...

Issue using com ports...

ZXn-24 comm - still a problem...

Re: ZXn-24 comm - still a problem...

Got it!

Re: Got it!