COG hardware for SPI

JCee

Let me start by saying I really like what Parallax has done with the Prop but one thing
I wish was included was hardware to handle serial coms.· I would rather have some SPI hardware
than a second timer in each COG.· Every project I have worked on so far has used the serial
driver at some point, even if it was just for debugging. I have yet to use any of the counters,
I wouldnt mind giving up half of them.·

In my current project I have one COG left to read and process GPS data, but all of the objects I have seen so far
need at least two COGs, one to read serial values and one to process the data.·

Is it possible to use the counters to read serial data and free the COG to process the data?
Any chance the next prop will have serial hardware?

Chad George

I think using the counters depends on what kind of applications you're using and knowing how to use them effectively. I've used them often and many times actually wanted more counters per cog... certainly not less.

More than one time I've moved some bit of code into another cog just to gain access to the spare counter.

As for GPS processing in a single COG ... That seems like it should be feasible. I haven't looked at the code personally, but I'd imagine that most implementations use 2 COGs just because its more convenient (the uart already exists)

The only complexity with a software UART is high-speed duplex operation (changing back and forth between send and receive while not missing any bits)

Since GPS is receive only (I'm assuming because most I've seen are just a constant stream of data) it definitely doesn't take a full cog to handle this.
So this could be easily integrated somewhere else in the system (assuming it can't fit in the GPS processing COG)

On the other hand, serial comms (async, SPI, I2C) are in every design I've every used the prop for. Its not hard to do in software, but unlike most other micro's the prop doesn't really have anything to help ... other than of course not requiring interrupts.

Timmoore

I do gps without using additional cogs. i use the 4 port serial driver so I get 4 serial ports in 1 cog so once i have used the 1st serial port the remaining 3 dont need a cog. GPS processing I do in the background in an existing cog, I.e. I find a cog that is doing a loop - often the main cog is looping processing stuff and poll gps during the loop. Since the serial port is buffering the line, the gps processing doesn't need to be done that often.
I write my software with 2 models in mind
1. High speed tight timing - dedicated cog - often pasm.
2. Low speed , lose timing - have a poll function

Then the main cog is a repeat loop calling all the low speed polling functions.

I find one of hte big advantage of the prop is the lack of dedicated hardware. I dont have to worry when I start a project whether I have picked a version of the micro that has enough serial ports/I2c/ PWM, etc. If I need another one of those its straightfoward to add.

Post Edited (Timmoore) : 6/26/2009 7:27:08 PM GMT

Mike Green

It's really hard to justify adding hardware to handle serial comms when software works so well and can be reconfigured on the fly to do something else. There's also the issue of design errors. Serial hardware is complex, particularly if it has to handle a variety of serial protocols (async, I2C, SPI, etc.), and it's very common for there to be significant hardware errors persisting through several versions of the chip, sometimes requiring bizarre work-arounds.

There's one async serial driver in the ObEx that provides up to 4 high speed full duplex serial ports with optional handshaking. There's an SPI driver in the ObEx that's pretty fast as well. The I2C drivers have not been optimized for speed, but for flexibility, and could easily be sped up significantly.

JCee

I realize that doing the SPI in software allows for greater flexibility but so many times I have to dedicate a COG just to print some values on the terminal. The 4 port serial driver would be a good option but i dont have the serial driver already running.

I agree GPS is primarily a read only application. Maybe I can come up with some ASM that will read the data and update some values in hub memory.

Thanks for the feedback
-JC

Mike Green

How are you using the existing cogs? You may be using them inefficiently.

JCee

I am working on an autopilot with OSD.

3 Cogs for OSD
1- Overlay Driver
1- Graphics Driver
1- Display Handler

2 Cogs for Attitude Estimations
1- ADC (Sensor Reading)
1- Attitude Calculations

1- Cog for Rc Control ( Read Reciever values / drive servos)

1- Cog for Navigation and Control

1- Cog for GPS parsing

If there was a way to combine the graphics + overlay driver into some LMM code and still keep the timing I would
be all for it. I tried to cut the floating point math and move everything to integer to save a cog.

I am really considering putting a second prop on the board to allow for any future expansion.

Mike Green

Unless you're time limited, you might be able to combine the Attitude Estimations cogs. In other words, read the sensors, then calculate the attitude information.

You also might be able to combine the GPS parsing with the serial I/O as long as you can get away with ignoring the GPS information while you're parsing the last line from the GPS.

Timmoore

Couple of questions
which adc?
Are you connecting the output channels of the rc receiver to the prop and then working out the pulse length?

I would look at it this way. The time sensistive stuff you have are
1. Overlay driver
2. Graphics driver
3. Pulse length for rc receiver
4. Pulse length for servos
5. Serial read of gps

None of the rest sound time sensistive, so I would start with 5 cogs for the time sensistive functions, 1 cog doing the rest in a loop, with another cog for float if you need it but I would try with floatmath first. With care you can probably combine 3/4 since the timing constrains are similar.

JCee

I am using a MCP3208 with this driver
http://obex.parallax.com/objects/180/

Yes each receiver input (6 total) has a separate pulse that needs to be measured then depending on mode of operation, re generated on 6 separate output pins. I am working on an ASM routine that will do the measuring and generating with one cog.

Timmoore

That driver uses a COG because it reads each channel often. I would guess that you dont really need it read that often so you could use a spin SPI library and access the adc from spin from either the altitude cog or the nav cog. Also if the altitude calculations are taking a pressure reading and translating to altitude it doesn't need a cog. I have done that calculation on the same cog as I was reading all the sensors and doing other calculations.
For example I have a sensor board
2 cogs reading 12 sensors, doing calculations on sensor values (including altitude calculation from pressure), 1 of the cogs is also outputs all the sensor readings to debug serial port for debuging. I could combine the 2 cogs together but means rewriting one of the sensor drivers and I haven't needed to do it yet
1 cog for debug serial port and gps serial port
1 cog for float maths (probably could be removed but haven't needed to yet)
1 cog for I2C slave
for a total of 5 cogs - 2 are time sensitive - serial and i2c slave, 2 polling loops cogs and 1 float cog
With yours I would guess that the altitude and nav calculations could be combined. I would do the gps processing (except serial port) on the same cog and use a standard serial port for gps input
I would also look at whether the display handler can be made a polling system and called from same cog.
With that I think you could have several spare cogs.

JCee

that would definately require me to change the entire architecture of my system, i am not sure i want to do that yet.
I guess there is no way to configure the counters to read serial data.

Mike Green

That's correct. You could use a counter to time the width of the serial input pulses, but you'd still need a lot of code executing to extract a bitstream from that. The counters are designed for timing pulses and counting them.

Cluso99

Much easier to offload all the display sections to another prop Remember, your first prop can load the second prop saving the second eeprom.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm