Shop OBEX P1 Docs P2 Docs Learn Events
Can I/O pins be used as a way of communicating between cogs — Parallax Forums

Can I/O pins be used as a way of communicating between cogs

YodaYoda Posts: 132
edited 2009-07-11 19:37 in Propeller 1
I am interfacing a propeller to a z80 system as an intelligent I/O subsystem. I have several cogs assigned to look like I/O ports and are doing waitpeq's until they are selected. For input, the timing is pretty critical. A rdlong of the status from the hub doesn't always work. I only need a couple of bits of status information, I have 2 I/O pin un allocated. I was thinking I could set a pin high in one cog and the cog that needs status does a read of the pin which would be faster and more deterministic.

Is it possible to do something like this with the lock bits as a different way?

Thanks

Dave

Comments

  • jazzedjazzed Posts: 11,803
    edited 2009-07-10 15:51
    Using a pin as a mail-box flag (cog1: or outa, pin, cog2: waitpeq pin, pin) is faster than using wrlong/rdlong.
    I use this in some device drivers. Haven't considered locks for this, but they are also "hub operations".

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve


    Propalyzer: Propeller PC Logic Analyzer
    http://forums.parallax.com/showthread.php?p=788230
  • YodaYoda Posts: 132
    edited 2009-07-10 16:14
    Steve

    Thanks for the reply. I was thinking the actual lock ids might not be in the hub memory and I could use lockset and lockclr as a mechanism. I just looked at the manual and it says they are in hub memory so I guess that idea is not going to work.

    So it looks like I will try out the I/O pin idea. I have 2 free pins so I can have 4 status conditions that I can read and make decisions on. I think that will be sufficient for what I am doing.

    Dave
  • Nick MuellerNick Mueller Posts: 815
    edited 2009-07-10 16:27
    > I have several cogs assigned to look like I/O ports and are doing waitpeq's until they are selected.

    But what do you need a different COG for to signal a status?
    I mean, if address-line XYZ selects a certain COG, he can see that by himself, or not?
    Or what am I getting wrong?

    Nick

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Never use force, just go for a bigger hammer!

    The DIY Digital-Readout for mills, lathes etc.:
    YADRO
  • YodaYoda Posts: 132
    edited 2009-07-10 17:55
    Nick

    Here is the scenario, I am generating VGA, Keyboard and uSD card as disk for a z80 system. I need a status port for example that the z80 through CP/M can see if a character is available. I have a cog handling the keyboard and a cog emulating the I/O port(s) to the z80. I must be able to communicate to the status port cog that there is a character available. I could do this through hub memory but sometimes that takes too long and I don't have time to send the data to the z80 within the time required. If I use local memory it works fine and works most of the time with hub memory so that is why I need something faster.

    Dave
  • AleAle Posts: 2,363
    edited 2009-07-10 18:08
    Can't you insert a wait state using the /HALT line of the Z80 ? It is even possible ?

    If the pin is not used (like the SCL line for EEPROM maybe) why not, it will be fast!
    Btw you can always overclock! ~100 MHz works great

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
    pPropQL020: propeller.wikispaces.com/pPropQL
    OMU for the pPropQL/020 propeller.wikispaces.com/OMU
  • YodaYoda Posts: 132
    edited 2009-07-10 18:52
    Ale,

    That was my other option is to drive the is to use the /WAIT line on the z80 but I would like to avoid that if possible. I do have to free pins right now and as you suggest I could use the serial communication (P31 and P30) as they are not used once the code is downloaded into the prop.

    I am planning to go to 100MHz soon maybe the 25% would solve the problem but I may be limited in how much faster the z80 can go. It is only at 4MHz now - would like to go to 6MHz eventually so I would be back in the same dilemma. By having essentially a local variable I can get data on the z80 data bus within 50ns of chip select which seems to be satisfactory. With rdlong it can be substantially longer and is variable which seems to be causing the problem

    Dave
  • AleAle Posts: 2,363
    edited 2009-07-10 19:19
    Are you sure you need the data within 50 ns of CS ?. I thought that data was latched when /RD went high...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
    pPropQL020: propeller.wikispaces.com/pPropQL
    OMU for the pPropQL/020 propeller.wikispaces.com/OMU
  • YodaYoda Posts: 132
    edited 2009-07-10 22:03
    No I don't need that soon but that it is ready by then means I am OK. It appears I don't quite make it always by doing the rdlong.
  • localrogerlocalroger Posts: 3,452
    edited 2009-07-10 23:03
    The recently posted Turbulence demo did exactly this; cog to cog comms over otherwise unused I/O pins are·faster than hub ops because they don't have to wait for the hub to sync.· Well synchronized hub ops (2 pasm instructions between hub operations) can be about half as fast as i/o pins at the same bit width -- but 8 bits require 8 I/O pins, so it needs to be an app with a lot of the I/O pins hanging unused to be practical.
  • RossHRossH Posts: 5,512
    edited 2009-07-11 00:35
    @all,

    It's a real shame Parallax didn't implement the B I/O register on the Propeller - that would have allowed blindingly fast cog to cog communications, bypassing the hub. I even started designing a CSMA/CD comms protoocol that would allow all 8 cogs to talk together before I realized that the Prop didn't implement the B register. Such a lost opportunity!

    Perhaps since the original Prop I is now almost out of stock we could plead with Parallax to add the internal circuitry required to implement the B register in a new Prop I (mark 2).

    In fact, when Parallax finally release the Prop II, I hope they give consideration to releasing a version in a 40 pin DIP version which omits the external pins for the B register but which is plug compatible with the Prop I (and with the B register implemented internally). What a screamer that would be - and still pin for pin compatible with the original Prop I!

    Ross.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Catalina - a FREE C compiler for the Propeller - see Catalina
  • Mike GreenMike Green Posts: 23,101
    edited 2009-07-11 00:48
    RossH,
    Pleading with Parallax won't help. There was some discussion in the last Webinar about the cost of finishing the 64 pin version of the Prop I. It's not financially feasible. When the Prop II is available, there won't be a simple 40 pin DIP version. The only way it could be done would be something like the Spin Stamp in a larger module. There would have to be a 1.8V regulator on the module and the real pins would have to be routed to the 40-pin module pins. There will be some extra pins on the SMT package. I suspect that it would be fairly expensive to make a 40 pin DIP module much like the Spin Stamp.

    It's nice to dream about what might be or what we wish could be, but the reality is that we have the Prop I and it can do some things and can't do others. We will eventually have the Prop II and it will be able to do a lot more, but maybe not quite the way we want and there will be costs involved, both monetary and functional.
  • RossHRossH Posts: 5,512
    edited 2009-07-11 02:35
    @Mike,

    My understanding is that the costs were mostly to do with making the pins visible to the outside world - and I don't want the actual pins, just the internal B registers included and accessible by all cogs.

    I agree it is unlikely to happen - but I can dream, can't I? smurf.gif

    Ross.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Catalina - a FREE C compiler for the Propeller - see Catalina
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-07-11 03:10
    Yoda: As others have said, use the pins internally - it works·yeah.gif· They are internally connected and I have used that method to·start 4 cogs running in synchronised, but each a clock offset, to start storing data from the I/O pins at 12.5nS sampling in a datalogger.

    Ross: Yes it is a pitty the Prop I does not implement the extra 32 I/O pins internally.·Chip didn't and as Mike has said, Parallax have determined it is not financially viable to produce a 64 I/O version.shakehead.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Bill HenningBill Henning Posts: 6,445
    edited 2009-07-11 03:29
    Sigh... I know, and I totally understand the financial part (being at the start of launching Mikronauts and the first product line of my own...

    But still.. 64 I/O Prop would have allowed a really nice 16 bit wide data bus, 16 bit page size XMM interface... drool.

    Ah well, the Prop2 will allow even more amazing things!
    Cluso99 said...
    Ross: Yes it is a pitty the Prop I does not implement the extra 32 I/O pins internally. Chip didn't and as Mike has said, Parallax have determined it is not financially viable to produce a 64 I/O version. shakehead.gif
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
    Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
    Morpheus & Mem+ Advanced dual Propeller SBC with XMM and 256 Color VGA
    Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-07-11 09:14
    When the question was raised by Parallax very early this year about Prop IB, no-one could forsee the abunance of new designs requiring the extra pins [noparse]:([/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • AleAle Posts: 2,363
    edited 2009-07-11 14:56
    Cluso: If Parallax could sell 20000 units in say 2 or 3 months, then they would do it. For less units it is too much money :-(

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Visit the home of pPropQL: propeller.wikispaces.com/pPropQL
    pPropQL020: propeller.wikispaces.com/pPropQL
    OMU for the pPropQL/020 propeller.wikispaces.com/OMU
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-07-11 19:37
    For tinkering at home the 3.3V of the Prop1 is close enough to real world keyboards, mice etc and with a resistor or two, most 5V stuff plays nicely.

    I wonder what extra compulsary bits will have to be added to get the Prop2 to work all that I have already.

    Hobbled, the 40 pin DIP Prop2 may be deemed to be but the proper one with 0.5mm, or so, pitch together with a whole bunch of level conversions, it will remain beyond full on home construction, here.

    If only we could pool one great promised order, to allow a special batch.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
Sign In or Register to comment.