Shop OBEX P1 Docs P2 Docs Learn Events
tricks with B registers — Parallax Forums

tricks with B registers

Bobb FwedBobb Fwed Posts: 1,119
edited 2009-03-12 17:52 in Propeller 1
I have hear mention of some tricks that may be performed (at least with PASM) using the DIRB, OUTB, and INB registers. The thing I was reading (don't remember what) said they were going to right some info on it later. Seeing as I don't remember where I read it, it is difficult to follow up on it.
Are there any special things you can do with them. I was hoping for being able to use WAITPEQ with it, but that only works on input changes (it appears).

I have a couple days here while my project is being printed and delivered to learn some new mastery of the Prop.

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2009-03-11 23:08
    DIRB, OUTB, and INB do not actually exist as registers in the current Propeller. If you refer to those locations, you will be accessing the underlying memory locations in the cog ram (since there's actually 512 longs of cog memory). As the Propeller Manual indicates, WAITPEQ and WAITPNE always refer to INA on the current Propeller.
  • Bobb FwedBobb Fwed Posts: 1,119
    edited 2009-03-11 23:42
    The registers exist (or maybe I am getting the terminology wrong). I can store a long in DIRB and OUTB...and I can access it (at least in spin). Maybe that was the only trick that the writer had in mind. Where memory is short, a couple more longs to store and access isn't a terrible thing.
  • mctriviamctrivia Posts: 3,772
    edited 2009-03-12 01:12
    yes you can get 3 extra longs of storage using those 3 registers. as mike was saying they are no different then any other address because the 64 io prop was never released.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.
  • Bobb FwedBobb Fwed Posts: 1,119
    edited 2009-03-12 01:40
    Oh what I could do with 64 IOs.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    April, 2008: when I discovered the answers to all my micro-computational-botherations!
  • mctriviamctrivia Posts: 3,772
    edited 2009-03-12 01:44
    well if enough people said they wanted it I am sure Parallax could put out 1 BGA pack for it. I have already posted that if they did I would be willing to make adapter boards from BGA to DIP.

    To what I have herd though they need to be able to sell at least 10,000 units to make worth while. May be more not sure.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.
  • Mike GreenMike Green Posts: 23,101
    edited 2009-03-12 01:59
    mctrivia,
    Putting the Prop I in a BGA pack or any other package wouldn't help you. The chip itself does not have the "B" I/O circuitry. It doesn't exist on the chip. There's nothing to connect to.

    There was a message some time ago that Parallax was in the process of designing a Prop I that did have the 2nd set of I/O. There is a bug in the chip design software that Parallax is using for the Prop I and it's impossible to verify the design with the current software. Without the verification, they can't go on to build prototypes and the software vendor is in no hurry to fix it for some reason. Basically it's on hold and the Prop II may be done before the Prop IB.
  • mctriviamctrivia Posts: 3,772
    edited 2009-03-12 02:20
    did not know about the bug that sucks. I was not suggesting putting prop 1A in BGA but prop 1B as 80 pin dip would be huge chip better to make 1 standard small chip and make adapter boards for the hobiest wanting a nice bug DIP package.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.
  • Carl HayesCarl Hayes Posts: 841
    edited 2009-03-12 06:26
    Shortness of memory isn't the only reason for using those longs that constitute the B I/O registers.

    A cog running PASM ordinarily must wait for hub access to get at the shared longs in hub memory.· As I read the manual, however, the B I/O registers can be accessed at any time by any cog without waiting for a hub window.· So, if I'm interpreting the manual correctly, some time can be saved by using these I/O registers for trading info among cogs.· Care would be required, of course, to avoid errors resulting from simultaneous accesses.· But frankly that's pretty easy if the same guy is writing the code for all the cogs, and that guy is any good at it.

    O ye who know more than I do (several of you), am I correct in this?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    · -- Carl, nn5i@arrl.net
  • ImageCraftImageCraft Posts: 348
    edited 2009-03-12 06:36
    I am betting $.25 that each Cog has its copy of those registers..... since they would just see the underlying SRAM local to each chip.
  • Carl HayesCarl Hayes Posts: 841
    edited 2009-03-12 06:47
    ImageCraft said...
    I am betting $.25 that each Cog has its copy of those registers..... since they would just see the underlying SRAM local to each chip.
    Yes, I consider that quite possible, with future OR logic to connect them to the actual pins when there are pins to connect to.· No bet.· But there will be someone here who knows.· Of course I could find out experimenally by programming one cog to change them every second or so, and another cog to read and display them.· Not too tough a job, but surely someone knows.· Idle to hope that the manual would say.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    · -- Carl, nn5i@arrl.net
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-03-12 07:00
    Each cog has its own distinct set of B "registers" (memory locations). They can't be used for communicating among cogs. Read Mike's initial response. Mike knows! smile.gif

    -Phil
  • Carl HayesCarl Hayes Posts: 841
    edited 2009-03-12 16:08
    Mike does know, but did not address that particular issue clearly. You did, with admirable clarity. Thanks!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    · -- Carl, nn5i@arrl.net
  • Cluso99Cluso99 Posts: 18,069
    edited 2009-03-12 16:32
    The memory locations that are in parallel to the registers are known as shaddow memory. There are a number of uses for these and they can only be accessed by some, not all, propeller pasm instructions. They are all set to zero on coginit/new so can also be also used as a zero constant.
    I used the first 4 shaddow memory longs in my debugger to execute code from there -see PASM and SPIN debug with Zero Footprint http://forums.parallax.com/forums/default.aspx?f=25&m=290946 for more information.

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

    · Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
    · Prop Tools under Development or Completed (Index)
    · Emulators (Micros eg Altair, and Terminals eg VT100) - index
    · Search the Propeller forums (via Google)

    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • TJHJTJHJ Posts: 243
    edited 2009-03-12 17:20
    But they do sync do they not. When Does a Dira B change get expressed in the other cogs? If ever? Dont they have to be synced in order to prevent driving an input? Or one cog trying to drive a pin out that is in high impedance state? Is it on the timing window? Wouldn't the INB/OUTB register be forced to be physically linked in order for them to work correctly. Such as a change on OUTA causes a pin to go high and a resulting change on INA? I wonder if you could write to OUTB and read it on INB from another cog? I would suspect the physical link is most likely missing making this not work, but maybe......

    Even if If they do sync every hub window, it would allow you to pass 2 longs to hub, 1 address + 2 longs to the next cog, ect allowing for 1 cog to get uninterrupted access to the main ram or allowing it to only have to wait a single window no matter where in the cycle the hub is?

    I have been wracking my brain for months for a way to expand the cog ram size with out going LMM and being forced to wait for the hub sync.

    TJ

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    I owe everyone here a bunch, So thanks again for answering my dumb questions.
    Projects. RG500 ECU system. PropCopter. Prop CanSat. Prop Paste Gun.
    Suzuki RG500 in a RGV 250 frame.
    Bimota V-Due (Running on the fuel injection system)
    Aprilia RS250
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-03-12 17:52
    TJHJ said...
    But they do sync do they not. When Does a Dira B change get expressed in the other cogs?
    No, they don't sync. There is no intercog connection among the so-called port B registers. They're just cog-resident memory locations.

    -Phil
Sign In or Register to comment.