Language Agnostic API for P2 HAL Implementations

2»

Comments

  • Just because we have names like API and HAL doesn't mean we have to include them in our name, but we could....

    PAL = Parallax Abstraction Layer

    All we need is a name and it helps if it is an acronym because that is also a mnemonic for what it does, it's an abstraction layer for Parallax processors.


    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    --->CLICK THE LOGO for more links<---
    P2 +++++ TAQOZ INTRO & LINKS +++++ P2 SHORTFORM DATASHEET
    P1 +++++ Latest binary V5.4 includes EASYFILE +++++ Tachyon Forth News Blog
    Brisbane, Australia
  • I was thinking a while ago to use TAQOZ as language independent API, by allowing to call TAQOZ as independent Subsystem, sending and receiving strings.

    That could be easy integrated into any language. Sadly my idea did not got traction before the new rom was made, since Peter could not understand the usefulness of this approach, even if he said a mailbox for TAQOZ would be easy to implement.

    Now one has to include a changed TAQOZ image into every program trying to do so and the idea of a known TAQOZ status, a known TAQOZ mailbox and a known TAQOZ wordlist (because in ROM) is moot.

    This would have given a common way to integrate TAQOZ into any other language and would have given not just a API but the implementation of it too. And a OBEX for TAQOZ snippets usable from everybody, his dog and his favorite language.

    I will need to wait for the next chip to see if I still be able to patch the ROM like I did with the P2ES ROM. But since TAQOZ is compressed in the ROM it will be much more complicated.

    As for definition of types in the PAPI I am more on eric's side here, PASM/PASM2 does not really have the concept of types, except maybe bit/byte/word/long, same goes for SPIN/SPIN2 even if eric does some nice work to allow function pointers and multiple return values the common subset of types available in PASMx/SPINx/BASIC/C/C++/ is quite small.

    Sure more types allow for more compile time checks but me thinks it belongs into the higher level of code, not into the HAL.

    As stupid as I sound, after some time thinking about it, I really like the Idea of Pins.spin2 out of the demo files. Just getting away with PORTA/B for a cleaner view in source, thinking and movability.

    As for the version numbers I think we should start at 1000 and increment by 1000 and do not allow for more then 8 version changes.
    First of all do get it done and stable and second of all we would end up with HAL 9000.

    Enjoy!

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Just because we have names like API and HAL doesn't mean we have to include them in our name, but we could....

    PAL = Parallax Abstraction Layer

    All we need is a name and it helps if it is an acronym because that is also a mnemonic for what it does, it's an abstraction layer for Parallax processors.

    My favorite so far.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • msrobots wrote: »
    I was thinking a while ago to use TAQOZ as language independent API, by allowing to call TAQOZ as independent Subsystem, sending and receiving strings.

    That could be easy integrated into any language. Sadly my idea did not got traction before the new rom was made, since Peter could not understand the usefulness of this approach, even if he said a mailbox for TAQOZ would be easy to implement.

    Now one has to include a changed TAQOZ image into every program trying to do so and the idea of a known TAQOZ status, a known TAQOZ mailbox and a known TAQOZ wordlist (because in ROM) is moot.

    This would have given a common way to integrate TAQOZ into any other language and would have given not just a API but the implementation of it too. And a OBEX for TAQOZ snippets usable from everybody, his dog and his favorite language.

    I will need to wait for the next chip to see if I still be able to patch the ROM like I did with the P2ES ROM. But since TAQOZ is compressed in the ROM it will be much more complicated.

    As for definition of types in the PAPI I am more on eric's side here, PASM/PASM2 does not really have the concept of types, except maybe bit/byte/word/long, same goes for SPIN/SPIN2 even if eric does some nice work to allow function pointers and multiple return values the common subset of types available in PASMx/SPINx/BASIC/C/C++/ is quite small.

    Sure more types allow for more compile time checks but me thinks it belongs into the higher level of code, not into the HAL.

    As stupid as I sound, after some time thinking about it, I really like the Idea of Pins.spin2 out of the demo files. Just getting away with PORTA/B for a cleaner view in source, thinking and movability.

    As for the version numbers I think we should start at 1000 and increment by 1000 and do not allow for more then 8 version changes.
    First of all do get it done and stable and second of all we would end up with HAL 9000.

    Enjoy!

    Mike

    The ROM Monitor can read and write strings, hex, etc. There is a defined interface for it to call within your programs. I am doing it almost every day.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • There was some discussion in another topic about having some system variables reserved like what the Prop1 had. Namely the system clock frequency. I don't know what came of that discussion, it didn't affect me at the time.

    However, it's been discovered that knowing the pre-existing config of the sysclock is a necessity for reliable operation. Not the frequency but the whole config word. See https://forums.parallax.com/discussion/169838/p2-reset-possible-problem/p6

    The reserved variables needs some immediate attention.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • Cluso99 wrote: »
    msrobots wrote: »
    I was thinking a while ago to use TAQOZ as language independent API, by allowing to call TAQOZ as independent Subsystem, sending and receiving strings.

    That could be easy integrated into any language. Sadly my idea did not got traction before the new rom was made, since Peter could not understand the usefulness of this approach, even if he said a mailbox for TAQOZ would be easy to implement.

    Now one has to include a changed TAQOZ image into every program trying to do so and the idea of a known TAQOZ status, a known TAQOZ mailbox and a known TAQOZ wordlist (because in ROM) is moot.

    This would have given a common way to integrate TAQOZ into any other language and would have given not just a API but the implementation of it too. And a OBEX for TAQOZ snippets usable from everybody, his dog and his favorite language.

    I will need to wait for the next chip to see if I still be able to patch the ROM like I did with the P2ES ROM. But since TAQOZ is compressed in the ROM it will be much more complicated.

    As for definition of types in the PAPI I am more on eric's side here, PASM/PASM2 does not really have the concept of types, except maybe bit/byte/word/long, same goes for SPIN/SPIN2 even if eric does some nice work to allow function pointers and multiple return values the common subset of types available in PASMx/SPINx/BASIC/C/C++/ is quite small.

    Sure more types allow for more compile time checks but me thinks it belongs into the higher level of code, not into the HAL.

    As stupid as I sound, after some time thinking about it, I really like the Idea of Pins.spin2 out of the demo files. Just getting away with PORTA/B for a cleaner view in source, thinking and movability.

    As for the version numbers I think we should start at 1000 and increment by 1000 and do not allow for more then 8 version changes.
    First of all do get it done and stable and second of all we would end up with HAL 9000.

    Enjoy!

    Mike

    The ROM Monitor can read and write strings, hex, etc. There is a defined interface for it to call within your programs. I am doing it almost every day.

    yes @Cluso99, I do know that and I really like it very much. And in opposite to TAQOZ one can patch the pins in ROM and it works perfect. At least on the current P2ES. Not sure of the next ROM, I have not looked at it, yet.

    And you forgot the most important part, one can load a file from SD to any HUB location, with and without starting it. Or did that got cancelled in the new ROM?

    curious,

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • O.T.
    msrobots wrote: »
    Cluso99 wrote: »
    msrobots wrote: »
    I was thinking a while ago to use TAQOZ as language independent API, by allowing to call TAQOZ as independent Subsystem, sending and receiving strings.

    That could be easy integrated into any language. Sadly my idea did not got traction before the new rom was made, since Peter could not understand the usefulness of this approach, even if he said a mailbox for TAQOZ would be easy to implement.

    Now one has to include a changed TAQOZ image into every program trying to do so and the idea of a known TAQOZ status, a known TAQOZ mailbox and a known TAQOZ wordlist (because in ROM) is moot.

    This would have given a common way to integrate TAQOZ into any other language and would have given not just a API but the implementation of it too. And a OBEX for TAQOZ snippets usable from everybody, his dog and his favorite language.

    I will need to wait for the next chip to see if I still be able to patch the ROM like I did with the P2ES ROM. But since TAQOZ is compressed in the ROM it will be much more complicated.

    As for definition of types in the PAPI I am more on eric's side here, PASM/PASM2 does not really have the concept of types, except maybe bit/byte/word/long, same goes for SPIN/SPIN2 even if eric does some nice work to allow function pointers and multiple return values the common subset of types available in PASMx/SPINx/BASIC/C/C++/ is quite small.

    Sure more types allow for more compile time checks but me thinks it belongs into the higher level of code, not into the HAL.

    As stupid as I sound, after some time thinking about it, I really like the Idea of Pins.spin2 out of the demo files. Just getting away with PORTA/B for a cleaner view in source, thinking and movability.

    As for the version numbers I think we should start at 1000 and increment by 1000 and do not allow for more then 8 version changes.
    First of all do get it done and stable and second of all we would end up with HAL 9000.

    Enjoy!

    Mike

    The ROM Monitor can read and write strings, hex, etc. There is a defined interface for it to call within your programs. I am doing it almost every day.

    yes @Cluso99, I do know that and I really like it very much. And in opposite to TAQOZ one can patch the pins in ROM and it works perfect. At least on the current P2ES. Not sure of the next ROM, I have not looked at it, yet.

    And you forgot the most important part, one can load a file from SD to any HUB location, with and without starting it. Or did that got cancelled in the new ROM?

    curious,

    Mike
    The monitor did not change and resides in the same hub addresses.
    The SD has small changes so the hub locations (ie calls) differ. You can still load/run a file to any hub address.
    see the Fun with the P2 ROM thread for calling the SD routines directly and the monitor too.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • evanh wrote: »
    There was some discussion in another topic about having some system variables reserved like what the Prop1 had. Namely the system clock frequency. I don't know what came of that discussion, it didn't affect me at the time.

    However, it's been discovered that knowing the pre-existing config of the sysclock is a necessity for reliable operation. Not the frequency but the whole config word. See https://forums.parallax.com/discussion/169838/p2-reset-possible-problem/p6

    The reserved variables needs some immediate attention.

    TAQOZ, fastspin, and p2gcc all use some status variables in the low part of HUB memory:
    $10: reserved (I can't remember what TAQOZ puts here, maybe crystal frequency?)
    $14: 4 bytes current system frequency (e.g. 180000000)
    $18: 4 bytes current clock mode setting
    $1c: 4 bytes preferred baud rate
    

    It sounds like it would be useful for other languages to adopt this convention too. Not sure if this exactly goes in the Parallax Abstraction Layer, but it is somewhat related.
  • Cluso99Cluso99 Posts: 15,076
    edited 2019-03-07 - 10:32:29
    Sounds good to me.
    Hopefully $10 has the xtal frequency and the _XOSC (2 bits) to define OFF/OSC/15pF/30pF in b31:30
    This gives us everything we need to know about the xtal/osc connected if we need to switch frequencies.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • evanhevanh Posts: 7,262
    edited 2019-03-07 - 10:48:13
    Cluso,
    The way I'm reading loadp2's boot-loader is "clock mode", hub address $18, contains everything except the source select, %SS. Source select is assumed to be PLL.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • The full xtal spec (frequency and osc/xxpF setting) will be required.
    If you don’t have that, you cannot make a new setting after it gets changed to RCFAST or RCSLOW as these mode bits will be overwritten.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Yep, all of that is in "clock mode".
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • Soooo.... should this repository even have a "copyright" notice? I certainly want anyone reading it to feel comfortable knowing that they can use this however they want, for free. But... the MIT license template has a copyright notice at the top... should I just delete it? It doesn't feel right to put my name there. Seems cumbersome to put everyone's name in there. Seems wrong to put Parallax there.

    I'm using "Copyright 2019 David Zemon & the Parallax Community" for the time being.

    https://github.com/DavidZemon/ParallaxAbstractionLayer

    I'll write more in the root readme later. Enough for this evening.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • Never played with GitHub pages before... cool :) https://davidzemon.github.io/ParallaxAbstractionLayer/

    I've started sending out invitations to "collaborate" on github. i don't know many peoples' github usernames, so if you didn't get one, don't take it personally. just send me your username and i'll send you an invite.

    I can't enforce pull requests without also enforcing at least 1 review on that pull request... so be it. you must submit have your PR approved by someone (anyone.. maybe even yourself???) before merging.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • MIT Copyright

    1. It's good practice to acknowledge in the source
    2. Perhaps it stops some crank claiming copyright and enforcing it over the MIT license ???
    3. Probably other legal reasons :(
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • First pull request is live! Lets talk about the object hierarchy: https://github.com/DavidZemon/ParallaxAbstractionLayer/pull/1
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • Your proposal for the object heirarchy seems reasonable, although for beginners perhaps "pins" would be a more illuminating name than "gpio".

    On that topic I think we need some low level APIs for interfacing with the pins. I'll propose:
    // old style pin settings
    void pinhigh(int pin); // set a pin to output 1
    void pinlow(int pin);  // set a pin to output 0
    void pintoggle(int pin); // invert current state of an output pin
    void pinset(int pin, int val); // set the value of a pin to 0 or 1
    int pinget(int pin); // get current value of an input pin (0 or 1)
    
    // smart pin settings
    void pinwx(int pin, int xval); // write smartpin x register
    void pinwy(int pin, int yval); // write smartpin y register
    void pinwr(int pin, int rval);  // write smartpin config register
    int pinrdr(int pin); // read and ack smartpin result register
    int pinrdrq(int pin); // like pinrdr, but does not do an ack
    void pinack(int pin); // acknowledge smartpin
    
  • ersmith wrote: »
    Your proposal for the object heirarchy seems reasonable, although for beginners perhaps "pins" would be a more illuminating name than "gpio".

    Anyone else have an opinion on this? I definitely agree that "pins" is intuitive for beginners, but "gpio" is the less ambiguous.

    And Eric, I'll respond to your low level pin suggestions in a bit.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: https://ci.zemon.name?guest=1
  • Stamp and Prop1 conventions is best I think. Blocky or Arduino conventions would be suitable also.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • rosco_pcrosco_pc Posts: 323
    edited 2019-03-15 - 09:44:27
    rpi, UEFI uses gpio
    Arduino/Blockly uses pins.

    For propeller we've always used pins, and since we now have smartpins I think that using pins is better, so +1 for @ersmith proposal.

    Edit: Also like to point out to the propeller 2 wiki, would that not be a better place to have this API specified?
    Edit2: in the wiki is a start of a pins object, which @ersmith made a bit more 'fastspin'ny here. And I suggest to make the following changes:
    PUB High(pin)
      drvh_(pin)
    PUB Low(pin)
      drvl_(pin)
    PUB Toggle(pin)
      drvnot_(pin)
    PUB Set(pin, v)
      drv_(pin,v & 1) 
      ' make sure to only use bit 0 as prop1 code often uses this pattern:
      ' value := 123
      ' repeat 8 
      '   outa[pin] := value
      '   value >> 1
      
    PUB Get(pin) : state
    #ifdef __P2__
      asm
        testp pin wc
        muxc state, #1
      endasm
    #else
      dira[pin] := 0
      waitx_(clkfreq / 10000)
      state := ina[pin]
    #endif
    
    

    Edit 3:
    Would it make sense to have this support pin ranges as is possible in SPIN for prop1?
    Stockholm, Sweden
    I am only an egg -- Stranger in a Strange land, Robert A. Heinlein
Sign In or Register to comment.