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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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?
Comments
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.
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
My favorite so far.
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.
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.
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.
TAQOZ, fastspin, and p2gcc all use some status variables in the low part of HUB memory:
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.
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.
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.
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.
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.
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.
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
On that topic I think we need some low level APIs for interfacing with the pins. I'll propose:
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.
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] #endifEdit 3:
Would it make sense to have this support pin ranges as is possible in SPIN for prop1?