ZBasic Forum

I have an application where I am interacting with a proprietary wireless transceiver at 9600 baud, and a generic serial 2-line x 20 character point-of-sale display, also 9600 baud. I am using pins 5 and 6 for the network and pins 7 and 8 for the display.

The basic application is to receive text messages over the wireless network, then scroll them left to right on the POS display. All of this code works fine, except that is seems like the wireless network buffer is being overrun pretty regularly and causing the device to either lockup or restart itself. This will happen whether I am running the display update loop or not.

The wireless network is for the most part idle, but when it does talk, it gets a burst of 50-80 character messages, 2 to 5 at a time. There is a reasonable amount of code required to parse, decode and acknowledge.

I would post code, but there's a lot to deal with here, not realistic, plus I can't post anything about the proprietary protocol. My suspicion is that my network protocol processing is just too inefficient.

So my questions, and I understand that they are not that simple to answer:
1) Am I asking too much of the device, will this ever work reliably?
2) I am out of time. Is there a consultant out there that can jump on this and get it working for me (if it's possible)?

Thanks,
Andy

Which ZX device are you using and what version of the VM does it have installed?

ahouriet wrote:I would post code, but there's a lot to deal with here, not realistic, plus I can't post anything about the proprietary protocol. My suspicion is that my network protocol processing is just too inefficient.

So my questions, and I understand that they are not that simple to answer:
1) Am I asking too much of the device, will this ever work reliably?
2) I am out of time. Is there a consultant out there that can jump on this and get it working for me (if it's possible)?

You probably need to use some of the multi-threading capabilities of ZBasic. I can process messages from a 115K baud RS485 link without too much trouble. See application note AN-218.

If you cannot post anything about the proprietary protocol then it will be much harder for us to help you. Can you post any more details - perhaps a code outline?

If you decide to employ a consultant then this is the forum where all of the ZBasic experts are. You will also need to have a confidential disclosure agreement with the consultant for him/her to even look at your code. The fact that you are in a hurry will also drive up the cost.

From the debug window: ZX24 v2.1

Mike, thanks for the tip on the app note, lots of good info there. The confidentiality agreement is not a problem, that is expected. I'm not so much in a hurry to get it done as I have no time to work on it, although that's what I 'd rather be doing!

Here's a basic outline of what I am doing. In this context, the parent app is running on a PC with a corresponding wireless transceiver device:
- Setup and open both ports
- Initialize the POS display, show the startup message
- Initialize the transceiver, including request status from parent app
- Main Loop:

Tranceiver:
- Check for any queue data
- If any, move it from the queue into a buffer, parse the buffer and pull out any commands
- Process each command
- Send acknowledge back to PC if needed

POS:
- Update the scrolling message on the POS to the next character or next message, as needed

- Delay 0.15, back to top

As I write this, I wonder if that Delay is causing me some of the trouble.

so if I were to recode some, or all of this into multi-threaded code, where would be the best place to start? Should both serial handlers be threaded, or just one?

Hopefully this provides more insight.

Thanks,
Andy

ahouriet wrote:ZX24 v2.1

Based on your description, I suspect that you're seeing the effect of a problem that was fixed last fall. This problem was discovered by another user who had a GPS unit attached to Com3 which was sending a lot of messages. On occasion, the input queue would be full when a character arrived. A defect in the VM code caused it to corrupt the stack resulting in a "hang", reset or similar unexpected behavior.

ahouriet wrote:Mike, thanks for the tip on the app note, lots of good info there.

Also check out the two application notes on multi-threading.

ahouriet wrote:- Delay 0.15, back to top

As I write this, I wonder if that Delay is causing me some of the trouble.

My guess is that this delay is so that the user can view the text on the display. This code is much better being placed in another task.

ahouriet wrote: so if I were to recode some, or all of this into multi-threaded code, where would be the best place to start? Should both serial handlers be threaded, or just one?

I would start by analyzing the code some more first. It might be best to put the display code in a separate task first because it has user interaction.

You may be suffering also from a general slowness of the software UARTs used for COM3 and above. There are several solutions:

• Use a I2C based LCD display. These tend to be faster than LCDs with a serial interface.
• The ZX-24a only gives you access to the RS-232 voltage levels. I think you are looking for TTL logic levels. You could use the pin compatible ZX-24ae which gives you one hardware USART or the ZX128e which has two hardware based USARTs.

Thanks Don, I'll update and test with that.

Mike, thanks for the input, now I know where to start.

Andy