Shop OBEX P1 Docs P2 Docs Learn Events
3 way communication - Plz help!!!!!!!! — Parallax Forums

3 way communication - Plz help!!!!!!!!

computer guycomputer guy Posts: 1,113
edited 2007-10-12 20:35 in Propeller 1
I am trying to get my propeller to talk to my BS2 and my BS2 to talk to my computer (VB2005) Program.
However I am having difficulty synchronizing the devices.
How would I get them to talk and listen at the right times.

Thank you smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out my robot using the propeller robot.tmcp.com.au
If you offer cheap PCB fabrication, perl programming or any other helpful services please email me at.
anthonybmyatt@yahoo.com.au

Post Edited (computer guy) : 10/10/2007 1:24:41 AM GMT

Comments

  • LeonLeon Posts: 7,620
    edited 2007-10-08 13:36
    FIFO buffers and some sort of flow control?

    Leon

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Amateur radio callsign: G1HSM
    Suzuki SV1000S motorcycle
  • Mike GreenMike Green Posts: 23,101
    edited 2007-10-08 14:55
    1) What kind of communication are you using? A serial port?

    2) Usually this kind of thing gets easier when one device serves as a master and the others are slaves. The master provides the control to keep things in sync.

    3) If you don't want to use a master / slave(s) setup, you can use a multidrop network setup where all of the transmit lines use an open collector/drain type of connection and the receive lines and transmit lines are connected together ... a party line. Any party can transmit at the same time ... there has to be error control and some rules about when to try again if your transmission fails because someone else transmitted at the same time. The Ethernet uses this type of protocol. A lot of the algorithms were developed as part of the Aloha-net project which was one of the first wireless network implementations.
  • computer guycomputer guy Posts: 1,113
    edited 2007-10-08 20:44
    I would be happy to use the BS2 as a master as it will be in the middle.
    I am using the USB port on the BS2 (serial) and am planning on using serial between the BS2 and Prop.
    I don't know anything about serial communication, so an example with code snippets would probably help.

    Thank you smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Check out my robot using the propeller robot.tmcp.com.au
    If you offer cheap PCB fabrication, perl programming or any other helpful services please email me at.
    anthonybmyatt@yahoo.com.au
  • computer guycomputer guy Posts: 1,113
    edited 2007-10-09 22:43
    How would I use the start bit and stop bit to control flow?


    What I want to do is the computer says hello to the BS2.
    The BS2 says hello to the prop.
    The prop tells the BS2 lots of info.
    The BS2 relays this to the computer with some of its own info.
    The BS2 then every 2 seconds sends info to the Computer with any info it may have gotten from the Prop during that 2 second gap.

    They are wired up like so:
    
        Serial             Serial to USB
Prop ---------->BS2 -------------------------->PC



    Thank you smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Check out my robot using the propeller robot.tmcp.com.au
    If you offer cheap PCB fabrication, perl programming or any other helpful services please email me at.
    anthonybmyatt@yahoo.com.au

    Post Edited (computer guy) : 10/10/2007 1:08:04 AM GMT
  • computer guycomputer guy Posts: 1,113
    edited 2007-10-10 13:37
    Anyone. Plz, smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Check out my robot using the propeller RECONAUTOR
  • deSilvadeSilva Posts: 2,967
    edited 2007-10-10 13:53
    Just carry on...

    How many COGs do you expect to use? Why?
    You have to allocate time slots for the communications... Di they overlap? Do they have to?
    A slave is a listener! Carefully design, who the listeners are...
  • Ken PetersonKen Peterson Posts: 806
    edited 2007-10-10 17:11
    First of all, if you don't know anything about serial communication, pull up the UART article in wikipedia.com and browse through it. Normally you only need RX and TX and no flow control. The FullDupliexSerial object in the object exchange will queue the incoming data for you and all you need to do is read the bytes from the queue. It's pretty straight-forward to configure the object.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    The more I know, the more I know I don't know.· Is this what they call Wisdom?
  • computer guycomputer guy Posts: 1,113
    edited 2007-10-12 00:16
    Ken
    I have read that article, it was the first article I read after not getting any responses to this forum thread.
    So I basically just have to do a trial and error process. cry.gif

    At the moment I can get the BS2 to send Info to the PC and get the PC to display 50% of this.
    The buffer in FullDuplexSerial would be nice, however that probably won't ever be used as the Prop very rarely recieves.

    The reason I have a BS2 in the middle is because I am using the BS2 to monitor battery levels, as I have only 2 pins left on the propeller.
    So I have the propeller sending debug information to the BS2, the bs2 than gets this and send it with the battery levels from it to the PC.

    
     Started ->              Battery Levels ->
     Beep ->                 Started ->
     Servos Set ->           Beep ->
                             Servos Set ->
