Multiple Prop C UARTs on 1 cog

emiljt

I'm sorry ahead of time if this is a dumb question or I missed the answer elsewhere (I did try searching around for a couple of hours). I'm working on a project that uses the Parallax Flight Controller and it needs to communicate to several devices over serial, preferably in as few cogs as possible. Is there a way in C to create multiple serial ports on one cog?

I've read through the learn.parallax.com tutorials on it and understand how to use one serial port, but as far as I can tell the library uses one cog per serial port. I know there is a Spin object that can do multiple serial ports on one cog, but I'm trying to stay in C if at all possible. Any ideas or something I've missed?

Mike Green

Yes, there is a Spin object in the object exchange that can provide 4 serial ports using one cog. It hasn't been ported to C. The existing C serial I/O uses one cog for one serial port. You haven't missed anything. You either use the existing serial driver or convert the 4 port driver to a C version. It's not a beginner's project although the assembly part of the driver (the most complex part) can almost be copied verbatim.

DavidZemon

Do you need buffered serial or would unbuffered suffice? Transmit, receive, or both? What about specs such as baud rate, parity, etc?

emiljt

Thanks for help guys.

I'm not sure on the exact needs of one or two of the devices (the connection to the on-board IMU). One of the devices can run 150000 baud, or step down to 115200. That one is a connection to the receiver, so I imagine a buffered serial port would be needed. I'm just getting this project going though, so I could be wrong about that. For that one, it only needs to receive data from the rx, so one way is fine.

I did notice that the code for the Parallax FC seems to mix Spin objects and C. Does that mean it would be possible to use the Spin object in a C project?

JasonDorie

The Parallax Flight Controller already uses the 4-port serial driver, ported to C. If you look for InitSerial in the code that's where the buffers and port rates are set up. By default, only the first two ports are actually used. Look for calls to functions with S4_ in the name - those are the calls to send/receive data.

Regarding your question about Spin, only the PASM sections in the Spin code are actually used. The Spin code portions are discarded, and the equivalent code is present in the corresponding cpp files.

JasonDorie

Also, even though I use two of the serial ports, technically you could remove the code for the second one because it's only active if you have an XBee connected to the FC, so by default there are two available, but you could bump that to three pretty easily.

Is your project just using the FC hardware, or are you using the included software as well?

emiljt

Thanks Jason! (one more reason to love this community, a reply from the author himself in an hour or two).

I'm using the Flight Controller hardware for sure. I was originally going to write my own software strictly for the educational experience, but I've since decided I'd rather find ways to contribute to whats there. I love the payload capacity of the Elev-8, it's made here in the States, and (don't take this the wrong way) a relatively young and simple code base when compared to a more mature project like ArduPilot. As you can tell by my n00b questions though, I wouldn't get too excited about my desire to contribute. Maybe one day I'll contribute a bug fix that you could have done in your sleep In all seriousness though, I'd love to help out, even if it's just testing firmware.

For the learning experience though, I'm still thinking of writing a simple flight controller, but for fixed-wing, using the Elev-8 FC. I just recently finished a FT Explorer build that would be perfect for this since it's cheap to fix, can carry a nice payload, and has a large dihedral wing.

JasonDorie

If you want to write your own, the drivers are generally set up to be pretty modular, and should make for an easier starting point. Start with the sensors, servo, R/C and serial drivers and you should have everything you need to build a simple gyro-based flight stabilizer.

Making it auto-leveling is challenging for some non-obvious reasons if you aren't a math geek. The QuatIMU code is a full orientation tracking IMU in software, and also handles the orientation controls and altitude tracking.

There are comments and docs in the GitHub repository that describe a lot of the code and he math involved, and if you have any questions I lurk here regularly.