P2 Proposed standard pin names and some common pin numbering - FAILED :(
Cluso99
Posts: 18,069
I want to propose we use some standard naming before we get too far in.
Update 2021-03-14: Use COPI/CIPO instead of MOSI/MISO
Jon proposed a compromise to use PGM_RX/PGM_TX so I have updated to reflect this.
I know some of you are already using other pin names, as am I. But let's get this sorted real quick please 
There will be some discussion regarding the DI and DO pins for the SPI devices (Flash, SD and LCD/Touch). Please consider this. These pins are named from the device end and is common practice, as you can see in Chip's ROM Boot specs. Also, they have been used commonly on the P1 for more than a decade. Secondly, if you look at a plugin pcb, the pins are labeled from the device, so you will see on LCD boards DI/DIN as input to LCD board and DO as output from LCD board.
The serial boot pins on P1 have always been at issue. I named them SI and SO being Serial In to the P1 and SO being Serial Out, but I note that I am possibly the only one to do this. Serial has traditionally been with respect to the connector so that TXD connected to RXD and RXD connected to the TXD. This is actually an RS232 Specification, and a crossover cable was necessary to bypass a pair of modems that were traditionally used.
Anyway, here is my proposal. Note some pins are shown that would be changed by the user when configuring them for use on a particular board.
Can we agree, or agree on an alternative?
```
'' +---------------------------------------------------------------------------+
'' | Cluso's P2 Common Pin Definitions V?.?? |
'' +---------------------------------------------------------------------------+
'' RR20210310 001 proposed (as used in SD_Driver etc)
'' RR20210314 002 updated to use COPI/CIPO (controller/peripheral)
con { P2 I/O pins }
'' +---------------------------------------------------------------------------+
PGM_RX = 63 { I } '\ SERIAL: Recv pin: P2 programming / debug port
PGM_TX = 62 { O } '/ Xmit pin: P2 programming / debug port
'' +---------------------------------------------------------------------------+
SF_CS = 61 { O } '\ FLASH: Chip Enable pin (shared with SD_SCK)
SF_SCK = 60 { O } '| Clock pin (shared with SD_CS)
SF_SDI = 59 { O } '| Data In COPI pin (to Flash, shared with SD)
SF_SDO = 58 { I } '/ Data Out CIPO pin (from Flash, shared with SD)
SD_SCK = 61 { O } '\ SDcard: Clock pin (shared with SF_CS)
SD_CS = 60 { O } '| Chip Enable pin (shared with SF_SCK)
SD_SDI = 59 { O } '| Data In COPI pin (to SD, shared with Flash)
SD_SDO = 58 { I } '/ Data Out CIPO pin (from SD, shared with Flash)
'' +---------------------------------------------------------------------------+
VGA_HS = +0 { O } '\ VGA Horizontal Sync (4/8 pin group)
VGA_B = +1 { O } '| Blue
VGA_G = +2 { O } '| Green
VGA_R = +3 { O } '| Red
VGA_VS = +4 / -1 { O } '/ Vertical Sync (when using 4 pin group will be group -1)
'' +---------------------------------------------------------------------------+
USB1_DM = +0 { IO } '\ USB D- (use @garryj's code) (must be an even pin)
USB1_DP = +1 { IO } '| USB D+ (must be next odd pin)
USB1_INT = +2 { IO } '| Used to signal between COGs (usually next pin) (cfg)
USB1_LED = +3 { IO } '/ Used for error LED (usually next pin) (cfg)
USB2_DM = +4 { IO } '\ USB D- (use @garryj's code) (must be an even pin) (cfg)
USB2_DP = +5 { IO } '| USB D+ (must be next odd pin) (cfg)
USB2_INT = +6 { IO } '| Used to signal between COGs (usually next pin) (cfg)
USB2_LED = +7 { IO } '/ Used for error LED (usually next pin) (cfg)
'' +---------------------------------------------------------------------------+
' LCD SPI Connector: Adjust pins to suit your P2 board (use -1 if pin not connected/used)
LCD_3V3 = -1 {-1 = no pin} '\ LCD: 3v3 ~59mA or 5V ~113mA (varies) power from power supply
LCD_GND = -1 {-1 = no pin} '| GND power from power supply
LCD_CS = 47 { O } '| Chip Enable pin
LCD_RST = 46 { O } '| Reset pin (can be reset by software)
LCD_DC = 45 { O } '| Data / Command select pin
LCD_SDI = 44 { O } '| Data In COPI pin (to LCD)
LCD_CLK = 43 { O } '| Clock pin
LCD_LED = 42 { O } '| LED backlight enable pin (hi to enable - ~2.4mA)
LCD_SDO = 41 { I } '/ Data Out CIPO pin (from LCD)(not used?)
LCD_TCLK = 40 { O } '\ Touch: Clock pin
LCD_TCS = 39 { O } '| Chip Enable pin
LCD_TDIN = 38 { O } '| Data In COPI pin (to Touch)
LCD_TDO = 37 { I } '| Data Out CIPO pin (from Touch)
LCD_TIRQ = 36 { I } '/ Interrupt (from Touch)
'' +---------------------------------------------------------------------------+```
Let the discussion begin 
Comments
SPI peripherals on most microcontrollers use MISO and MOSI as the data lines. Master In Slave Out and vice versa is a little less ambiguous.
I do agree an using TX/RX with DTE convention, though.
For somebody who posts Quick Bytes and has the setup of the circuits from every single effort, I really like this idea.
I'm 100% behind this concept for some common peripherals.
@JonnyMac get a look.
Ken Gracey
This is a good idea and possibly the New Program P2 template could be defaulted to this. The actually names should make sense but setting a standard
is higher priority. Possibly this could lead to a program guideline for naming convention, subroutine call procedure, etc.
Regards
Bob Drury
Times are a changing... https://eetimes.com/its-time-for-ieee-to-retire-master-slave/#
Yes, it's easy to change words that then end up taking on new meanings anyway and so they need to be changed again and so on. The word "special" used to be special but then it was applied to "special" people, and now using that special word is derogatory.
Totaliterrorism here we come.
Changing hearts and minds can't be achieved by rule of law which only creates a "be careful how you speak or you will get sued or lynched" mentality anyway. Ooops! maybe I've said too much
Its a pity they missed the opportunity to fix this with the I3C standard that blends some benefit of I2C and SPI
I wonder whether they couldn't come up with alternative words starting with 'M' and 'S' - main / sensor for instance
The flux in what was "right" to what now ain't in the English language is a never-ending saga. But the one that I totally fail to understand is the morph of "handicapped" to "disabled." The former term refers to those with challenges that can be overcome; the latter to those with challenges that can never be -- as if those to whom the term applies are doomed to fail, despite their best efforts. To me, "disabled" is demeaning, compared with "handicapped."
Honestly, though, I'm torn over the master/slave stuff. On the one hand, it's neutral, since it doesn't refer to people but to electronic devices. On the other hand, it does conjure up the image of a fraught period in American history -- one that we rightfully need to be sensitive to.
I'm not sure that controller/responder is the answer, though: too many syllables. It needs to be more concise.
-Phil
boss/lackey
Maybe the word "bit-bashing" will become offensive to some and conjure up violent memories?
Maybe the word "micro controller" conjures up memories of my dear other half?
I was thinking of maybe incorporating other languages, e.g. German. But über/unter both use the same letter. Drat!
Might master/serf be less offensive?
-Phil
brains / braun
Client/Server but maybe there's a patent???
Reminds me of the complaint in the 90's about the use of man in unix. All these man xxxx things have got to be fixed says a person. Said receiver of the complaint offered to let said complainer fix all the references to which there are thousands or millions. BTW man stands for manual.
If only we had #include. In P1 I used #include _hwdef to include basic P1 definitions when using the bst compiler. I am not looking forward to going back and changing my I/O pins in my P2 programs because I didn't totally get my own standards working from the get-go.
I would vote for master/journeyman/apprentice; master = master, apprentice = slave, and journeyman = can be either / or / both. Have no problem with master remaining as is. Or bring it to the organizational level and call them boss/worker (less harsh than lackey).
ouchh..... my head hurts exploded.
Leader / follower would have been my preference, but that ship has sailed.
Somebody else got to SDI / SDO first.
https://www.sparkfun.com/spi_signal_names
Hey Phil,
your german example could still fly, Hoch vs Platt (high versus low) german language. Or of course, Knight/Page (wasn't he the knights sl.. I mean gopher?) AS to the "man"page issue, __________ (supreme being of your/no choice here) only (may) know what will happen to all non-english western languages, all are so dependent on noun gender, guess they will all need to be dumped.
@"Peter Jakacki" regarding " special" here in the states that is the preferred term to use. The re- word is the most highly offensive word. But a label is still a label. The slogan of the school my son attended was "At ACCEL my son is just Andy".
Bleeehhhhh, up way to late tonight........... On a positive, got PropTool up in Win7 on linux in VirtualBox tonight......
C'mon, this "ban offending words" discussion is ridiculous. Who is offended? We are talking about devices, not persons. I find it totally acceptable to call an IC "slave". To outlaw the use of the word doesn't make anything better. What sense does it make to replace a word that everybody understands with something more complicated?
Amen !
+1
Mike
Just use servant instead of slave...
For spi there’s all kinds of options...
Owner-User
Change master and slave to manager and servant. Keeps the MOSI/MISO initials, minimal confusion.
Maybe Sparkfun has a good idea.
Wonder is anybody else is following that...
How about “Management & Labor”?
Deleted!
(seemed to offend some)
@Ariba, was just kidding about the O2, hard to get across in text.. sorry. edited out. Did not intend for you to change avatars to the randomly impersonal ones.... My bad.
But we could always go biological with host and parasite... (?? political = citizen and government??)
Moderators can stand down.....
Careful guys.
How about major / subordinate?
Dom & Sub
(this could quite possibly bend some sensibilities to a point where maybe leaving well enough alone has merit. When the machines have a say, I vote we revisit all this then.)
Lol, I will show myself out, but as I go back to the grindstone, in my defense the suggestions just triggered it, and so... yeah! There it is from your pal Spud.
Greetings everyone! I will be back to play soon.
You know we are really trashing Cluso's thread
We have controller chips and we have peripheral chips. What's wrong with using terms we already use, that is, if we really have to use alternative terms, which I am not in favor off anyway.
Controller/peripheral
The standard I and O suffix make it clear that it is Inputting or Outputting but a peripheral should use its own terminology so that it has a PDI which would connect to a CDO etc.
or Micro/Peripheral ?
But yes, this stuff is ridiculous. We've been down this path many times before. Manhole cover is now Inspection Point, chairman is now chairperson - what was wrong with madam chairman.
Just created lots of jobs to change everything.
Children's books Noddy and Bigears was banned in the 80's because they were gay (you're kidding right?). Now they're in vogue. Next they will be trying to change the black and white colors on our monitors. Do you just change their names, or do you have to change the colors too ???
Anyway, the only real discussion to my thread is whether, from the P2 end, is it SD_DO or SD_DI for the input (and visa versa) ??? P1 always has been SD_DO because when you specify the pins for the SD Driver, you specify the pins at the SD end, so the output from the SD (DO) is specified.
https://www.oshwa.org/a-resolution-to-redefine-spi-signal-names/
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