Prop ----------------------->BS2 ---------------------->PC




    Thank you smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Check out my robot using the propeller RECONAUTOR
  • Ken PetersonKen Peterson Posts: 806
    edited 2007-10-12 02:37
    Start designing your protocol by specifying a starting and ending byte for your message. Then your PC can send a series of bytes and the BS2 will know it's valid if it starts and ends with the right bytes. You might want to try fixed-length messages for simplicity. Say for instance, you always send 100 bytes beginning with $55 and ending with $EF. Then you listen for input and when you get $55, read in 100 bytes and check for $EF in the last byte. If all is well, you just received a valid packet. The second byte can indicate the message type. $01 is "hello", $02 is "battery level" etc. If your environment causes transmission errors, you can add a checksum scheme if you need it.

    I guess with the type of data you're sending, maybe 100 byte messages are too long. Pick any length that meets your needs.

    When your BS2 gets a message from the PC that means "send data" it would forward the same packet to the propeller. Whatever the propeller sends to the BS2 would just get forwarded to the PC (after it's received in it's entirety and checked for validity). You would need to set up transmit and receive buffers for holding your packets while you evaluate the ones you receive or compile the ones you will send.

    Is any of this helpful?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    The more I know, the more I know I don't know.· Is this what they call Wisdom?
  • computer guycomputer guy Posts: 1,113
    edited 2007-10-12 02:59
    I get the concept.
    However I have no idea how to implement it.
    The data I am sending is:

    Name: 10 char
    Ver: 3 char
    Date: 8 char
    Description: 100 to 500 char
    bat1 level: 2 char
    bat2 level: 2 char
    general debug: 4 to 20 char

    Thank you smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Check out my robot using the propeller RECONAUTOR
  • Ken PetersonKen Peterson Posts: 806
    edited 2007-10-12 04:00
    Please describe in more detail where you are stuck. It seems to me to be a matter of constructing the message based on your example and sending it byte by byte over the serial line. if you have variable length packets then you need to include length indicators in your message.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    The more I know, the more I know I don't know.· Is this what they call Wisdom?
  • GadgetmanGadgetman Posts: 2,436
    edited 2007-10-12 08:13
    You're pushing a message that may be over 500 chars from the BS2 to the PC?

    The FIRST thing you need to consider is packet length...
    I assume you're using 9600bps?

    If so, that would IDEALLY take half a second, or so.
    In that time the BS2 can't do anything else as it doesn't have a RX or TX buffer.

    Older transfer protocols often used 128Byte packets because of problems with line noise and speed.

    It may be a good idea to define several 'query codes':
    PC sends $FF:
    BS2 sends a general 'status package' with $FF Version, date, battery levels, $CRC
    PC sends $EE$00
    BS2 sends $EE$00 and first 32Bytes of description. + $CRC
    PC sends $EE$01 to get next 32Bytes and BS2 responds with $EE$01 and 32Bytes... and so on...
    When the remaining description is shorter than 32Bytes, it responds with $EE$FF and sends the block, padded with spaces at the end.

    If you also use Hardware handshaking, you should be able to avoid the BS2 losing any comms from the PC.

    Of course, if you used another Propeller you won't have to fight with the BS2's singletasking/no buffer problem....

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
  • Desy2820Desy2820 Posts: 138
    edited 2007-10-12 09:01
    I don't have any Propeller experience and am not an expert on the Stamp, but I'd be tempted to change this around.· Have the Propeller query the Stamp every so often, then the Propeller sends the combined data to the PC when requested.· The BS2 is limited in·received string size, receive speeds·and is single-tasking, eg, it can miss the start of the PC's send data request·if it's busy.

    Stamp --> Propeller
    Propeller--> PC

    Maybe borrow/emulate the appmod protocol?· The stamp waits to see·a "!BAT"· command before sending it's data.· The Propeller or PC sends "!BAT", then the Stamp sends the data.· If you wanted to talk to the Propellor, the Stamp will ignore anything that dosen't start with "!BAT".· In the protocol, the "!" is not really a critical·bit, it's designed more to sychronize the transmitter/reciever.·

    Also,·you could do something similiar for the Propeller, like "!RBT"· for robot, then the Propeller sends it's data to the PC.

    The Propeller can have a buffer and with a dedicated (or semi-dedicated) cog, won't miss much data.· Also, you may be able to increase your send/recive speeds to/from the PC.· If the Stamp misses the query, you can wait for a little bit and try again, while·the Propeller could send the last good data it has to the PC, thus not holding up your application.

    I hope this helped!
  • computer guycomputer guy Posts: 1,113
    edited 2007-10-12 09:31
    Ok I think I am getting somewhere now.
    So rather than just sending and receiving I should tell the sender that I am ready to receive first.

    Thank you smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Check out my robot using the propeller RECONAUTOR
  • Ken PetersonKen Peterson Posts: 806
    edited 2007-10-12 13:57
    @CG: Yes, in away. More like commanding it to send. The PC would command the prop to send, which would in turn command the BS2 to send (in Desy's example)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


    The more I know, the more I know I don't know.· Is this what they call Wisdom?
  • computer guycomputer guy Posts: 1,113
    edited 2007-10-12 20:35
    Ok, thank you for confirming.

    Thank you smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Check out my robot using the propeller RECONAUTOR
Sign In or Register to comment.