using rs232 cog 2 to talk back and forth from 2 mini propellers then cog 1 as main display
harryimrctech
Posts: 3
Hello all ,
I have 2 mini props wired together and cant seem to get them to talk to each other . I am able to get one to sent a string out but can't seem to get the other to read it and then transfer it to my buffer/ array i call corebuss input string.
I am writing in c/c++ . I am using the fdserial object. Can't seem to find the command that says read the string and put it here. Saw rx.char. do i have to use that and receive 1 byte at a time and put it into my array or is there a command that receives the entire string sent and puts it in my buffer ie array.
Shorely there code written that does this .Where can i find it?
I am also looking to use 1 cog 2 as a port for conversation with other mini . The at the same time use cog 1 to talk with the main display port set up in the programmer believe is pin 31,32
I would like both these ports to be dumped into this array i mention earlier so i could print on main display on one mini and have it show up in the second mini.
Could anyone please help??
Harry
Comments
Because that function doesn't exist. The RX functions available in fdserial are:
Not a problem; you could write a simple function that receives your string -- and this let's you decide what character to use as the string terminator. I did something similar in Spin for a Nextion HMI that I'm using in a couple projects. I can have the display send a message that looks like this: "STATUS=1." The string receiver knows that the message is done when it sees a period. The parser knows that the element and the value are separated by "=". Easy-peasy and works well.
Hi jon,
Thanks for the reply. I appreciate your help. So I too have come up with a packet/parser routine that decodes the packets sent from another unit. If I read you correct I should use an approach of collecting each byte, using the rxcheck ,and building my string. After it is received and terminated by a standard null then send it thru my parsing routine . Is that what you are suggesting?
Are there functions such as strcpy that exist for use with the propeller? I have not be able to locate any library that is included with the propeller documentation that addresses sting commands.
One other thing is it your opinion that the the propeller is 8 distinct processors or is it similar to a DMA function of a standard processor. One reason I selected the propeller is that a wanted a device that can do more that 1 thing at a time asyscronislty like a separate processor for each task. From what I gather from the examples is that it can only do simple thing like blink light independently per cog. Can each cog launched act as a separate processor that can loop and do its own thing ? I was also not very clear in the documentation on how to share data collected by each cog. What is your opinion ?
I said previously that I was using RS - 232 but I am technically just using a TTL direct type approach . I have 4 short runs of wires between each mini appropriated as communications between them. If there is a more efficient way of the mini's communicating please let me know.
Thank you again for your response.
Harry
PS Great day here in florida hope you have the same there!!!
I'm not much of C programmer -- I have been using Spin since before the P1 was released (I worked for Parallax back then). You may need to spend a bit more time in the docs.
It's not my opinion -- it's a fact. Each processor runs on its own, only holding if needing to exchange information with the hub.
Thankfully, you're mistaken, and I can prove it with the work I've done for myself and my clients.
Most of my work is connected to entertainment in one form another -- but let me share some of [commercial] things I've done with the P1:
I understood -- you're doing asynchronous serial. One of the great things about the Propeller's approach is that UARTs are synthesized in a cog. I've never needed one, but there are others that have written drivers that run multiple serial connections using a single cog.
You only need ground, TX, and RX on each side. Of course, you understand that TX on one side connects to RX on the other. If you want to prevent possible programming accident, put a 3.3K resistor between TX and RX.
Serial is pretty easy -- you just have to decide on the rules you're going to live by. ATM, I am working with my friend John at JonyJib to create protocol that we'll use between his newest master controller and remote control head. In this case we use RS-485, so it's still serial (half-duplex).
This is my opinion: Nobody cares what language you use if the device does what it's supposed to do and does it well. I like Spin because it is a small, lean, easy-to-use language that was designed specifically for the Propeller architecture hence allows the programmer to exploit that architecture easily. Yes, you can program in C if you choose. I don't. I have never had a client upset that I'm not using C -- in fact, one customer has learned enough about Spin that he can make small tweaks without needing my assistance. If you decide to try Spin I have lots of libraries I can share with you.
You can see some of my artistic projects (many for Hollywood legend, Steve Wang) using the P1 here:
-- https://www.pinterest.com/jonmcphalen/techno-art/
I've given many Zoom presentations on Propeller programing for Parallax -- you can find them on their YouTube channel. The focus is on the P2, but most applies to the P1 as well. Give yourself time to experiment; it will pay off.
Cheers from Hollywood (CA)!