Shop OBEX P1 Docs P2 Docs Learn Events
Getting more out of the P2... - Page 2 — Parallax Forums

Getting more out of the P2...

2

Comments

  • jmgjmg Posts: 15,140
    Tubular wrote: »
    Is it just me that fails to get excited by the prospect of a configurator?

    I understand their necessity on other micros, where there might be crossbar limitations or rules that must be adhered to, but P2 won't be similarly confined.

    We'll certainly need examples of common configuration modes, which is no problem and doesn't need a tool

    I guess its not a big deal either way. Perhaps a visualisation/configuration tool that runs on the P2 itself could be interesting

    I guess some will not mind tracking 6 Boolean fields, plus params, and counting bits, and shifting, but most users I expect will simple want to set a PWM output on Pin Q at XXX kHz to yyy bits.
    ie their focus will be on getting the chip working.

    If they ask for 12 bits and 1MHz, the config tools would issue a warning.

    I do not see much point in P2 hosting such a tool, as that presumes the P2 has a display connected, plus a file system, plus keyboard....

    Certainly, a Good P2 Debug could display the results of any config, as well as the bits, but I'd not call that 'runs on P2 itself', even tho the Debug stub will be in the P2, the real work will be done on the PC host.

  • I guess I was thinking of a serial based interface, bit like the P2 monitor, with some extensions (reserved words) for getting the smart pins to do something
  • In P1 to configure a counter we needed 3 lines of PASM code.
    	mov	ctra,ctr_mode
    	mov	frqa,my_frq
    	or	dira,pin_mask
    
    In P2 to configure a smartpin we need 3 lines of PASM code too.
    	pinsetm	sp_mode,#my_pin
    	pinsetx	sp_config,#mypin	
    	setb	dira,#my_pin
    
    Simple.
    We all survived without a configurator in P1, I don't think we need one for P2 either.

    IMHO All that is needed is some little code examples and more importantly some nice diagrams in the docs. :)
  • cgraceycgracey Posts: 14,133
    edited 2016-05-01 06:41
    What might be really handy is a program that lets you set up any smart pin in any mode, and then write values to it, manually, to see what it does. Also, feedback would be appropriately displayed. That would translate right to software know-how.

    There could be simple GUI screens for each mode, where you enter data into little panes, which get formatted and presented into 32-bit configuration values. That would get people understanding the bottom-level behavior very quickly so that they could confidently write software (even copy/paste code snippets to set up pins). This program would be useful anytime anyone wanted to test out a new smart pin mode, or refresh on what the various bit fields did.

    A lot of effort was made to keep things simple and direct, and that should be demonstrated to the user. They need to see that smart pins are no big deal. No smart pin has more than three values to configure and operate it (PINSETM/PINSETX/PINSETY) and all data is returned by an IN bit and a 32-bit value (PINGETZ). Nothing is hidden or black-boxed. It's all explained and is meant to be understood. Maybe we make too big a deal over this because of the complexities we've had to deal with in other chips. There's little belief that anything can actually be simple, anymore.
  • TubularTubular Posts: 4,620
    edited 2016-05-01 06:51
    What if we built pin mode expressions similarly to how we set the clock/crystals in P1? Effectively a small dictionary of words already shifted, so you'd do something like

    pinsetm modePWM+strongHIGH+weakLOW ... , #mypin

    You wouldn't need every possible word, just common ones, and anything you don't include defaults to zero

    edit: I'm not necessarily against a GUI, just looking at a lower level that may be interacted with in a natural way

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    What might be really handy is a program that lets you set up any smart pin in any mode, and then write values to it, manually, to see what it does. Also, feedback would be appropriately displayed. That would translate right to software know-how..

    Sounds good to me, and maybe such a GUI could also report a measurement.
    ie because the pins can so nicely 'clip-onto' other pins, the local P2 stub program / Pin-Mode monitor, could also use an adjacent pin cell to measure the result.

    eg Someone could request NCO, and get a frequency counter report back, or PWM and get a Hi and Lo time reported back, etc
  • jmgjmg Posts: 15,140
    Tubular wrote: »
    What if we built pin mode expressions similarly to how we set the clock/crystals in P1? Effectively a small dictionary of words already shifted, so you'd do something like

    pinsetm modePWM+strongHIGH+weakLOW ... , #mypin

    You wouldn't need every possible word, just common ones, and anything you don't include defaults to zero

    edit: I'm not necessarily against a GUI, just looking at a lower level that may be interacted with in a natural way

    Sure, things like those often go into Device include files.

  • Yes, true.

    Thinking about it more, the closest thing to what I'm thinking is probably the commands of the basic stamp (PWM, BUTTON, COUNT etc). The bus pirate also has some similar interactive serial commands. I'm not familiar enough with either but better start reading

  • MJBMJB Posts: 1,235
    cgracey wrote: »
    What might be really handy is a program that lets you set up any smart pin in any mode, and then write values to it, manually, to see what it does. Also, feedback would be appropriately displayed. That would translate right to software know-how.
    this can be done in few lines of @Peter's Tachyon EXPLORER for P2
  • kwinnkwinn Posts: 8,697
    edited 2016-05-01 13:31
    cgracey wrote: »
    What might be really handy is a program that lets you set up any smart pin in any mode, and then write values to it, manually, to see what it does. Also, feedback would be appropriately displayed. That would translate right to software know-how.

    There could be simple GUI screens for each mode, where you enter data into little panes, which get formatted and presented into 32-bit configuration values. That would get people understanding the bottom-level behavior very quickly so that they could confidently write software (even copy/paste code snippets to set up pins). This program would be useful anytime anyone wanted to test out a new smart pin mode, or refresh on what the various bit fields did.

    A lot of effort was made to keep things simple and direct, and that should be demonstrated to the user. They need to see that smart pins are no big deal. No smart pin has more than three values to configure and operate it (PINSETM/PINSETX/PINSETY) and all data is returned by an IN bit and a 32-bit value (PINGETZ). Nothing is hidden or black-boxed. It's all explained and is meant to be understood. Maybe we make too big a deal over this because of the complexities we've had to deal with in other chips. There's little belief that anything can actually be simple, anymore.

    That's a great idea, particularly for someone like me who does not write software full time. I spend quite a bit of time reading the manual for the less frequently used items like counters and video.

    Even better if it could be accessed from the IDE and it inserted the code based on the values entered into the gui ;-)
  • dMajodMajo Posts: 855
    edited 2016-05-01 14:06
    The ones of you who is familiar with picaxe perhaps has used their wizards. For pwm eg you have a wizard that helps you configure the pwm for a given frequency with a given duty cycle according to the running frequency using real measurement units.
    This wizard insert the instruction, with the right arguments, in the code editor at the cursor location. What is missing is backward functionality eg call the wizard with the highlighted line of code to adjust its parameters/arguments.

    Perhaps just a bunch of wizards for the various propeller functions that can generate pasm/spin/c code at the prompt position in the editor can be enough.
  • kwinnkwinn Posts: 8,697
    edited 2016-05-01 14:42
    dMajo wrote: »
    ....

    Perhaps just a bunch of wizards for the various propeller functions that can generate pasm/spin/c code at the prompt position in the editor can be enough.

    You mean like this? Even better idea ;-)Propeller%20Wizard.png
    467 x 467 - 172K
  • How about a web based knowledge based wizzard that you put in options such as mode ,pin, freq etc that would create either spin, c, forth and pasm then transfer to your system for download to either prop1, prop2 or propx?

    Would be helpfull for lite programers like me! I am probably missing something here in my narrow non programming mind.
  • What Dmajo says makes a lot of sense. It would also a be a great way to introduce people to the P2 instead of just handing them a databook and a assembler to figure things out. That approach worked 30 years ago when IC manufacturers provided little if any support to curious engineers who evaluated their product. Not today when you can get a nice eval board for under $25 and free development suite.


  • jmgjmg Posts: 15,140
    edited 2016-05-01 20:16
    dMajo wrote: »
    Perhaps just a bunch of wizards for the various propeller functions that can generate pasm/spin/c code at the prompt position in the editor can be enough.

    Some call then Wizards, some call them configurators, - same thing, really.
    Most I use operate via the clipboard and/or file save.
    That allows a tag like 'at the prompt position in the editor' to apply to all editors (not just one), and the Prop has a lot of variant editors/IDEs out there, and I see another one is maybe added recently too....

    dMajo wrote: »
    What is missing is backward functionality eg call the wizard with the highlighted line of code to adjust its parameters/arguments.
    That would be nice to have, and could be done various ways.
    However, I could see issues with parsing 'any old user code', but certainly parsing code the configurator generated earlier, should be possible, and even a comment line could be used to give a language independent, Mode & Equation information.
    DisAsm style parsing would be possible - ie extract a purely numeric line, with no symbols or expressions to complicate things.
  • cgracey wrote: »
    What might be really handy is a program that lets you set up any smart pin in any mode, and then write values to it, manually, to see what it does. Also, feedback would be appropriately displayed. That would translate right to software know-how.

    That's the preloaded firmware in the P2's $10 demo board.
  • evanhevanh Posts: 15,126
    Missed a zero off there Brian. ;)
  • dMajodMajo Posts: 855
    edited 2016-05-02 12:29
    jmg wrote: »
    Some call then Wizards, some call them configurators, - same thing, really.
    Perhaps it is only dependant on the language (spoken/read) skill one have. Actually english is my third language and I understand configurator more as an IDE integrated function rather than a code generator. I mean like choosing the target device, configure its built-in peripherals or IO directions and such things some IDEs have. Many time you do not see the results in code even if a header or other included file is generated and then compiled with your source.

    My wizard example is clearly visible in the middle of your code, where the prompt was located prior to its call.

    But you are right, when the terminology is understood, are more or less the same thing.
  • I wish the term Cog was replaced with Core. Several reasons for this, including it would boost perception and give immediate relate-ability to new users. Not to mention it rolls off the tongue much easier than cog which is rather consonant-y.
  • Heater.Heater. Posts: 21,230
    I'm totally with that idea "core" not "cog". I'm a bit down on "HUB" as well. Basically because surely it's best to use common terms that people can relate to immediately.
  • evanhevanh Posts: 15,126
    I can't say that even slightly deterred me on initial skimming.

    And using unique naming is handy for specificity which helps with descriptive clarity. Ha, hows that for big wording!
  • Heater.Heater. Posts: 21,230
    I don't see any big words in your post evanh.
  • I'm not sure if it matters much whether it is COG or CORE. I seem to recall that my main hesitation about the Propeller was the very low amount of code space in each COG. It wasn't obvious to me how one would write any significant code in that little space. That, of course, is no longer a problem with P2 and its hub exec mode.
  • ElectrodudeElectrodude Posts: 1,614
    edited 2016-05-03 19:28
    David Betz wrote: »
    I'm not sure if it matters much whether it is COG or CORE. I seem to recall that my main hesitation about the Propeller was the very low amount of code space in each COG. It wasn't obvious to me how one would write any significant code in that little space. That, of course, is no longer a problem with P2 and its hub exec mode.

    I've never run into a problem with this. I've written things that needed to be big, for which I used Spin, and things that needed to be fast, for which I used PASM. But I've never written anything that needed to be both so big it couldn't use PASM and so fast it couldn't use Spin.
  • David Betz wrote: »
    I'm not sure if it matters much whether it is COG or CORE. I seem to recall that my main hesitation about the Propeller was the very low amount of code space in each COG. It wasn't obvious to me how one would write any significant code in that little space. That, of course, is no longer a problem with P2 and its hub exec mode.

    I've never run into a problem with this. I've written things that needed to be big, for which I used Spin, and things that needed to be fast, for which I used PASM. But I've never written anything that needed to be both so big it couldn't use PASM and so fast it couldn't use Spin.
    I didn't know about Spin when I first looked at the Propeller architecture. I just looked at the instruction set and wondered how a compiled language could be implemented. It didn't occur to me at the time that people would be happy with an interpreter.

  • David Betz wrote: »
    I'm not sure if it matters much whether it is COG or CORE. I seem to recall that my main hesitation about the Propeller was the very low amount of code space in each COG. It wasn't obvious to me how one would write any significant code in that little space. That, of course, is no longer a problem with P2 and its hub exec mode.

    I've never run into a problem with this. I've written things that needed to be big, for which I used Spin, and things that needed to be fast, for which I used PASM. But I've never written anything that needed to be both so big it couldn't use PASM and so fast it couldn't use Spin.
    The Spin interpreter itself is a good example of a program that needs more cog memory to run faster. Chip had to jump through lots of hoops to get the interpreter to fit in cog memory. With more memory it could run much faster, and the code would be much easier to follow.

    I have written some programs, such as a compiler that run quite slow because they won't fit in cog memory. I was able to speed them up by putting snippets of the code in helper cogs that execute from cog memory, but this is a painful process.

  • Dave Hein wrote: »
    David Betz wrote: »
    I'm not sure if it matters much whether it is COG or CORE. I seem to recall that my main hesitation about the Propeller was the very low amount of code space in each COG. It wasn't obvious to me how one would write any significant code in that little space. That, of course, is no longer a problem with P2 and its hub exec mode.

    I've never run into a problem with this. I've written things that needed to be big, for which I used Spin, and things that needed to be fast, for which I used PASM. But I've never written anything that needed to be both so big it couldn't use PASM and so fast it couldn't use Spin.
    The Spin interpreter itself is a good example of a program that needs more cog memory to run faster. Chip had to jump through lots of hoops to get the interpreter to fit in cog memory. With more memory it could run much faster, and the code would be much easier to follow.

    I have written some programs, such as a compiler that run quite slow because they won't fit in cog memory. I was able to speed them up by putting snippets of the code in helper cogs that execute from cog memory, but this is a painful process.
    In any case, the P2 solves all of this with hub exec and keeps the ability to run code fast from COG memory as well.

  • RaymanRayman Posts: 13,797
    Hub exec would be slower though in code that jumps a lot.
    Wonder if you'd notice that in a interpreted language like Spin or JavaScript...
  • Rayman wrote: »
    Hub exec would be slower though in code that jumps a lot.

    This shouldn't really be a problem if jumps are aligned properly and if compilers are told how and when to use if_ conditions.

    It just struck me the other day that the fastest way to do short conditionals, like "if (cond) { ... } else { ... }" and "cond ? a : b" with bodies shorter than 16 or so instructions would be to test the condition, get the result into z or c, and then if_z or if_nz all of the following instructions.
  • evanhevanh Posts: 15,126
    HubExec branching will always cause a FIFO reload, I believe, a branch effective issues a RDFAST to redirect the FIFO. The FIFO pre-fetchs a rotation ahead and has no internal addressability. The Cog must accept everything the FIFO feeds it consecutively, or issue a reload.
Sign In or Register to comment.