Question about I/O Architecture

nick112147

··· I have a question about the I/O architecture of the Propeller microcontroller. Are all of the I/O pins serial(P0-P31), or just P28-P31? Any help is greatly appriciated. Thanks,

Nick

Paul Baker

None of the pins are technically serial, pins 28-31 have a special meaning at bootup but become ordinary I/O after the bootup process is complete. The propeller does not have dedicated I/O pins for special functions like most microcontrollers do (we feel dedicated hardware is wasteful and cost ineffective·for projects which do not use·it, so everything is general purpose). All functionality of the I/O pins are dictated directly by the program running on the Propeller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

hippy

Quick answer : Yes, all pins 0-31 are serial

Longer answer : All pins 0-31 can be anything you want them to be once your program starts running; inputs or outputs. When booting from Eeprom and downloading from PC the pins have a special purpose, but as soon as booting and download is complete they are turned back to inputs. You can do anything you want with them after that. To use them for serial you will need some software which interfaces with those pins to send or receive serial data.

nick112147

So I have to program them to be serial? So really I can make them serial or parallel. Wouldn't this make operation slower? Maybe some background on what I am trying to do will help. There is a strong possibility that I will be using the Propeller in a CD-ROM media based game console. From the what Hippy is saying I pretty much need to write an OS or atleast a large BIOS program in order for it to function using either parallel or serial. One thing that concerns me about all of that is that I will have to run an OS and the game at the same time in order for it to work properly and function as a serial device. I suppose a good way to counter that is to run the OS on one COG and use the other 7 seven for the game and graphics. Another small question, what about memory mapping? Does that need to be programmed, or is there already a set memory map for each pin? The data sheet looks like it only provided the memory mapping for the internal RAM and ROM. Thanks for the help so far.


Nick

Phil Pilgrim (PhiPi)

The pins are mapped to cog memory, via the INA, OUTA, and DIRA registers. Every cog has equal access to all the pins. When two or more cogs use the same pin for output, the value on the pin is the OR of those cogs' OUTA bits for that pin.

-Phil

Mike Green

There are existing "objects", essentially library routines, to provide "virtual I/O" like a buffered full duplex serial port. There are objects for other functions like video to a VGA display or for a PS/2 keyboard and/or mouse.

nick112147

Oh, so any Cog can access any pin, which means any cog can access an IC according the OS's programming instructions, ergo a video processor and sound processor get their own CPU/cog than can readily share and process any information with any other cog. I see many advantages with this, the main one being conservation of PCB space, while others include dedicated processing and speed. I know I must seem bothersom, but could someone show me a SMALL example of assembly or SPIN (no need to show both I am not that needy ) of how one might output serial data to a single pin? I am assuming these registers are 32-bit right?

In response to Mr.Green: So I wouldn't even need a real OS, since all of the routines exist in firmware form. what is even better because I don't want to bog down the processor. I am extremely new to the Propeller, what mainstream processor can I compare a cog's processing·to, a·Motorola 68K·or an early/newer x86?

Post Edited (nick112147) : 3/5/2008 1:42:23 AM GMT

Mike Green

Download the Propeller Tool from Parallax's download page for the Propeller. It comes with a variety of these "objects" and demo programs that are installed with the compiler/assembler/downloader. Pretty much each I/O driver "object" has a corresponding demo program and all of this is in source form with comments in the source code. There are examples for handling servos, serial I/O, analog to digital and digital to analog conversion, and video to VGA and TV.

nick112147

Oh nice! I will check that out right now. Thanks to everyone who replied and helped.

Nick

Chuck Rice

Paul Baker (Parallax) said...
None of the pins are technically serial, pins 28-31 have a special meaning at bootup but become ordinary I/O after the bootup process is complete. The propeller does not have dedicated I/O pins for special functions like most microcontrollers do (we feel dedicated hardware is wasteful and cost ineffective for projects which do not use it, so everything is general purpose). All functionality of the I/O pins are dictated directly by the program running on the Propeller.

I believed this, and is it true to a point, but... I tried to use 28 and 29 for propeller to propeller communication via FullDuplexSerial. This worked, but I ran into a lot of trouble with a reboot of one of the propellers sending the contents of the EEPROM to the other propeller. Also programming the EEPROM without disconnecting the other propeller was problematic. So you can use these pins after bootup, but you need to be careful of how you do it.A GOTCHA that got me. -Chuck-

Mike Green

Pins 28 and 29 are used for the EEPROM. They're really handy for hooking up other I2C devices like additional EEPROM or I/O Expanders. You do have to be really careful about using them for other types of protocols. Pins 30 and 31 are used for downloading from a PC via serial I/O, so these pins are very handy for other serial I/O like a "console".

