Shop OBEX P1 Docs P2 Docs Learn Events
BASIC Stamp 2P 40 Help! — Parallax Forums

BASIC Stamp 2P 40 Help!

Dan TaylorDan Taylor Posts: 207
edited 2009-02-21 06:17 in BASIC Stamp
Can someone please explain to me how to use the BS2p40?

I don't get the whole MAINIO and AUXIO thing. When I try to light an LED on p15 it dosn't even work. I am doing this on the PDB for the BASIC Stamp. Please help!
Thanks!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Dan Taylor

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2009-02-14 20:39
    Basically, the BS2p40 has two sets of 16 I/O pins. PBasic only has provisions for 16 I/O pins in the various I/O registers and instructions, so the BS2p40 has statements to switch from one set of 16 I/O pins to the other, MAINIO and AUXIO. The default is MAINIO after any reset (like from power up). The I/O pins labelled Pn are part of AUXIO, so you'd have to execute an AUXIO statement somewhere in your program to enable the Pn set of I/O pins before you do something with the I/O pins (like a HIGH or LOW statement).
  • Dan TaylorDan Taylor Posts: 207
    edited 2009-02-15 00:46
    So if I am just using the Main I/O pins I don't have to use any MAINIO or AUXIO Commands?



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Dan Taylor
  • Tracy AllenTracy Allen Posts: 6,662
    edited 2009-02-15 02:18
    Correct--There is no need to use the MAINIO or AUXIO if you are only experimenting with the MAINIO pins.

    Be careful with the pin mapping from the BS2P40 on the professional development board. Look at the pin mapping on page 6 of the PDP instructions. It can be confusing when you use a BS2p40.

    The 24 pin BASIC Stamps have 16 i/o pins, usually numbered from p0 to p15, and those 16 i/o's go from p0 to p7 down one side of the package and from p8 to p15 on the other side of the package. On the PDB they connect to the 16 places on the plugin terminal strip labeled X15, and correspondingly labeled "0" to "15". Very straightforward.

    Now, look at the BS2p40 package. The module itself has MAINIO, logical pins p0 to p15 running down one side and auxio, logical pins x0 to x15 running up the other side. When you install a BS2p40 on the PDB, it ends up with 8 of the mainio, p0 to p7, and 8 of the auxio, x8 to x15, on the connector x15, instead of p0 to p15 as it was on the 24 pin stamps. But the PDB docs still refer to those terminals as they come out on the PDB as P0 to P15. And the remaining pins of MAINIO, p7 to p15 and of AUXIO, x0 to x7 end up on the socket that is up at the end of the PDB and lableled "AUXIO". Confusing? Each of those terminal blocks ends up with half of the MAINIO and half of the AUXIO signals from the BS2p40. The designations on the terminals labled "AUXIO" run from RB0 to RB7 and RC0 to RC7, as they are on the SX chip that might share those terminals.

    The PDB manual refers to the logical MAINIO pins as M0 to M15 and AUXIO from as A0 to A15, however, in most of the examples you will see, the pins designations as shown on the BS2p40 schematic are used, p0 to p15 for MAINIO and x0 to x15 for AUXIO. Confusing again?!


    All pins on MAINIO and AUXIO come up as inputs at power up. Experimenting is one thing, but in any final application, all unconnected pins should be made outputs in one state or another in order to minimize current drain.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • GeekgirlGeekgirl Posts: 50
    edited 2009-02-18 23:38
    One of the other little "gotcha's" of the p40, is using auxio pins and pollin.

    If, for example, you have a subroutine or section of code that only uses auxio pins, normally, you could put the auxio command at the beginning and the mainio at the end and all would run fine. When you use pollin, you have to be sure to auxio/mainio every single line that involves a pin, or very strange problems arise.

    I try to always design my p40 programs so that I use as few aux pins, and·as seldom as possible, on pages with pollin as it cuts down the number of potential missed auxio/mainio lines.

    Once you get used to how it works, the p40 is really nice to work with.

    It does however seem to give more grief on my PDB than when I have it on a big breadboard or in a project.



    Darlene
  • Dan TaylorDan Taylor Posts: 207
    edited 2009-02-19 05:32
    Ok! Thanks for all of the info!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Dan Taylor
  • Tracy AllenTracy Allen Posts: 6,662
    edited 2009-02-19 17:05
    Darlene,
    I'm curious about the issues you've had with POLLIN. Can you be more specific about it, or give a snippet, for example, does it happen when coupled to a POLLOUT or POLLRUN? I've not been aware of bugs with it intrinsically, although the inclusion of auxio and polling does entail a new class of pitfalls. I most often use POLLIN in conjunction with POLLWAIT, or in latched mode in conjuction with the scratchpad RAM polling bits.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com
  • GeekgirlGeekgirl Posts: 50
    edited 2009-02-20 01:45
    Tracy Allen said...
    Darlene,
    I'm curious about the issues you've had with POLLIN. Can you be more specific about it, or give a snippet, for example, does it happen when coupled to a POLLOUT or POLLRUN? I've not been aware of bugs with it intrinsically, although the inclusion of auxio and polling does entail a new class of pitfalls. I most often use POLLIN in conjunction with POLLWAIT, or in latched mode in conjuction with the scratchpad RAM polling bits.

    · I usually use pollin with pollrun. I'm watching for a button press while the main program is running, and if pressed, goes to another page where I have program options that may be browsed and selected if desired, plus the return to main program option.

    If the program is executing a subroutine for example, where all the calls are to auxio pins, and you have auxio at the beginning of the subroutine and mainio at the end,·without pollin, that works fine. But·if you don't have mainio immediately before the pollin line, it will look at the pollin pin number as an aux pin when it checks while·between the lines in the subroutine. If you do have mainio·immediately before·pollin (assuming it's on a mainio pin), then...

    When it goes back to the next line in the subroutine where it came from, it won't know to go back to auxio. I also have had better luck keeping the pollin pin in the mainio range.


    Here's a snippet of code from a subroutine, which in turn, calls another subroutine. I chose pin usage so that the called subroutine (and it's a long one)·can use all mainio pins, otherwise I'd have 100 auxio/mainio lines in it.·This subroutine only has to check on 1 auxio pin, but look how much space is wasted on auxio/mainio lines, without which, it won't work.


    DsplUpdt:

    ·· PAUSE 20
    · AUXIO
    · IF OUT12 = 0 THEN
    · MAINIO
    · SEROUT LcdPin, BM, 10, [noparse][[/noparse]145, "OFF"]
    · AUXIO
    · ELSEIF OUT12 = 1 THEN
    · MAINIO
    · SEROUT LcdPin, BM, 10, [noparse][[/noparse]145, " ON"]
    · ENDIF
    ·MAINIO
    ·· GOSUB ResetConfig1
    ··· PAUSE 20
    · GOSUB Convert1
    ······· Rslt1 = Rslt
    · SEROUT LcdPin, BM, [noparse][[/noparse]168, "··· "]
    ·· PAUSE 20
    · SEROUT LcdPin, BM, 10, [noparse][[/noparse]168,DEC Rslt1]
    ·· PAUSE 20

    For every line that refers to a pin, you have to have auxio/mainio right before and after or the program just gets lost.

    It's not a bug, but just a pita nuance of how pollin works. ... the new class of pitfalls, as you call them.·

    Once I·developed a sufficient understanding of how pollin worked, I understood why·my original·program code·ran so wierd and then crashed, and what to do to make it work as intended.

    This snippet is the option on the options page that the above display update subroutine keeps track of in the main program.

    Option2:
    · SEROUT LcdPin, BM, [noparse][[/noparse]128, "OPTION-2:·· AUTO O2 "]
    · SEROUT LcdPin, BM, [noparse][[/noparse]148, "· * * * * * * * * * "]
    · SEROUT LcdPin, BM, [noparse][[/noparse]168, "BTN-1··· NEXT OPTION"]
    · SEROUT LcdPin, BM, [noparse][[/noparse]188, "BTN-3·· TO SET VALUE"]
    · PAUSE 600
    · DO
    · LOOP UNTIL IN8 = 0 OR IN7 = 0
    · IF IN7 = 0 THEN
    · RUN 7
    · ENDIF

    ·Option2b:

    · SEROUT LcdPin, BM, [noparse][[/noparse]128, "· AUTO· O2 IS:····· "]
    · SEROUT LcdPin, BM, [noparse][[/noparse]148, " BUTTON-1· =· ON··· "]
    · SEROUT LcdPin, BM, [noparse][[/noparse]168, " BUTTON-2· =· OFF·· "]
    · SEROUT LcdPin, BM, [noparse][[/noparse]188, "BOTTON-3·· TO· SKIP "]
    · AUXIO
    · IF OUT12 = 0 THEN
    · MAINIO
    · SEROUT LcdPin, BM, [noparse][[/noparse]145, "OFF"]
    · AUXIO
    · ELSEIF OUT12 = 1 THEN
    · MAINIO
    · SEROUT LcdPin, BM, [noparse][[/noparse]145, " ON"]
    · ENDIF

    ·PAUSE 800
    ·MAINIO
    ·DO
    ·LOOP UNTIL IN7 = 0 OR IN9 = 0 OR IN8 = 0
    · IF IN7 = 0 THEN
    · AUXIO
    · HIGH 12
    · MAINIO
    · SEROUT LcdPin, BM, [noparse][[/noparse]145, "·· "]
    · SEROUT LcdPin, BM, [noparse][[/noparse]145, " ON"]
    · ELSEIF IN9 = 0 THEN
    · AUXIO
    · LOW 12
    · MAINIO
    · SEROUT LcdPin, BM, [noparse][[/noparse]145, "·· "]
    · SEROUT LcdPin, BM, [noparse][[/noparse]145, "OFF"]
    ·ENDIF
    ·PAUSE 600
    ·DO
    ·LOOP UNTIL IN8 = 0
    ·IF IN8 = 0 THEN
    ·GOTO Option2
    ·ENDIF

    The p40 when using the aux pins, is just totally intollerant of omissions.


    Darlene
  • ZootZoot Posts: 2,227
    edited 2009-02-20 02:00
    GeekGirl -- have you thought about just capturing all your INS a few times, before shelling out to subs or mainline code that parse the inputs? On my p40 projects I generally group all ins on one side and all outs on the other, that way I can capture all my input data (in SPRAM), then flip to the other bank for the second half where it all gets parsed and written to output. This would obviate the need for switching back and forth so many times.

    Also, to save execution time, if you are concerned about bank switches during POLL operations, you can check the bank flag before any bank-critical command and swtich only if the flag isn't where you want (the bank switch actually takes quite a bit of time to execute, so there are a number of good reasons for cutting down on bank switches). In other words, even if a given chunk of code presumes that correct bank is in play, right before an op like SEROUT, you check the bank status anyway.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    When the going gets weird, the weird turn pro. -- HST

    1uffakind.com/robots/povBitMapBuilder.php
    1uffakind.com/robots/resistorLadder.php
  • Tracy AllenTracy Allen Posts: 6,662
    edited 2009-02-20 05:52
    It is true that the MAINIO or AUXIO has to be used like a switch to point to the correct group of pins. The switch maintains its setting until it is changed somewhere else in the program, even if that is in a subroutine or in a cross-bank RUN. I well know the potential for bugs. I wasted a pile of time on one the other day on a sensor driver that was to be entered with two nibbles to point to two pins to use for i/o. It worked fine until any one sensor was unpugged, then the readings on all of them went whacko and didn't recover until the Stamp was reset. I really did waste a lot of time looking in the wrong places, but I had forgotten that the sensor driver also had an option (one bit at entry) to select the main- or auxio, and the bug came down to that. My programs are peppered with MAINIO and AUXIO. Those commands are very fast, unlike bank switching, which is relatively slow.

    Darlene, I don't see any POLLIN commands there in your snippets. Is POLLing more trouble than just aux-and mainio?

    Once a pin has been set for polling, say on AUXIO, the program can switch back to MAINIO and the polling action on the selected auxio pin(s) will take place in the background. For example,
    AUXIO : POLLIN 15,0 : POLLOUT 14,1 : POLLMODE 10 : MAINIO
    DO
      DEBUG BIN16 INS,CR
      PAUSE 10
    LOOP
    


    Activates a latched connection between x15 and x14, so x14 will start low, but it will go high and stay there (latched, due to pollmode 10) as soon as x15 goes low (within the ~10ms granularity of the main loop), without any further program intervention. That happens even though the main program DO:LOOP stays in mainio. The caveat there is that the MAINIO/AUXIO switch has to be in the correct position when selecting the pins to use for POLLIN or POLLOUT.



    like Zoot says, something like,
    AUXIO
      IF OUT12 = 0 THEN
      MAINIO
      SEROUT LcdPin, BM, [noparse][[/noparse]145, "OFF"]
      AUXIO
      ELSEIF OUT12 = 1 THEN
      MAINIO
      SEROUT LcdPin, BM, [noparse][[/noparse]145, " ON"]
      ENDIF
    


    can maybe be shortened to a version with fewer flips from main to aux, as in,
    myox12 VAR bit
      AUXIO : myox12 = out12 :MAINIO
      IF myox12 = 0 THEN
        SEROUT LcdPin, BM, [noparse][[/noparse]145, "OFF"]
      ELSE      ' not too good an example, the ELSEIF myox12=1 is not really necessary!
        SEROUT LcdPin, BM, [noparse][[/noparse]145, " ON"]
      ENDIF
    

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Tracy Allen
    www.emesystems.com

    Post Edited (Tracy Allen) : 2/20/2009 5:57:52 AM GMT
  • GeekgirlGeekgirl Posts: 50
    edited 2009-02-20 19:43
    The pollin is at the top of the main program page. I have mainio right before it as it's a mainio pin and what follows it untill farther along is all mainio.

    When I get home from work, I'll post it.



    Darlene
  • WBA ConsultingWBA Consulting Posts: 2,934
    edited 2009-02-21 06:17
    Make sure you don't need the slap on the forehead like I did with the PDB / BS2P40 combo.......... cry.gif

    see this thread:
    http://forums.parallax.com/showthread.php?p=767204

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Andrew Williams
    WBA Consulting
    IT / Web / PCB / Audio
Sign In or Register to comment.