PSC firmware addition

QuadrtrFlyr

I have a questions with regards to the Parallax Servo Controller firmware. I am communicating over a serial line and was wondering if the TX and RX lines are completely separate of each other? I believe they are but I ask this because I am trying to run the following PUB method, which sends the current counter value automatically, to my microcoontroller without me needing to query it.

PUB TimeRequest  | r, n       
    repeat
       SendDataString(string("1.0"))
       chksum := "1" + "." + "0" 
       value := cnt
       'COMport1.dec(value)
       repeat n from 0 to 3
          'SendDataString(string(" "))
          SendDataByte(value.byte[n])
          'COMport1.hex(value.byte[n],2) 
          chksum += value.byte[n]
       repeat r from 0 to 1
          SendDataByte(chksum.byte[r])  
          'COMport1.str(string(" _ "))
          'COMport1.hex(chksum.byte[r],2)
       chksum := 0

I have launched this code into a new cog via:

VAR

long    TimeStack[20]

PUB  PSC_Propeller_firmware|Edata,Tdata 
Cognew(TimeRequest, @TimeStack)

However now when I try to send typical commands to the PSC such as Set Servo Position commands, I get no response from the motors. Nevertheless the RX line on the PSC is not being used so shouldn't the motors be running? Also does the baud rate of 38400 have any effect on this counter being transmitted effectively?

Thank you,
Robert

Mike G

The actual PSC hardware is half duplex.

It's not clear, to me, what you're asking or how you have the devices setup. A schematic would go a long way.

QuadrtrFlyr

Oh I see, so half duplex devices let you send and receive, but only one-way at a time. That is not good... I am basically controlling 4 motors with the parallax servo controller by sending serial linux commands from a PC. However my linux PC (a raspberry pi) does not have an on-board clock accurate enough/accessible like the parallax propeller counter so while controlling the motors I am trying to receive this propeller counter value. So in essence I am trying to read this counter on the raspberry pi without interfering in the motor control. Is there any way to mix in that TimeRequest method I created above into the current firmware without affecting the control of the motors? I thought running it in a separate cog would help. If you need any more information please let me know. There is not much I can do about a schematic. It is just connected via a USB cable, all software. Is there any way to make it Full Duplex?

Much Appreciated!

Mike G

Someone with better chops will have to help you. What I see is a COG that pretty much hammers the serial port. I imagine the serial port driver is pretty busy just sending data. Adding a pause might help - give the driver a breath. How does the CNT come into play? By the time the RPi gets and processes CNT those ticks are far gone. How are you planning to use CNT in the RPi.

QuadrtrFlyr

Mike G wrote: »

Someone with better chops will have to help you. What I see is a COG that pretty much hammers the serial port. I imagine the serial port driver is pretty busy just sending data. Adding a pause might help - give the driver a breath. How does the CNT come into play? By the time the RPi gets and processes CNT those ticks are far gone. How are you planning to use CNT in the RPi.

I was thinking of adding a pause but was hoping not too because it interferes with the control of the motors.. Maybe someone has some other ideas? Eventhough the CNT ticks that get sent to the raspberry pi might not be exactly in sync with that of the propellers, they are still valuable because, offset as they may be, they are still coming in at a consistent rate. I plan on taking whatever count value comes in, running my entire code, taking a new count value, finding the change in the two values, dividing by clkfreq, and then finally using the change in time in my PID loop for the integral portion.

Mike G

First, the Prop PSC has two virtual serial port drivers; one for the USB and one for the 3 pin plug. The 3 pin plug is half duplex the USB connection is full duplex.

I'm still not following the CNT logic. CNT is a propeller register that increments on each clock tick. It's common to use CNT for deterministic timing and measuring stuff like frequency within the Prop.

As stated in post #5, CNT is sent at a constant rate to the RPi. If CNT is sent at a constant rate and CNT itself increments at a constant rate wouldn't the delta always be the same? I believe you are actually measuring serial port connection and processing parameters.

The PSC does not read the current position of the motors. The PSC reads it's internal register. The motor could be off but the PSC will return a value. You need encoders to complete the feedback loop.

QuadrtrFlyr

First, the Prop PSC has two virtual serial port drivers; one for the USB and one for the 3 pin plug. The 3 pin plug is half duplex the USB connection is full duplex.

I am using a USB connection so doesn't that mean that if i send 4 servo set position commands to the propeller continuously from the Raspberrry Pi, am I not supposed to be able to also receive continuous updates from the PUB TimeRequest methods I created above simultaneously? However when I do test it out, the servos do not move..

I'm still not following the CNT logic. CNT is a propeller register that increments on each clock tick. It's common to use CNT for deterministic timing and measuring stuff like frequency within the Prop.
As stated in post #5, CNT is sent at a constant rate to the RPi. If CNT is sent at a constant rate and CNT itself increments at a constant rate wouldn't the delta always be the same? I believe you are actually measuring serial port connection and processing parameters.

Although that is true, let me try to provide a counterargument to maybe correct my logic. You have brought up some interesting points. Delta would always be the very close to the same value, but not the same. I have done some experimental tests to prove that this CNT variable is valuable (without the position commands being sent). For example: I delayed the raspberry pi C code by 8ms and after solving for the actual loop time of the code using the change in CNT, I found that the code was executing at an average of approximately 8.125 m, sometimes even with larger time intervals like 16ms. This proved to me that the CNT timing is doing work and accurate enough to use in my actual code. Delta would always be close to the same, but if I don't get it from the CNT value, then I don't know what this change in time value is at all.

The PSC does not read the current position of the motors. The PSC reads it's internal register. The motor could be off but the PSC will return a value. You need encoders to complete the feedback loop.

In my setup I have an IMU to complete the feedback loop.

Mike G

I am using a USB connection so doesn't that mean that if i send 4 servo set position commands to the propeller continuously from the Raspberrry Pi, am I not supposed to be able to also receive continuous updates from the PUB TimeRequest methods I created above simultaneously? However when I do test it out, the servos do not move..

You're pushing the serial port library beyond its capabilities.

Although that is true, let me try to provide a counterargument to maybe correct my logic. You have brought up some interesting points. Delta would always be the very close to the same value, but not the same. I have done some experimental tests to prove that this CNT variable is valuable (without the position commands being sent). For example: I delayed the raspberry pi C code by 8ms and after solving for the actual loop time of the code using the change in CNT, I found that the code was executing at an average of approximately 8.125 m, sometimes even with larger time intervals like 16ms. This proved to me that the CNT timing is doing work and accurate enough to use in my actual code. Delta would always be close to the same, but if I don't get it from the CNT value, then I don't know what this change in time value is at all.

I still don't get the CNT concept. Why not send one byte every millisecond or faction of a millisecond? Every time a byte arrives increment a variable. That would really cut down the overhead and free up the serial library.

The Propeller has set and forget counters which can act as a clock signal. If the RPi can detect a rising edge that would be even easier.