The best example I seem to have uses the regular serial output to talk to LabView on a PC (instead of serial terminal), the dogbot.c file in thread from post #10 here.
You can use the same idea to talk between propellers though.
Looks like I used "gets()" to wait for serial input and then "sscanf()" to parse the message into a string and a digital number.
So, not sending data as binary here but as plain text.
Not really using any frame start or end here and you don't really have to with a simple USB connection to PC because it's usually perfect data.
But, you'd need things like that if there's a chance of corrupted data or the two propellers not being in sync.
Can add CRC if really worried about bad data...
I also rewrote FDSerial for llvm (currently on a separate branch), so the file-based interface works there. For binary data, however, you’d just use the library functions _uart_putc() and _uart_getc() and write your own packeting system on top of it.
Telescope Driver would be easier to understand if the actions where made individual functions.
In the While loop of the Main function, after getting the switch inputs, the program transmits the Mode as a Decimal, the Direction as a character, and then a NewLine or CR character, before pausing and looping again.
In the While of the Main of Orion, the Mode and Direction are retrieved which a Mode of 0 meaning no movement.
Mode is converted back to a number by subtracting out the ASCII value of the number Zero.
One big problem is the Switch statement which does not cancel out the other directions.
If going East/West then North/South need to be canceled, and vice versa when going North/South.
Normally LEDs and Switches are Active-High meaning they are On when a high voltage is connected, but they can be Active-Low.
Active-Low is good when something shouldn't happen such as a part contact switch that shows a part is in place.
Currently the Orion program is treating the Autoguider switches as Active-Low or active/working when their value is low.
Incorrect on the mode being zero means no movement. Mode is used to reference the speed array which always starts at zero.
This way the array could be changed to allow for different movement values. Up/down might be faster than left/right.
Since the direction is controlled by the square_wave function it can only effect one pin at a time and thus only move in one direction. Its only allowed to move in one direction for a half of a second and then stops.
The motors are controlled by an A4988 type stepper chip that powers the motors at all times to keep it in one place. A step pulse is used to move the motors in one direction one movement at a time. It makes no difference where the pins are left since they only respond to change.
One issue is that the motor driver is waiting one half second but the hand control is waiting at 50 milliseconds. The motor driver unit could be over driven by step movements since it is buffering the connection. The array storing incoming commands is only 8 long and could be over run by values.
@Rayman said:
The best example I seem to have uses the regular serial output to talk to LabView on a PC (instead of serial terminal), the dogbot.c file in thread from post #10 here.
You can use the same idea to talk between propellers though.
Looks like I used "gets()" to wait for serial input and then "sscanf()" to parse the message into a string and a digital number.
So, not sending data as binary here but as plain text.
Not really using any frame start or end here and you don't really have to with a simple USB connection to PC because it's usually perfect data.
But, you'd need things like that if there's a chance of corrupted data or the two propellers not being in sync.
Can add CRC if really worried about bad data...
Maybe you could take some time and explain this concept in more detail , I got lost just looking at it , I am a rank amature at this stuff.
Telescope Driver would be easier to understand if the actions where made individual functions.
In the While loop of the Main function, after getting the switch inputs, the program transmits the Mode as a Decimal, the Direction as a character, and then a NewLine or CR character, before pausing and looping again.
In the While of the Main of Orion, the Mode and Direction are retrieved which a Mode of 0 meaning no movement.
Mode is converted back to a number by subtracting out the ASCII value of the number Zero.
One big problem is the Switch statement which does not cancel out the other directions.
If going East/West then North/South need to be canceled, and vice versa when going North/South.
Normally LEDs and Switches are Active-High meaning they are On when a high voltage is connected, but they can be Active-Low.
Active-Low is good when something shouldn't happen such as a part contact switch that shows a part is in place.
Currently the Orion program is treating the Autoguider switches as Active-Low or active/working when their value is low.
Someone done changed the original wording and I dont understand what he wrote but setting i == 0 does present a problem since when the switch( opto-isolators) is depressed a 3.3 volt potential is applied to the io pin.
actually, the way this is supposed to function is when any button is depressed whether it is on the handbox or the guider, the motor connected to the depressed switch is supposed to run as long as the switch is depressed and stop when it is released. ( ==0)
Sometimes make up a protocol like a few special characters to indicate start of a transmission.
I just use 0xAA (10101010), followed by a slave-address, a few data-bytes and a checksum.
Currently have Flexbasic+SmartSerial talking to a string of RPi Picos (multi-drop TTL UART with a schottky diode) @ 460KBaud; worked instantly and hasn't missed a beat
That's so that the other nodes don't interfere with the others as they leave the TX as plus 3.3 or 5 volts.
Mike
Schottky actually.
Yeah, although it is a strict command response arrangement, it just feels better to provide a bit of protection. The devices are close proximity and it seems silly to use a differential transceiver.
OK "rayman" I just looked at your FlexProp C talking to labview and I do not understand any of this stuff. My programs are already written in Propeller C and I'll stick with it. My immediate problem is in the serial trans. I just need the command to apply the mode value and direction to the output pins.
But, they are using 5V Zener diodes. Looks to me like just a regular diode would work. Not enough voltage here to get Zener breakdown...
I remember looking-up the differences between regular/Schottky and apart from the lower volt-drop of the Schottky, I figured it would be better to go with its faster switching time. IIRC, even low-power Schottky is something like 14ns.
Comments
Serial is used all over the place, but it may not be called serial. Baud rate might get you more hits.
Anyway, here is a tutorial on the learn site of Parallax that talks about different protocols and some exercises:
propeller-c-simple-protocols
These devices require serial to work:
parallax-wx-esp8266-wifi-module
parallax-2-x-16-serial-lcd-with-piezo-speaker-backlit-blue
The main thing with serial is that the TX pin goes to the RX pin on the other device and they both need the same baud rate.
Mike
I need to figure that out too.
With FlexProp C, you can just use one the .Spin2 serial drivers.
No idea how to do that with LLVM/Clang yet...
@Rayman ,
No need to use spin code. Have written serial drivers for both flexprop and llvm.
With flexprop you can use the serial driver with fprintf so you can do formatted output to devices if need be.
With LLVM you can do stdin, stdout.
Open a new subject with examples of what you want to do.
Mike
Oh, does "Propeller C" refer to something specific? Is that SimpleIDE or GCC?
@Rayman ,
SimpleIDE is built on top of GCC and is the C compiler for P1 projects.
Mike
I've used Catalina for P1 projects in the past.
Recently used FlexProp C for P1.
I'm just wondering if "Propeller C" means some specific tool...
All of the examples work fine for printing to a terminal or LCD or whatever but I am trying to send binary date to be read and acted upon.
I usually just send the data a byte at a time as if it were text.
Sometimes make up a protocol like a few special characters to indicate start of a transmission.
You may have to typecast data location as char pointer or something like that
I had flexprop C talking to labview on a pc here:
https://forums.parallax.com/discussion/173513/labview-2020-nxg-connection-over-serial-port-to-flexprop-c-code
Might or might not help
@bbrien byte stuffing is quite common here is a link to an introduction.
https://www.tutorialspoint.com/what-is-byte-stuffing-in-computer-networks#:~:text=Byte Stuffing Mechanism&text=In byte stuffing, a special,byte is stuffed before it.
The best example I seem to have uses the regular serial output to talk to LabView on a PC (instead of serial terminal), the dogbot.c file in thread from post #10 here.
You can use the same idea to talk between propellers though.
void Loop() { char s1[100] = "SA= 140"; gets(s); int d=100; sscanf(s,"%s %d", s1, &d); _waitms(5); printf("SA= %d\n", d); //printf("%s\n", s); servo.write(0, d); }Looks like I used "gets()" to wait for serial input and then "sscanf()" to parse the message into a string and a digital number.
So, not sending data as binary here but as plain text.
Not really using any frame start or end here and you don't really have to with a simple USB connection to PC because it's usually perfect data.
But, you'd need things like that if there's a chance of corrupted data or the two propellers not being in sync.
Can add CRC if really worried about bad data...
Have a pair of programs that seem to work as far as sending some bytes but the functions aren't to my liking .
I also rewrote FDSerial for llvm (currently on a separate branch), so the file-based interface works there. For binary data, however, you’d just use the library functions _uart_putc() and _uart_getc() and write your own packeting system on top of it.
bbrien,
Telescope Driver would be easier to understand if the actions where made individual functions.
In the While loop of the Main function, after getting the switch inputs, the program transmits the Mode as a Decimal, the Direction as a character, and then a NewLine or CR character, before pausing and looping again.
In the While of the Main of Orion, the Mode and Direction are retrieved which a Mode of 0 meaning no movement.
Mode is converted back to a number by subtracting out the ASCII value of the number Zero.
One big problem is the Switch statement which does not cancel out the other directions.
If going East/West then North/South need to be canceled, and vice versa when going North/South.
Normally LEDs and Switches are Active-High meaning they are On when a high voltage is connected, but they can be Active-Low.
Active-Low is good when something shouldn't happen such as a part contact switch that shows a part is in place.
Currently the Orion program is treating the Autoguider switches as Active-Low or active/working when their value is low.
@Genetix ,
Incorrect on the mode being zero means no movement. Mode is used to reference the speed array which always starts at zero.
This way the array could be changed to allow for different movement values. Up/down might be faster than left/right.
Since the direction is controlled by the square_wave function it can only effect one pin at a time and thus only move in one direction. Its only allowed to move in one direction for a half of a second and then stops.
The motors are controlled by an A4988 type stepper chip that powers the motors at all times to keep it in one place. A step pulse is used to move the motors in one direction one movement at a time. It makes no difference where the pins are left since they only respond to change.
One issue is that the motor driver is waiting one half second but the hand control is waiting at 50 milliseconds. The motor driver unit could be over driven by step movements since it is buffering the connection. The array storing incoming commands is only 8 long and could be over run by values.
Mike
Maybe you could take some time and explain this concept in more detail , I got lost just looking at it , I am a rank amature at this stuff.
Someone done changed the original wording and I dont understand what he wrote but setting i == 0 does present a problem since when the switch( opto-isolators) is depressed a 3.3 volt potential is applied to the io pin.
actually, the way this is supposed to function is when any button is depressed whether it is on the handbox or the guider, the motor connected to the depressed switch is supposed to run as long as the switch is depressed and stop when it is released. ( ==0)
I just use 0xAA (10101010), followed by a slave-address, a few data-bytes and a checksum.
Currently have Flexbasic+SmartSerial talking to a string of RPi Picos (multi-drop TTL UART with a schottky diode) @ 460KBaud; worked instantly and hasn't missed a beat
LOVE this stuff!
Craig
@Mickster What is the function of the zener diodes?
@Rayman ,
That's so that the other nodes don't interfere with the others as they leave the TX as plus 3.3 or 5 volts.
Mike
Schottky actually.
Yeah, although it is a strict command response arrangement, it just feels better to provide a bit of protection. The devices are close proximity and it seems silly to use a differential transceiver.
Craig
I see something similar here: https://electronics.stackexchange.com/questions/505910/multidrop-rs232-diode-selection-and-doubts
But, they are using 5V Zener diodes. Looks to me like just a regular diode would work. Not enough voltage here to get Zener breakdown...
OK "rayman" I just looked at your FlexProp C talking to labview and I do not understand any of this stuff. My programs are already written in Propeller C and I'll stick with it. My immediate problem is in the serial trans. I just need the command to apply the mode value and direction to the output pins.
Mickster ; What is SmartSerial and how does it differ from FDSerial.
I remember looking-up the differences between regular/Schottky and apart from the lower volt-drop of the Schottky, I figured it would be better to go with its faster switching time. IIRC, even low-power Schottky is something like 14ns.
Craig
I believe that SmartSerial is derived from FDSerial. In the FlexBasic doc's SmartSerial is intended for Prop-2 whereas FDSerial is Prop-1
Craig
Ok, Schottky makes more sense.
bbrien,
I create program constants whenever possible since it makes the program easier to understand and modify.
Notice the constants at the top of each of these programs:
https://learn.parallax.com/tutorials/language/propeller-c/propeller-c-simple-protocols/half-duplex-serial
https://learn.parallax.com/tutorials/language/propeller-c/propeller-c-simple-protocols/spi-example/bit-masks-better-code
https://learn.parallax.com/tutorials/language/propeller-c/propeller-c-simple-protocols/diy-i2c/more-data-types-and-devices
if (PushButton[Number] == Pressed) is easier to understand than if (i == 1).