picaxe serial interface with a software

[alistairsam]

Hi,

I need to interpret ascii data sent from a software via the programming cable and perform relevant tasks on a 28x2, but am having some trouble parsing the data.

the software is an autoguiding software (guidemaster) for sending correction pulses to a telescope controller when a star drifts from the software's monitored position.
there are 8 commands delimited with a #.
#:Mw# for "move west", #:Me# for "move east and so on.

I used a serial to serial cable between two laptops, ran hyperterm on one, and the astro software on the other. below is the data captured in hyperterminal.

#:RG# ; initialize
#:Me##:Qw##:Qe# ;Move east, quit west, quit east
#:Mw##:Qw##:Qe# ;move west, quit west, quit east
#:Ms##:Qn##:Qs#
#:Mn##:Qn##:Qs#
#:Q#

I wrote the code below to see if the picaxe (28x2) recognizes the # as a qualifier and stores the following 3 bytes into the scratchpad and then display it in the terminal. But the output I'm getting from the terminal reading the 3 pointer values is as below

§5þEnd
§5þEnd
§5þEnd
§5þEnd

I'm expecting :RG

code is as below

#picaxe 28x2


symbol led = b.7

main:
ptr=1
high led
disconnect
serrxd [5000,timeout],("#"),@ptrinc,@ptrinc,@ptr



timeout:
low led
reconnect
ptr=1
for b10=1 to 4
sertxd (@ptrinc)
next b10
pause 1000
sertxd ("End",CR,LF)
goto main

I kept the timeout value high so I can see if the LED goes off before the timeout when the qualifier is recognized and it does.
am I doing something wrong?

this is following my earlier thread http://www.picaxeforum.co.uk/showthread.php?19292-Serial-interface-to-a-PC&highlight=serrxd+ascii

as for raising an interrupt when data is received, are the hsersetup and setint commands more relevant to hserin data over the hardware serial pins?

thanks

 

[Technical]

What baud rate did you use in hyperterminal?
It's probably a true polarity signal you need, so you can't use serrxd. You will be better off using the hardware serial pins.

Until you get the baud rate and polarity matched (Nxxx or Txxxx) nothing is going to work!

 

[hippy]

What baud rate does the guidemaster use ?

How are you getting data into the SERRXD and getting data out from the SERTXD ?

I suspect you would be better of using high-speed background receive on the X2 and parsing all data on the fly. It's more complicated that way but more likely to overcome all the obstacles you may encounter trying to do it with SERRXD, SERRIN or HSERIN.

 

[MPep]

Just had a quick read, appears that GuideMaster uses LX200 protocol. This is explained in the PDF on http://www.meade.com/support/CommandSet.html website. Strangely enough a Baud rate is NOT mentioned.

 

[Armp]

Quickstart says:

6. If the astronomical software requires it, configure the computer
Com Port as follows:
• Baud Rate 9600
• Data Bits 8
• Parity None
• Stop bit 1
• Flow Control None

 

[alistairsam]

Hi
I am using 9600 baud in hyper terminal.
in guidemaster, you have options to specify which telescope you're connecting and I am using lx200 as that's the easiest to emulate, no option for baud rate though.

If I am to use the hardware serial pin, do I have to use a max 232 interface between the laptop and the picaxe or can I use the same 22k resistor network as in the serial download pin

Hippy, I have the programming editor and guide master open in the same laptop. I connect the telescope in the software which sends the init command above, then make a few guide corrections. During this, the picaxe is connected with the programming cable.
I then disconnect telescope in the software, and bring up the terminal window in the editor.

I'm not sure if baud rate could be an issue as the led goes off the moment the software sends an init command which has the qualifier, so I'm guessing the picaxe received the qualifier.

Would it help if I converted ASCII to hex or decimal?
Fact that the characters repeated are identical, to me indicates it's receiving consistently.

 

[Armp]

It looks as if you can change baud rate using the LX200 protocol?

View attachment 10236

 

[alistairsam]

It looks as if you can change baud rate using the LX200 protocol?

View attachment 10236

Hi,

I connected the two laptops again with a serial to serial, ran the Aiterm term software on one and guidemaster on the other, tried different baud rates from 4800 to 38400 on the receiving laptop, I get the correct commands only at 9600, so pretty sure guidemaster default is to send at 9600.