nick112147

I looked at the examples for the full duplex and simple serial I/O objects. Very nice! However, I notice this is only for the Rx and TX pins, can they be edited to use say for example, P16 as a serial I/O pin? Thanks. Sorry I have so many questions, I am not used to this kind of processor architecture, it is very unique and quite flexible compared to a standard parallel bus CPU or MC. Thanks again.

Nick

hippy

@ nick : The "OS or BIOS" code you need to implement serial interfacing can be incredibly short and sweet, just a few lines of Spin code sometimes. Six lines of code to do bit-banged serial transmit, and eight for receive ( excluding global variable definitions and initialising )...

PRI TxByte( b ) | timeout
  b := (( (( b & $FF ) ^ $FF ) << 2 ) | 2 ) ^ txInvert
  timeout := cnt
  repeat 11
    waitcnt( timeout += bitTime )
    outa[noparse][[/noparse]txPin] := ( b >>= 1 ) & 1

PRI RxByte : rxd | timeout
  waitpeq( rxInvert & rxPinMask, rxPinMask, 0 )
  waitpne( rxInvert & rxPinMask, rxPinMask, 0 )
  timeout := ( bitTime >> 1 ) + CNT
  repeat 8
    waitcnt( timeout += bitTime )
    rxd := ( ina[noparse][[/noparse]rxPin] << 7 ) | ( rxd >> 1 )
  rxd := ( rxd ^ $FF ^ rxInvert ) & $FF

More flexible code ( buffered, background receive and so on ) exists, as Mike says, as free to download and use "objects".

Chuck Rice

Yes. When you start the serial object, you tell it which pins you want to use. You could have 16 full duplex serial connections (32 pins divided by 2 pins for each connection) or 32 half duplex connections.

In my current project I use pins 1 and 2 for full duplex serial communication with a zigbee link to my laptop, pins 26 and 27 for full duplex serial communication with another propeller, and pin 8 for a half duplex serial connection to a GPS module. -Chuck-

nick112147

In section 4.5 of the datasheet it explains that no two cogs may use the same pin for different purposes, while that is common sense, what about using it for the SAME purpose. For example, 2 cogs (an ample 40 MIPS) handling the GPU. Can those 4 cogs work in unison, or rather use that pin for interfacing with the GPU.

@Hippy: I like that! However I am an ASM man myself, for the fact that I want all system level programming (drivers, BIOS, everything that is NOT the game) to be as fast as physicaly possible. While SPIN seems fast, it is interpreted in real time. Interpretation is slow, and since games are resource demanding little demons, every ns counts, because I know that having the SPIN interpreted for complex AI or graphics routines from an external GPU will as several ns to the overall execution time.

@Mr.Rice: Awsome. Thanks for the information Mr.Rice. I think this processor will serve me better than my original chioce of using a motorola for the CPU of my console. I really like the idea of using 2 processors. Has anyone ever considered using a different CPU rather than another propeller, say a Z80 or something basic like that?

hippy

While Spin is slow compared to PASM, if it does the job required then it can be a needless and time consuming effort to convert to assembler and debug it. With eight Cogs( each an entirely separate and independent CPU ) one running slower than it otherwise could doesn't necessarily impact on anything else. Another argument in favour of Spin is that if it cuts development time on the periphery you have more to spend on the core programming which is your game. If nothing else, Spin is less error prone and easier to debug.

I've found the Propeller ideally suited to rapid development and early prototyping, more so than other processors. It really does suit the "get it working, rewrite and optimise later if necessary" model. Only when limitations arise is ones hand forced into using PASM and heavy optimisations. On other processors tight, efficient coding may be required from day one which can be a major obstacle to getting a first prototype working, and it's a lot of potentially wasted effort if a brick wall is hit and a redesign is needed.

Paul Baker

nick112147 said...
In section 4.5 of the datasheet it explains that no two cogs may use the same pin for different purposes, while that is common sense, what about using it for the SAME purpose. For example, 2 cogs (an ample 40 MIPS) handling the GPU. Can those 4 cogs work in unison, or rather use that pin for interfacing with the GPU.

Thats exactly what occurs with the higher resolution video drivers: http://obex.parallax.com/objects/176/·and http://obex.parallax.com/objects/177/. Once the cogs synchronize to a clock count they remain in sync.

Your questions don't bother us, it's a novel enough architecture that everyone has questions when they first look at it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 3/5/2008 4:47:13 AM GMT

Mike Green

