The short answer to your question: probably.
The long answer is a bit more complicated.
Qlarity Foundry's Simulation view does not attempt to simulate the processor speed of the terminal. It will run at the native speed of your CPU -- i.e. something like 2-3 GHz with a whole lot of optimized hardware. Your Z60 is our extra low cost Qlarity terminal, which has a much lower performance processor -- about 75 MHz, and a much less optimized memory subsystem. So slower processing speeds are to be expected on the Z60. If you need more processing power you might consider the G70 terminal, which will run the same Qlarity code but at 2-6x the Z60's speeds depending on what you are doing.
Having said that there probably are things that can be done to optimize the situation. The #1 big one that I can see based on the limited code you have posted is: setserialrecvsize(BasicSerial_1.Comport,1). This line of code is brutal in two ways.
First of all, it is executed for every single byte that is received on the serial port, but only really needs to run once at program startup. Try moving it to the program startup like this:
- Code: Select all
'Global code section
func Startup ()
handles MSG_INIT
'Add any code needed to prepare the workspace here.
'Code that needs to intereact with other objects, or that needs the
'Z-order to be established should be placed in PostInit function
UserDirectMsg(default, _MSG_POST_INIT, 0, false)
return
endfunc
func PostInit(parm as integer) returns boolean
handles _MSG_POST_INIT
'This function will be called after all objects have processed their Startup function
'Add any startup code that needs to interact with other objects here
SetSerialRecvSize(BasicSerial_1.Commport, 1)
return true
endfunc
This may produce a minor speed increase. However by far the worst problem in your serial receive code is that you are processing it one byte at a time. You would be much better off trying to process it in good size chunks at a time. To set that up start modifying the global code we just wrote like this:
func PostInit(parm as integer) returns boolean
handles _MSG_POST_INIT
'This function will be called after all objects have processed their Startup function
'These are HINTS for optimization, do not rely on them.
SetSerialRecvSize(BasicSerial_1.Commport, 800) 'a HINT at how large the data messages will be
SetSerialTimeout(BasicSerial_1.Commport, 2) 'indicate that you want data quickly if there is any gap in the serial stream
return true
endfunc
Next you need to modify your DataReceived function to deal with arrays of bytes arriving instead of individual bytes. The easiest way to do that is take your current logic and wrap it in a FOR loop. This will give you a decent feel for whether you have bought anything with your optimization. There are many further optimizations you could perform. For instance, it is common to simply buffer data until at least one packet has arrived (see SetArrayData for the fastest way to do that), then parse the packet and copy it. Often this is easier to code than the state machine you have set up. And it is usually much faster as well.
