Simple & small MCU with 4 UARTS

snip

Quick answers? That is a little hard to do but I'll try :)

Each core or cog is a tiny 32-bit CPU with it's own RAM and I/O ports. The Von Neumann architecture is the standard combined memory for program and data which is what the Propeller cogs are. However, unlike conventional CPUs the Propeller does not have any CPU registers but instead the cog RAM combines the program, data, and "registers". That doesn't slow things down though as most instructions take 4 clock cycles so that they run at 20MIPs on a standard 80MHz clock (5MHz x16).

The only instruction that can be really slow are the hub operations which can take from 7 to 22 clock cycles in case they miss their access slot. This can be optimized in assembler loops to squeeze a couple of instructions between each hub operation but most cogs only need to access the hub RAM to update global buffers and variables otherwise they can operate totally internally.

There are absolutely no interrupts and why should there be anyway? You have cogs which you can dedicate to the function that is required that normally could only be handled by interrupts on conventional CPUs. A powerful result of this is that each cog can be temporally deterministic and not at all encumbered with such kludges as "interrupts". Any load that an individual cog bears is not one that other cogs have to bear unless you want them too. I find it so much easier to debug and validate the software now that I do not have to deal with interrupts and the strange things that can happen as a result of indeterministic clashes.

The "UART" cog receives, transmits, and processes the data and handles the buffers in hub memory all in a transparent manner to the other cogs, so then why would you need or want interrupts? I have used my "UART" cogs at speeds of up to 2M baud with no negative impact at all on the other cogs. Objects have been written that permit 8Mbps coms between Propeller chips.

Most of the code is written in a PASCAL like syntax called SPIN. The SPIN IDE compiler are free. Here is a very basic code sample from the Propeller Manual tutorial that can be compiled, loaded, and running within a second or so with one keystroke.

****begin code****

{{ Output.spin }}

PUB Toggle dira[16]~~ 'set I/O 16 as an output in this cog (short-form ) repeat 'start an infinite loop (indentation IS code) !outa[16] 'toggle output 16 waitcnt(3_000_000 + cnt) 'wait until system clock has advanced by

3000000

****end code****

Note that this code example will run but it doesn't tell the Propeller what to do with the clock which will by default revert to the internal 12MHz RC clock.

This is the header normally used to set the clock.

****begin code****

CON _clkmode = xtal1 + pll16x ' use low-speed crystal with the PLL set to 16x _xinfreq = 5_000_000 ' 5MHz crystal x16 = 80MHz

****end code****

The assembler code doesn't actually run in the same cog that is running SPIN code but is loaded into cogs as is the case with objects such as the UART function.

Here is a snippet of PASM code that is part of the TV object:-

****begin code**** mov screen,_screen 'point to first tile (upper-leftmost) mov y,_vt 'set vertical tiles (y=vt) :line mov vx,_vx 'set vertical expand :vert if_z xor interlace,#1 'interlace skip? if_z tjz interlace,#:skip call #hsync 'do hsync

****and****

if_z xor interlace,#1 wz 'get interlace and field1 into z test _mode,#%0001 wc 'do visible front porch lines mov x,vf if_nz_and_c add x,#1 call #blank_lines

****end code****

Now screen, _screen, y, vt etc are variables located in the cog memory map which is always 32-bits wide and addressed with 9-bit source and destinations embedded in each instruction which means that each cog's memory is limited to 512 32-bit words but that it can directly address these without further reference.

Once again given the compactness of the conditional and modifiable (yes) instruction it turns out that is plenty of program memory for each cog.

The high-level Spin language itself as opposed to the PASM code (which may be embedded in sections of the Spin code) actually compiles byte tokens that reside in the

32K hub memory and are executed by an interpreter loaded into one or more of the cogs. The 32K ROM has a lot of the higher level functions that are called by the Spin code. It all sounds strange but it works and you don't have to be concerned with these details anyway.

Imagecraft have come out with a C compiler.

Yes, and isn't it a beautifully crafted piece of silicon rather than all those lego blocks chips with peripherals that try to do everything except what you really need them to do.

The thing to remember is that although each cog has a video register and two counter timers is that the cog itself is the peripheral and/or the CPU. Now that I mention the counter timers do you know that they can be setup with simple Rs and Cs as a DAC or an ADC? Not even to mention the frequency synthesis up to 128MHz. It is so easy for the Prop to generate the clocks for other chips in a larger system.

Anyway, have a look at the Parallax website for further information.

This is a link to the object exchange for source code examples of the wide variety of ingenious tasks that the Propeller (or it's cogs) have been put too.

Remember, this is an inexpensive little 40 pin chip.

*Peter*

the

y ,

n do.

,

Bear in mind the baud rates are much slower than CAN, so effects that come from reflections and from open-collector driven lines are not a big issue.

With 4x you can choose to sample the data at between 25% and 50% of the bit period or between 50% and 75%. If you use 3x the sample point moves to be between 33% and 67% of the bit period. This is about 8% closer to the bit center. It makes it a little more tolerant of bit (CPU) clock, but the big gain is the drop in processor overhead.

In practice it has worked well.

You could also look at the now sampling ATXMEGA128A1-AU -

The xMega series show EIGHT (!) uarts @ 100 pins,

7 Uarts @ 64 pins and 5 UARTS @ 44 pins.

-jg