Armp, I'm guessing that command to change the baud rate would normally be used to change the baud rate on an actual telescope, in my case it is a picaxe, so won't be used.

with serrxd, can I receive in hex if the transmit is ascii?

this is what I got with Aiterm "display hex" turned on
quit - 23 3A 51 23
Init - 23 3A 52 47 23
Move East - 23 3A 4D 65 23
Quit west - 23 3A 51 77 23
Quit East - 23 3A 51 65 23

the last three commands are sent together for one move command

 

[srnet]

with serrxd, can I receive in hex if the transmit is ascii?

They are the same thing really, a character is an 8 bit byte, whci can be represented in ASCII, hex, decimal or binary.

The 'ASCII' character # is 23 in hex, 35 in decimal or 00100011 in binary.

To convert ASCII values into the hex (or decimal) equivalents do a Google search for ASCII table, up to hex 7F then the characters displayed are reasonably standard, the graphics characters from hex 80 to hex FF not so standard.

 

[alistairsam]

Hi
So if it's pretty certain that the baud rate that the software is using is 9600, what else should I look at on the picaxe for it to receive using serrxd and retransmit with sertxd
Else should I look at hserin using background receive
Can I use a 10k and 22k resistor network similar to the programming pins and use the serial programming cable
It would be immensely useful if I can get this working
Thanks

 

[hippy]

should I look at hserin using background receive

I would recommend that. Connect leg 6 (Serial In) to leg 18 (HSERIN) of your 28X2 and try the following code. Wire as previously using SERRXD from controller / SERTXD to Terminal, the 22K/10K for Serial In will also provide for the HSERIN ...

#Picaxe 28X2
#Terminal 9600

Disconnect
HSerSetup B9600_8, %111
Do
  If ptr <> hSerPtr Then
    SerTxd( @ptrInc )
  End If
Loop

See if what is sent from the controller is displayed on the Terminal screen.

 

[hippy]

Wire as previously using SERRXD from controller / SERTXD to Terminal

Having re-read your earlier post ...

Hippy, I have the programming editor and guide master open in the same laptop. I connect the telescope in the software which sends the init command above, then make a few guide corrections. During this, the picaxe is connected with the programming cable.
I then disconnect telescope in the software, and bring up the terminal window in the editor

I'm not exactly clear on how you mean but it seems you are swapping serial cables completely. If so, what Terminal shows is the residual 'last received' information by virtue of the timeout of the SERRXD. And it's also possible that data is not what the controller sent but corrupt data generated when disconnecting or connecting cables.

You really need to have the setup working so you can receive from the controller and output to the Terminal at the same time. Yes, add the 22K/10K to the HSREIN if you rewire to do that. The above code can still be used but you can take out the DISCONNECT.

 

[alistairsam]

Having re-read your earlier post ...



I'm not exactly clear on how you mean but it seems you are swapping serial cables completely. If so, what Terminal shows is the residual 'last received' information by virtue of the timeout of the SERRXD. And it's also possible that data is not what the controller sent but corrupt data generated when disconnecting or connecting cables.

You really need to have the setup working so you can receive from the controller and output to the Terminal at the same time. Yes, add the 22K/10K to the HSREIN if you rewire to do that. The above code can still be used but you can take out the DISCONNECT.

Hi,

I'm not disconnecting the cable at all. all I do is choose the disconnect option from the software so it frees up the serial port. I then switch to the prog editor window and bring up the terminal so I can receive the sertxd from the picaxe.
Both the software and the programming editor use the same serial port but only one at a time.
when I choose disconnect, it sends "#:Q#" without the quotes. so I'm expecting to see that and I click on disconnect only when my LED is on. my code switches off the LED after the timeout.

But I will wire a resistor network to the hserin pin and connect to a different serial port. so I'll have one port connected to the picaxe download pins and another to the hserin pin so I don't have to switch between the two.

will post results shortly.

thanks.

 

[alistairsam]

Hi,

I've tested with a 20x2 with a serial LCD connected to b.0 and I connected pin 2 to pin 12, that is serin to hserin as advised above.

so I have the programming cable connected to com5, guidemaster connected to com5, and I'm running the code below. I'm not disconnecting the cable at any time.
idea is to receive in scratchpad and display in the LCD.
but I get a garbled character for the ptr value.

is the syntax of the hsersetup below correct? do I need to use the disconnect and reconnect since pins 2 and 12 are connected?

#Picaxe 20X2

setfreq m8

main:
disconnect
serout B.0, T9600_8,(254,1)
serout B.0, T9600_8,(254,128,"Receive")
pause 1000

for b2=1 to 254
HSerSetup B9600_8, %11
If ptr <> hSerPtr then disp
next b2



disp:
inc b10
 serout B.0, T9600_8,(254,1)
 serout B.0, T9600_8,(254,128,"Display,",#b10,",",@ptrInc)
 reconnect
 pause 2000
  goto main

 

[hippy]

so I have the programming cable connected to com5, guidemaster connected to com5

It will be much easier with the guidemaster on one COM port and monitoring the PICAXE on another. Then you can try with the simpler code below. Also try with HSERSETUP's %111 changed to %001 if it is just a polarity issue.

#Picaxe 20X2
#Terminal 9600

HSerSetup B9600_8, %111
Do
  If ptr <> hSerPtr Then
    SerTxd( @ptrInc )
  End If
Loop

 

[alistairsam]

It will be much easier with the guidemaster on one COM port and monitoring the PICAXE on another.

Hi,

Guidemaster is the software running on the laptop with the programming editor. once I download the code on the picaxe, I don't use the port with the programming editor, so its free for the software to use. I thought the LCD would be easy to use as an output to monitor. I already had this setup so used it.
But I'll try and connect a separate com port to the hserin pin. will just need to wire a serial cable.

meanwhile, I tried this code below, whenever I press a move button in the software that sends a string, the lcd changes from "receive" to "display,21,junk char and goes back to receive. (the 21 is just a counter I added that increments as expected)

#Picaxe 20X2

setfreq m8

main:
disconnect
serout B.0, T9600_8,(254,1)
serout B.0, T9600_8,(254,128,"Receive")
ptr = 0
HSerSetup B9600_8, %11
hserin [1000,main],0,4
If ptr <> hSerPtr then disp



disp:
inc b10
ptr = 0
 serout B.0, T9600_8,(254,1)
 serout B.0, T9600_8,(254,128,"Display,",#b10,",",@ptrinc,@ptrinc,@ptrinc,@ptr)
 reconnect
 pause 1000
  goto main

so it is receiving serial data from the software, just not sure why the data is garbled.

isn't it possible to use the output buffer in the programming editor terminal to send data and display that on an LCD on any picaxe?
I can't seem to get that working.

i'll wire up a separate cable from a spare serial port to the hserin pin and post results. I'll use a similar 22k/10k network to the pin.

thanks

edit: i can use serrxd to receive characters in type in the output buffer and display on the LCD. that works.

 

[alistairsam]

I finally got it working with the code below with just serrxd. not sure what I was doing wrong earlier.
Now, I can see the commands being sent from the software on the LCD.
only problem is it doesn't display when the characters are less than 5. even when I type in the output buffer, if I type in 5 characters, i get the display, else it stays at receive. is this normal?
how do I receive variable lengths?

#Picaxe 20X2

setfreq m8

main:
disconnect
serout B.0, T9600_8,(254,1)
serout B.0, T9600_8,(254,128,"Receive")
ptr = 0
serrxd [5000,main],@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr
If ptr <> 0 then disp



disp:
inc b10
ptr = 0
 serout B.0, T9600_8,(254,1)
 serout B.0, T9600_8,(254,128,"Display,",#b10,",",@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr)
 reconnect
 pause 1000
  goto main

 

[srnet]

Which serial LCD ?

 

[alistairsam]

Which serial LCD ?

its a standard 2 line 16char LCD with a sparfun serial module connected to b.0

edit: what I meant with not displaying lesser than 5 characters, is that the display is still at "receive" as in the code, but immdly changes to "display" when there are 5 characters. I'm guessing this is to do with the use of the ptrinc.

 

[srnet]

Dont know that one, sorry.

 

[hippy]

how do I receive variable lengths?

High-speed serial background receive

 

[alistairsam]

Thanks Hippy,
I went around in one big circle and came back to hserin.

I think it was the polarity as you mentioned, but I got it working with hserin now.
I was using %11 and then changed to %111 and its working with the code below.

but how do I cater for say 15 bytes, but display even if data received is less than 15?

#Picaxe 20X2

setfreq m8

pause 500

disconnect

serout B.0, T9600_8,(254,1)

ptr = 0
HSerSetup B9600_8, %111

main:

do
hserin [1000,main],0,5
 if ptr<> hserptr then     
  ptr = 0
  serout B.0, T9600_8,(254,1)
 serout B.0, T9600_8,(254,128,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr)
 endif
 loop

 

[Goeytex]

You don't use hserin with background receive.
The data just magically appears in the scratchpad memory.

To detect if data has arrived into the scratchpad you can use a hardware interrupt with setintflags set
to generate an interrupt on background serial activity. Hserptr can give you the length of the data
packet. Extract as many bytes as you want by using the "get" command.

 

[hippy]

You don't use hserin with background receive.
The data just magically appears in the scratchpad memory.

What Goeytex says ^

You can handle the data as suggested or you can process it on the fly using '@ptr' and related commands. The trick is to ensure you have the data, are not trying to use data which hasn't arrived yet, and that your processing is tailored to what you want to do.

There's no 'on a plate solution' which fits every need but solutions may point towards a good way how to. I personally prefer letting the incoming serial free-run and using 'ptr' to indicate when new data has arrived rather than any other ways, but other ways may suit certain situations better. For example the following (untested) should print every character received after a ":" ...

MainLoop:
  HSerSetup ...
  Do
    Do 
      Gosub GetChar
    Loop Until b0 = ":"
    Gosub GetChar
    SerTxd( "Got :", b0, CR, LF )
  Loop

GetChar:
  Do : Loop Until ptr <> hSerPtr
  b0 = @ptrInc
  Return

 

[alistairsam]

Hi,

I came up with the code below that uses interrupts.

Hippy, I tried your code, but since my output is an LCD, not sure whether the CR,LF will work. so its displaying the first character only.

#Picaxe 20X2
pause 500

setintflags %00100000,%00100000
disconnect

serout B.0, T9600_8,(254,1)
HSerSetup B9600_8, %111

main:
do:loop

Interrupt:
ptr = 0
serout B.0, T9600_8,(254,1)
serout B.0, T9600_8,(254,128,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptr)

Interrupt_Enable:
hserinflag = 0
HSerSetup B9600_8, %111
setintflags %00100000,%00100000
return

 

[hippy]

Hippy, I tried your code, but since my output is an LCD, not sure whether the CR,LF will work. so its displaying the first character only.

I'd really suggest getting rid of the LCD, setup two serial ports, one feeding HSERIN and the other for the download so it can monitor what the PICAXE is doing with SERTXD. It really is the best way to proceed, not least because an LCD can only show what has last arrived whereas Terminal and SERTXD gives a trace of everything(ish), and you can add other debugging information in with that. Also get a character sequence that screws up the LCD and once sent out you won't be able to tell what's going on !

Your current code fails the "ensure you have the data, are not trying to use data which hasn't arrived yet" requirement. Your interrupt fires as soon as the first byte of data is received, you then read the scratchpad and report the data ... but there's no guarantee anything other than the first byte has been received at that time. By luck it probably has, but no guarantee. If you were faking data from a terminal to simulate what the guidemaster sends it wouldn't work.

There are also other issues you are going to run into because of variable length data, hence my suggestion of coding it in a manner similar to the code in post #24.

What's probably worth doing, now you have serial working, is going back and detailing exactly what the guidemaster sends and what data you need to extract from that. I wasn't clear from an earlier post which "#" were indicating numbers and which were actual "#" characters.

 

[alistairsam]

Hi,

will test with two serial ports and post results.

thanks

 

[srnet]

I'd really suggest getting rid of the LCD, setup two serial ports, one feeding HSERIN and the other for the download so it can monitor what the PICAXE is doing with SERTXD

Having used a LCD and OLED a fair bit recently I would agree.

LCDs need a fair bit of care to get them to display what you think you want to display, so much easier to just shove everything out to a decent serial terminal till your program is debugged and working, then worry about formatting stuff for the LCD.

 

[alistairsam]

I've connected hserin to a separate serial port from the programming port and hippy's code in post 11 works great.
below is an output
#:RG##:Mn##:Qn##:Qs##:Mw##:Qw##:Qe##:Ms##:Qn##:Qs##:Me##:Qw##:Qe#
The M commands are for move and Q for quit.

There is a specific delay between the Move and quit to allow the motor speed correction to be carried out.
in my case, the motor correction is updating a variable for another picaxe. that is basically the pauseus value for a stepper pulsout routine.
the normal pauseus value is 2300, when the guidesoftware sends a correction, the value would be 10 times lower or higher so the motor would speed up or slow down 10x for half a second and return back to the normal rate.
this is repeated till the star is back at the cross hairs.

I'll need the picaxe to wait for a Move command and update the variable based on whether it was Mn or Ms or Me or Mw and then revert the value when the Q command comes in.

I presume this is possible and have a few ideas, do you'll see any issues?
i'll try writing this code and post results.

Thanks again.

 

[hippy]

Assuming the "Mn##" etc are numbers where # is it should be easy enough to extract the commands and values by extending the code in Post #4, and, while still untested, the following code should work whether my assumption's right or not. This is the way I'd do it, and then all you have to do is fill in handling the commands.

Note there are a few subtle changes to the code from Post #4 because the GetNumber routine will terminate on a ":" so we will already have read that when we come to look for the ":" to locate the next command. So no need to wait for a ":" if one has just turned up.

MainLoop:
  HSerSetup ...
  Gosub GetChar
  Do
    Do Until b0 = ":"
      Gosub GetChar
    Loop
    Gosub GetChar
    Select Case b0
      Case "M"
        GetChar
        Select Case b0
          Case "n"
            Gosub GetNunber
            SerTxd( "Mn=", #w1, CR, LF )
          Case "s"
            Gosub GetNunber
            SerTxd( "Ms=", #w1, CR, LF )
          Case "e"
            Gosub GetNunber
            SerTxd( "Me=", #w1, CR, LF )
          Case "w"
            Gosub GetNunber
            SerTxd( "Mw=", #w1, CR, LF )
        End Select
      Case "Q"
        Select Case b0
          Case "n"
            Gosub GetNunber
            SerTxd( "Qn=", #w1, CR, LF )
          Case "s"
            Gosub GetNunber
            SerTxd( "Qs=", #w1, CR, LF )
          Case "e"
            Gosub GetNunber
            SerTxd( "Qe=", #w1, CR, LF )
          Case "w"
            Gosub GetNunber
            SerTxd( "Qw=", #w1, CR, LF )
        End Select
    End Select
  Loop

GetChar:
  Do : Loop Until ptr <> hSerPtr
  b0 = @ptrInc
  SerTxd( b0 )
  Return

GetNumber:
  w1 = 0
  Gosub GetChar
  Do While b0 >= "0" And b0 <= "9"
    w1 = w1 * 10 + b0 - "0"
    Gosub GetChar
  Loop
  SerTxd( CR, LF )
  Return

 

[alistairsam]

Thanks hippy
I will try it out, will take me a while to understand it
The # is just the delimiter, there are no numbers.
#:Mn# move north
#:Qn# quit moving north
#:Qs#. Quit moving south
#:Mw# move west

 

[Goeytex]

Hippy,

Your code works good.

However it should be noted that it will only work reliably at a max 2400 baud with the Processor set to M16.
And max baud of 4800 with the Processor set to M32.

For example, I got errors at 2400 baud at the default 20X2 clock of M8 receiving more than 4 sequential bytes.

Good settings for the 20X2 might be:

Setfreg M16 / Hsersetup B2400_16
Setfreg M32 / Hsersetup B2400_32
Setfreg M32 / Hsersetup B4800_32
Setfreg M64 / Hsersetup B9600_64 (PE Terminal may not support sertxd at 64mhz)

 

[hippy]

Terminal will support SERTXD at 64MHz but you need an AXE027 or a download cable which supports 76800 baud.

As the # aren#t numbers you can have simpler code ...

MainLoop:
  HSerSetup ...
  Do
    Do 
      Gosub GetChar
    Loop Until b0 = ":"
    Gosub GetChar
    Select Case b0
      Case "M"
        GetChar
        Select Case b0
          Case "n" : SerTxd( CR, LF, "Got Mn", CR, LF )
          Case "s" : SerTxd( CR, LF, "Got Ms", CR, LF )
          Case "e" : SerTxd( CR, LF, "Got Me", CR, LF )
          Case "w" : SerTxd( CR, LF, "Got Mw", CR, LF )
        End Select
      Case "Q"
        Select Case b0
          Case "n" : SerTxd( CR, LF, "Got Qn", CR, LF )
          Case "s" : SerTxd( CR, LF, "Got Qs", CR, LF )
          Case "e" : SerTxd( CR, LF, "Got Qe", CR, LF )
          Case "w" : SerTxd( CR, LF, "Got Qw", CR, LF )
        End Select
    End Select
  Loop

GetChar:
  Do : Loop Until ptr <> hSerPtr
  b0 = @ptrInc
  SerTxd( b0 )
  Return

Part of the problem can be that incoming serial clashes with what the PICAXE is doing and that will get potentially worse as baud rates increase and bytes turn up more frequently. It may be that the SERTXD themselves affect the maximum data rate so when they are eventually removed things may be better.

It may also be worth adding pauses to ensure when data turns up there's a delay so further bytes turn up while the PICAXE isn't doing anything ...

GetChar:
  Do 
    Do While hSerFlag <> 0 
      hSerFlag = 0
      Pause 10
     Loop
  Loop Until ptr <> hSerPtr
  b0 = @ptrInc
  SerTxd( b0 )
  Return

You may have to experiment to find what's optimal.

 

[Goeytex]

Here is some code I did a while back when testing hserin for receiving RF packets and should work here as well.

It waits for data then goes to the interrupt routine where is can be processed one of two ways( or both). Either print the data from SP memory direct to the terminal ....Or put scratchpad data into variables starting at B10 and then display the variables on the screen. Works at any speed or baud rate and with variable data packet lengths. For 28X2 some lines will need to be changed.

#picaxe 20X2
#no_table
#com 2
#terminal 9600
pause 500 [COLOR=#008000]'Let Terminal Open[/COLOR]

Symbol LEN = B1

INIT:
setfreq m8

setintflags %00100000,%00100000  [COLOR="#008000"]'interrupt on hserin  [/COLOR] 

MainLoop:
 hsersetup b9600_8,1 
 
 do 
 pause 1000 
 loop  [COLOR="#008000"]'waiting for data[/COLOR]

Interrupt: 
pause 30          [COLOR=#008000]'let all data arrive in SP memory ... increase or decrease as needed[/COLOR] 

'=========================

gosub Process_data      [COLOR=#008000]'Pick one or both[/COLOR]
;gosub Process_data1   [COLOR=#008000]'Rem out one or the other[/COLOR]

'========================

Cleanup:
flags = 0
hserptr = 0
setintflags %00100000,$00100000
return

Process_Data: [COLOR="#008000"]'Get data from scratchpad and print to terminal [/COLOR]
LEN = hserptr -1  
sertxd ("Scratchpad Data",cr,lf)
for ptr = 0 to LEN 
sertxd (@ptr)
next
sertxd (cr,lf,cr,lf)
return [COLOR="#008000"]'to interrupt sub[/COLOR]

Process_Data1: [COLOR="#008000"]'Put SP Data into Variables starting at B10[/COLOR]

len = hserptr -1   [COLOR="#008000"]'Where is last byte ? [/COLOR]
bptr = 10           [COLOR="#008000"]'Start at B10  [/COLOR]

for ptr = 0 to len
  get ptr,@bptrinc  [COLOR="#008000"] 'Get data from scratchpad and put into SFR[/COLOR]
next

len = bptr - 1   [COLOR="#008000"] 'Where is last byte in SFR ? [/COLOR]
Sertxd ("Var Data b10 to b",#len,cr,lf)

for  bptr = 10 to len
    sertxd (@bptr)   [COLOR="#008000"] 'Send B10 - Bx to Terminal[/COLOR]
next

sertxd (cr,lf,cr,lf) 
return [COLOR="#008000"] 'to interrupt sub[/COLOR]

 

[alistairsam]

Thanks Goeytex, will try your code as well.

Hippy, I tried your last code at 8Mhz and 32Mhz, it displays the "Got Mn" but not the "Qn" which is the quit.
the quit command is sent around half a second after the M, but two quits are sent in sequence. I just need to wait for any "Q" and then I can quit moving.

here is the terminal output

#:Mn
Got Mn
##:Qn##:Qs##:Ms
Got Ms
##:Qn##:Qs##:Me
Got Me
##:Qw##:Qe##:Mw
Got Mw
##:Qw##:Qe#

I can't simulate the code in the programming editor as it says background receive cannot be simulated at the moment.

 

[alistairsam]

there was a "Gosub getchar" line missing below Case "Q", I added that and it works with a "got" for every q or m command.
output below

#:Mn
Got Mn
##:Qn
Got Qn
##:Qs
Got Qs
##:Mw
Got Mw
##:Qw
Got Qw
##:Qe
Got Qe

I tried the code at 32Mhz, and as you expected, I was getting garbled characters at the end. so tried the alternate getchar routine with the pause at 32Mhz, and that works very well.
I will stick to 32Mhz as I'll need to update the variable using I2C as quickly as possible to effect sufficient change in the motor speed.
Thanks so much, it's a major breakthrough for me.
autoguiding is the difference between being able to expose for 30 seconds and 15 minutes without any star trail that is seen even in a $10,000 telescope when run unguided.

 

[hippy]

Hippy, I tried your last code at 8Mhz and 32Mhz, it displays the "Got Mn" but not the "Qn" which is the quit.

Ah yes, an obvious bug staring us in the face there; a victim of careless cut and paste

Have a look at the "M" handling which works and the "Q" handling which doesn't. Can you see the difference ? Better still; can you work out why fixing the bug will ( should anyhow ) make it work ?

Added : And you beat me to it while I was posting. Well done, and I mean that sincerely.

 

[alistairsam]

thanks hippy, but can you pls explain how the ptrinc works in your code?
i know when a byte is received in the hserin pin, the hserin pointer is incremented and gets incremented for each byte. and this is copied to the scratchpad from location 0. but since the M and Q characters are the fourth, you'd have to increment the pointer by 4 and read that.
does each run of the getchar routine increment pointer value in b0 by 1?
also, how is the pointer reset to 0? or is it not?
other thing is a CR,LF is added immediately after the n,s,e,w. but there is a # that follows. how do you insert the CR,LF after the #? add another gosub getchar loop?

 

[hippy]

With the code as I have it the scratchpad receive buffer is considered as a circular buffer so 'hSerPtr' simply works it way around it overwriting older data with new.

The 'ptr' variable simply plays catch-up with 'GetChar:' checking 'ptr' is behind 'hSerPtr' and a character available, and when there is getting the character and then pointing to where the next would be. '@ptrinc' gets what 'ptr' points to and then adds 1 to it.

Both 'ptr' and 'hSerPtr' auto-wrapround from the last location of scratchpad to the first, which is what allows this circular buffer view of things to work. There's no need to explicitly set either to 0 as that just happens. There's no real start nor end with a circular buffer.

You can think of a circular buffer as a broken baggage carousel which doesn't rotate. One person (hSerPtr) puts incoming bags on it and moves along to the next empty slot, another person (ptr) checks they are lagging behind the first and if so takes a bag, does something with that, moves along. The bags in this case have characters stuck to them and after the 'ptr' person pulls them out the office staff look at the order of bag characters to work out the commands sent to them.

The important things are that all bags taken off are in the same order as put on, and the circular buffer handles any delay in taking them off and as long as the buffer isn't allowed to fill completely nothing will be lost.

The office staff receiving incoming bags have worked out that it's not necessary to know position of characters but the command will always be the two which follow a ':' so they throw all bags away unless ':' then from the next two determine what to do. Then start discarding again until another ':'. In other protocols it may be necessary to count bags but here it's not necessary.

You are right; to delay output of the "Got Mn" messages until after reading the "#" which follows, add another 'Gosub GetChar' before each SERTXD.