While I will agree that things could be better defined, one should not let angst over the past blind us to the present. These terms are at best irritants in the evolution of electronics, hardly noticed before the current politicization of nearly everything now. Question for all, next time you are at a hospital, or similar place, check the bathroom walls (no, not for graphiti) for the poster in multiple languages informing users that if they are, or know of someone who is a victim of human trafficking (reads slavery to me in any definition you could imagine) of a hotline to call for help. Anyone can gripe about a word, but ask yourselves "What have I done to promote this practice?" Do I buy from a sweatshop, do you know someone who keeps H1Bs on a short leash with threats of revoking same if not cooperative, underpaid, etc. This stuff tends to creep out of the woodwork quietly and with little notice. Something to think about......
I am sorry, but the OSHAWA does not say to use SD_DI and SD_DO the way you guys are interpreting it.
This is a definition for schematic design. Notice the lack of the prefix "SD_"
Now, for software, we usually use Equate to equate a label such as SD_DO to a pin number.
Here, as in my definition in the first post, we are equating the SD pin SD_DO to the P2 pin P58. We are equating the SD output pin DO to the P2 input pin P58.
Guess what guys, we've been doing this on the P1 since 2007 with Rokicki's SD card FAT file system driver.
We better have a reallly good reason to change, since what we're doing is reversing the input and output pins on P2 to what we have been doing for 14+ years on the P1. Sounds like a recipe for disaster.
I believe this is the best solution. Parallax is a member of the OSHWA (maybe lapsed, but I'll bring it current) and listed the first open-source microcontroller with them. My view is that we'll likely never agree on the same terms, that the issue with master/slave naming is relevant, should be dealt with for both social and business purposes, and that a reasonable proposal was made by the OSHWA.
We have so much to achieve to bring the P2 to a larger audience. We've got a really solid community with skilled and effective contributors, and the naming issue is a little barrier we could simply remove. At this time, anything is possible with our community but some things are only more difficult to change later. We collaborate, share code, solve problems, build tools, and enjoy our common interests.
Can somebody ratify this motion to use as much of the OSHWA naming as appropriate?
The next step could be @Cluso99 , @JonnyMac and others create the final nomenclature list, post it here, and adopt it into templates and examples. We can update past examples as time permits.
Ken Gracey
Yes, as much as is appropriate.
However, as I stated, the OSHAWA reference is related to schematics. Sure you could use them in software too.
But we have a history conflict here.
All the P1 code since at least 2007, Rokicki's SD card FAT file system driver, as used in FemtoBasic, and in 2010 Kye's SD FAT_Engine, and in my P1 Prop OS.
And in P2 we start with Chip's ROM code, followed by my SD Driver (I haven't checked the Flash programming code) using the same basics.
Jon is using the OSHAWA definition for schematics applied to software.
And this is the problem. SDO has been used in P1 and P2 for the prop input pin and SDI has been used for the prop output pin.
Jon is using SDI in P2 for the prop input pin and SDO for the prop output pin.
It has been suggested that my list is too long. It can easily be split into groups. I just wanted the naming to be a standard instead of some using for example "VGA" while others used "Video" or whatever. It would be nice for the different objects to use the same conventions.
It's American history that has caused the controversy over the naming conventions MOSI and MISO. That is to say just because it was done in the past doesn't mean it has to be done in the future.
Jon is using the OSHAWA definition for schematics applied to software.
I didn't know that, but in my own work, I use [Propeller-centric] net names as pin names where appropriate.
SDO has been used in P1 and P2 for the prop input pin and SDI has been used for the prop output pin.
Not by me. And I submit that those who did that caused a great deal of confusion for newcomers -- a pin labelled "O" for output is configured as an input?
I consider myself an advocate for new Propeller programmers and have worked very hard to use a clean, organized, non-intimidating code style that has been published dozens of times in Nuts & Volts and other magazines. I get a lot of really nice email. The last thing I want is someone asking me why an input pin is labelled like it should be an output.
My pin naming conventions are consistent with the RX and TX pins for the programming port that we all seem to agree on; RX is an input; TX is an output. To my simple mind, a pin that is configured as an input should have a name that reflects that behavior. FTR, I have changed the default names of my programming/debug port pins from RX1 and TX1 to PGM_RX and PGM_TX. I don't mind this change because it matches my general convention for pins: on the left side of the underscore is the subsystem or device, on the right of the underscore is the Propeller-centric function of that pin.
In my (new) P1 template:
con { fixed io pins }
PGM_RX = 31 { I } ' serial / programming
PGM_TX = 30 { O }
EE_SDA = 29 { I/O } ' i2c / eeprom
EE_SCL = 28 { I/O }
In my (new) P2 template:
con { fixed io pins }
PGM_RX = 63 { I } ' programming / debug
PGM_TX = 62 { O }
SF_CS = 61 { O } ' serial flash
SF_SCK = 60 { O }
SF_SDO = 59 { O }
SF_SDI = 58 { I }
SD_SCK = 61 { O } ' sd card
SD_CS = 60 { O }
SD_SDO = 59 { O }
SD_SDI = 58 { I }
LED2 = 57 { O } ' Eval and Edge LEDs
LED1 = 56 { O }
IMO using DO/DI, TX/RX or any similar one-sided terms is terrible and if you do it you open pandora's box of infinite confusion. Use MOSI/MISO or COPI/CIPO or whatever, please.
I always (and I really mean a.l.w.a.y.s. ) get confused when the one-sided names are uses.
Context dependent. Look at the history of serial communications. You know what you think you know then someone asks if the port is DTE or DCE... As Jon has said so many times, inconsistency will jack your code first chance it gets.
Regarding the of Tx and Rx. I have been using the convention for decades now that I name pins as seen from the device. So a Tx pin on a device is an output. It morphs to an Rx pin at the other end.
You have not failed to try Cluso so there is no failure in that. But wouldn't it be better to post your latest definitive naming convention for reference. Then it is there as a guide to those who will use it.
@"Peter Jakacki" said:
You have not failed to try Cluso so there is no failure in that. But wouldn't it be better to post your latest definitive naming convention for reference. Then it is there as a guide to those who will use it.
Comments
While I will agree that things could be better defined, one should not let angst over the past blind us to the present. These terms are at best irritants in the evolution of electronics, hardly noticed before the current politicization of nearly everything now. Question for all, next time you are at a hospital, or similar place, check the bathroom walls (no, not for graphiti) for the poster in multiple languages informing users that if they are, or know of someone who is a victim of human trafficking (reads slavery to me in any definition you could imagine) of a hotline to call for help. Anyone can gripe about a word, but ask yourselves "What have I done to promote this practice?" Do I buy from a sweatshop, do you know someone who keeps H1Bs on a short leash with threats of revoking same if not cooperative, underpaid, etc. This stuff tends to creep out of the woodwork quietly and with little notice. Something to think about......
I am sorry, but the OSHAWA does not say to use SD_DI and SD_DO the way you guys are interpreting it.
This is a definition for schematic design. Notice the lack of the prefix "SD_"
Now, for software, we usually use Equate to equate a label such as SD_DO to a pin number.
Here, as in my definition in the first post, we are equating the SD pin SD_DO to the P2 pin P58. We are equating the SD output pin DO to the P2 input pin P58.
Guess what guys, we've been doing this on the P1 since 2007 with Rokicki's SD card FAT file system driver.
We better have a reallly good reason to change, since what we're doing is reversing the input and output pins on P2 to what we have been doing for 14+ years on the P1. Sounds like a recipe for disaster.
What I object to in that resolution is this nonsense
Is that what we were doing? Really? I am really glad I'm now a Woke Bloke
Yes, as much as is appropriate.
However, as I stated, the OSHAWA reference is related to schematics. Sure you could use them in software too.
But we have a history conflict here.
All the P1 code since at least 2007, Rokicki's SD card FAT file system driver, as used in FemtoBasic, and in 2010 Kye's SD FAT_Engine, and in my P1 Prop OS.
And in P2 we start with Chip's ROM code, followed by my SD Driver (I haven't checked the Flash programming code) using the same basics.
Jon is using the OSHAWA definition for schematics applied to software.
And this is the problem.
SDO has been used in P1 and P2 for the prop input pin and SDI has been used for the prop output pin.
Jon is using SDI in P2 for the prop input pin and SDO for the prop output pin.
It has been suggested that my list is too long. It can easily be split into groups. I just wanted the naming to be a standard instead of some using for example "VGA" while others used "Video" or whatever. It would be nice for the different objects to use the same conventions.
It's American history that has caused the controversy over the naming conventions MOSI and MISO. That is to say just because it was done in the past doesn't mean it has to be done in the future.
I didn't know that, but in my own work, I use [Propeller-centric] net names as pin names where appropriate.
Not by me. And I submit that those who did that caused a great deal of confusion for newcomers -- a pin labelled "O" for output is configured as an input?
I consider myself an advocate for new Propeller programmers and have worked very hard to use a clean, organized, non-intimidating code style that has been published dozens of times in Nuts & Volts and other magazines. I get a lot of really nice email. The last thing I want is someone asking me why an input pin is labelled like it should be an output.
My pin naming conventions are consistent with the RX and TX pins for the programming port that we all seem to agree on; RX is an input; TX is an output. To my simple mind, a pin that is configured as an input should have a name that reflects that behavior. FTR, I have changed the default names of my programming/debug port pins from RX1 and TX1 to PGM_RX and PGM_TX. I don't mind this change because it matches my general convention for pins: on the left side of the underscore is the subsystem or device, on the right of the underscore is the Propeller-centric function of that pin.
In my (new) P1 template:
con { fixed io pins } PGM_RX = 31 { I } ' serial / programming PGM_TX = 30 { O } EE_SDA = 29 { I/O } ' i2c / eeprom EE_SCL = 28 { I/O }In my (new) P2 template:
con { fixed io pins } PGM_RX = 63 { I } ' programming / debug PGM_TX = 62 { O } SF_CS = 61 { O } ' serial flash SF_SCK = 60 { O } SF_SDO = 59 { O } SF_SDI = 58 { I } SD_SCK = 61 { O } ' sd card SD_CS = 60 { O } SD_SDO = 59 { O } SD_SDI = 58 { I } LED2 = 57 { O } ' Eval and Edge LEDs LED1 = 56 { O }IMO using DO/DI, TX/RX or any similar one-sided terms is terrible and if you do it you open pandora's box of infinite confusion. Use MOSI/MISO or COPI/CIPO or whatever, please.
I always (and I really mean a.l.w.a.y.s. ) get confused when the one-sided names are uses.
Context dependent. Look at the history of serial communications. You know what you think you know then someone asks if the port is DTE or DCE... As Jon has said so many times, inconsistency will jack your code first chance it gets.
Regarding the of Tx and Rx. I have been using the convention for decades now that I name pins as seen from the device. So a Tx pin on a device is an output. It morphs to an Rx pin at the other end.
Unfortunately this thread failed miserably.
Probably should have guessed as much.
At least I tried!
You have not failed to try Cluso so there is no failure in that. But wouldn't it be better to post your latest definitive naming convention for reference. Then it is there as a guide to those who will use it.
I agree.