PE6 Simulation of 'serrxd' , is it broken or am I missing something ?

Buzby

Senior Member
When I use the simulator to enter a number via serrxd, it seems to enter a 0 automatically the next time the program uses serrxd, before I even touch the keyboard.

If I use a real chip it's OK.

What am I doing wrong ?

Cheers,

Buzby

PE6serrxd.PNG
 

hippy

Technical Support
Staff member
There does seem to be a simulation issue which we will log and investigate.
 

hippy

Technical Support
Staff member
Have logged the issue but in the meantime this seems to be a workround, change your SERRXD #var to SERRXD ($22), #var ...

Code:
Do
  SerTxd( "Input Number... " )
  SerRxd ($22), #w0
  SerTxd( "You entered ", #w0, CR, LF )
Loop
 

Buzby

Senior Member
Hi hippy,

No luck with your workaround.

Something, either the Terminal or PE, just locks up.

I'm not too bothered, my workaround is just to add a second serrxd and discard the result.

Still needs fixing though. Maybe it's time for a better terminal.

We'll just have to see what Father Christmas brings.

Cheers,

Buzby

PE6serrxd2.PNG
 

Technical

Technical Support
Staff member
Actually it's simulating as intended. When using #b13 you should only really use ASCII transmit mode during simulation, you will see the error described if you use raw mode and enter invalid values for the mode (e.g. typing 2<send> in raw mode.).

That is because the special # mode is only ever intended for ascii character input (in the real chip too), so only ascii number characters "0-"9" (48-57) are ever valid entry. This mode also specifically needs a non-number ascii character to finish input, so in ascii mode you must enter something like '42x'. If in raw mode you use 2<send> then you are immediately terminating the ascii entry, hence the value 0 is received.

In raw mode you will need to use the raw ascii values 48-57 only, followed by a different number, e.g 48,49,32. This is confusing to do, so ascii mode would be easier to use.

Entering any other raw number will give an invalid input to the serial buffer, hence a 0 received.

1542060813492.png
 
Top