nick112147,
Be careful about the "assembly for everything because of its blinding speed". Each cog has only 496 x 32 bit words for instructions and data (plus 16 special purpose registers). Spin serves as a sort of scripting language to tie together the assembly language "functions" and is a quite powerful enough programming language in its own right. The Spin interpreter will run in a cog by itself and interpret byte codes in the main memory with data in the main memory and is fast enough to do 19.2KBaud half duplex serial I/O without the use of assembly.

Each cog has two special counters that can be used to measure pulse widths to a resolution of 12.5ns (with an 80MHz system clock) or generate pulses with the same resolution and these counters can be controlled from Spin.

Post Edited (Mike Green) : 3/5/2008 5:11:50 AM GMT

nick112147

While I am a fan of the blinding speed of assembley, I am more of a fan of embedding assembly code into higher level languages for things that need to be rip roaring fast, rather than doing it all in assembley. That method allows a slightly more ballanced environment. Graphical routines for an external GPU would be more suited for doing it in assembly and SPIN, where as handling a controller port might be more suited to just SPIN. The small instruction and data cache troubles me though, how will it be possible for me to create a more complex program?

I suppose using ample amounts RAM as intermediate between all of the devices versus directly connecting them to a serial port I program on the chip could solve the problem. One cog dedicated to SPIN, two to three for the GPU, one should be sufficient for sound, and the other 3 can be used as support. I am liking Mr.Rice's use of two processors connected via a serial bus. Out of curiousity, has anyone ever succesfully interfaced a CDROM drive with a Propeller? I hate to use ROM cartriges, they are bulky and quite expensive to make. Thanks again for all of the replies, the amount of help I am recieving is astounding. Thanks,


Nick

potatohead

For game related stuff, you are likely to find SPIN more capable than it appears at first glance! It's speed is roughly that of assembly language programs on 8 bit micros. One way to put that into perspective is to consider those systems had dedicated silicon that did the actual driving of the display, leaving the slower CPU to just handle the game logic and data. Same for I/O on those systems as well.

You should take a look at some of the games posted up in the HYDRA section of this forum. The main game logic runs easily in SPIN, while the lower level GFX, sound and I/O, run as assembly language programs, each in their own COGs. It all happens on one chip!

Because those choices are made in software, you get to make all the trade-offs without having to do core hardware (re)design in so many cases. It's also totally useful to use more than one Propeller, treating each as either a very capable sub-system, or the main CPU as you see fit. That's the beauty of it. Any Propeller can do graphics, sound, I/O, frequency generation, etc... In fact, any COG on any Propeller can do these things at any time, so long as there is enough RAM to handle the task.

A great example of the multiple Propeller approach is the PropGFX system Coley and Baggars are developing. It's a propeller, and one can even program it like any other propeller, with some work. However, the goal is to have it packaged and shipped with the programming already done to act like a very capable GPU. As such, it can be incorporated into many designs, not just Propeller ones. I think a Z80 demo is in the works, showing off doing just that.

For those cases where a given large program won't fit into a COG instruction space, cannot be broken into parallel components (or isn't worth doing that), and has speed requirements that exceed what SPIN can deliver, there are some projects being developed to address that:

There are two main approaches: alternative interpreters, and large memory model assembly code.

The alternative interpreters really won't have a speed advantage over SPIN (I'm pretty sure, who knows?), so just consider them SPIN like, for this discussion and leave it there. They do larger programs, and have other features SPIN does not have, most likely.

The large memory model stuff is interesting though! And it's the focus of a lot of different development efforts. See the Propeller wiki for more on this.

Basically, COGs load up their program from the main HUB memory, which can then be overwritten for other purposes, and begin executing them. That's the model used most often right now. Perfect for I/O, sound, GFX, etc... You only need to get the COG loaded, then it just does it's thing, leaving that HUB memory free for other purposes. So, that's 32K of HUB memory, plus 16K of COG memory, 2K / cog, or 512 longs per COG. If you are careful about how you load, init, and use that memory, you can get above the 32K limit, maybe closer to 48K of RAM instead of 32K.

An alternative is to have the COG load up a smaller assembly language kernel program, which then just fetches and executes assembly instructions from the main HUB memory. The speed of this is somewhere between SPIN and assembly, with the result being probably closer to assembly than SPIN. That larger program then lives in the HUB memory, where it gets executed, piece by piece, by one or more of the COGs, as necessary.

The up and coming Imagecraft C complier is going to use this model.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Chat in real time with other Propellerheads on IRC #propeller @ freenode.net

deSilva

@Nick,
as you say you have some background in assembly programming already it might further (or start) your understanding of how the Propeller works by browsing through my tutorial "Programming the Parallax Propeller using Machine Language":

http://forums.parallax.com/attachment.php?attachmentid=48819

nick112147

Astounding! I think the best plan for me would be to dedicate one Propeller to the actual game program code, and then dedicate the second Propeller to the main I/O, external GPU handling (because 256 colors isn't sufficient for my application), sound and other stuff not directly related to handling the main game program. Programs should not be that large. It is the game resources I am most worried about. For the most part, programs won't be large as I said before, but graphics, music and sound will be another story. My console will be more on par with the arcade games of the early 90's. How can I work around that without having to do a mind bendingly huge amount of constant switching because of the 32k limit? Even if I were to expand this using the tecnique you described to bring the limit up to 48K, sound, music and bitmaps take up alot of space. The Propeller is almost a work of absolute perfection, it is really a work of art, my only complaint is the restrictingly tiny memory space. If I am correct, most GPU's and sound feed directly off of RAM, so couldn't I skip bringing any of that data through a CPU first? This would mean having to use cartriges rather than CDs though. This diagram might help a little:

Cartrige GFX/Sound ROM -> RAM -> Any hardware needing to access it.

On the program side, the binary program would go directly into the Propeller, then sending any data it needs to to the second Propeller that "listens" for instructions for controlling the graphics and sound processors.

Cartrige Program ROM -> Propeller #1 -> Propeller #2 -> Sound/Graphical Processors


My design is probably faulty in many ways but it looks like a good starting point.

tpw_man

Instead of ROM carts or CD drives, you could use SD cards. They are reusable unlike CDs or ROM carts.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1010, so be surprised!

Coley

Nick,

You sound like you need a Hybrid www.propgfx.co.uk/forum/Blah.pl?b-hb/m-1192495734/
and a PropGFX www.propgfx.co.uk/forum/Blah.pl?b-PL/m-1198808109/

Coley

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite

nick112147

@ tpw_man: Nice idea tpw_man, I hadn't really thought about it, but it carries advantages over CD's and carts. Particularly their size, capacity and reusability. Thanks.

@Coley: Nice project! But what is the PropGFX, your own custom chip? If it is, I should mention that I could in no way afford to hire a foundry to make me chips :-(. Forgive my daftness, but it just looks like you are using a custom chip. If it isn't a custom chip, what brand is it? Also, what do you recommend as a graphics coprocessor? For about a year now, I have been searching for a good graphics processor that doesn't require making a million dollar deal with ATI lol. Thanks.

@deSilva: Very nice tutorial, it is helping me alot, I am going to start writing a BIOS tonight. Thanks.

Thanks again everyone, you guys are really helping me with my design!

Nick

Coley

Nick,

The PropGFX is as the name implies a 'Propeller' based 'Graphics' co-processor and it is due to be launched very soon.

It comes in an 'easy to integrate' DIP40 package and is ideal for prototyping.




Regards,

Coley

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
PropGFX Forums - The home of the Hybrid Development System and PropGFX Lite

StefanL38

hello,

if you take a look at the picture of

http://www.propgfx.co.uk/forum/Blah.pl?b-hb/m-1192495734/

first you see tha backside of the pcb

there is a chip-id P8X32A-D40 this is the ID of the ORIGINAL PARALLAX PROPELLER-CHIP!
it nothing custumized

and if you take a close look at the other pictures you can see a very slight letters printed on the topside of this chip

especially the picture titled "The Magical Propeller in all it's Glory!"

IT IS the propellerchip !


best regards
Stefan

nick112147

Oh so it is using the internal video processors of the propeller. I really don't want to use it's internal GPU because I do not think it supports anything like multiple scrolling layers, split screen scrolling. semi-transparency or extremely large sprites (512x512). If anyone knows of a good GPU that supports those kinds of things, let me know.

Paul Baker

nick112147 said...
·If anyone knows of a good GPU that supports those kinds of things, let me know.

I'm not aware of anything which doesn't require and entire subsystem of chips. Also nearly all of them were designed to interface with a bus system which would nearly cripple the Propeller it's connected due to the heavy amount of interfacing code and the large amount of I/O needed, I wish you luck on finding something.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 3/6/2008 9:48:16 PM GMT

nick112147

Hm, well I looked at the data sheet some more and it said 4-color 32-bit video, I am assuming that is 32-bit RGBA, or atleast something similar to 24-bit RGB? I wouldn't hook anything devistating up to it, probably something similar in power to a Sega Genesis or Super Nintendo's processor, both are quite low power and ran under a 16-bit processor.

Post Edited (nick112147) : 3/6/2008 9:59:51 PM GMT

deSilva

? You looked at WHAT data sheet?