 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : I/O Pin Numbering
| Author | Message | ||||
panky Guru  Joined: 02/10/2012 Location: AustraliaPosts: 1116 |
/start of rant This is a follow-on from the Pin(0) problem post and I am sure I will get hammered from all but I have to say that having the i/o pin numbering vary from chip to chip is an absolute dog's dinner (IMHO). I have nothing but the utmost respect and admiration for the fantastic product Geoff has created - as you can see from the bottom of this post, I have one of almost all variants - it's just this one issue that concerns me. The current system of i/o pin numbering being tied to the chip pins makes porting an i/o intensive program from a maximite to a 150 for example, a time wasting exercise. But wait, there's more! Now I need to go to a 28 pin 170 for whatever reason so I need to go through the exercise all over? Some one else loves my program but they have the 44 pin 170 - more heartache! Let's have some more pain and port my program to a 470 or an ARMmite!!! And just to make it worse, the analog and digital i/o's on the micromite chips are not designated as 1, 2, 3 etc. so I can't even embed a port map (at least not without a great deal of effort and time). With the maximite, minimite and colour maximite, at least the 20 pins on the GPIO were common. If it was a space issue with the micromite series, there are any number of commands I would happily forgo to keep pin numbering consistent, at least for the GPIO. Sorry Geoff, but this is a very limiting issue with an otherwise fantastic product! /end of rant Respectfully, panky. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Never ever ever ever ever! hardcode pin numbers in your program unless it is a few lines long. Define the pins used first at the start of the program. Then moving it to another chip, it is just adjusting those defines and you are done. Few minutes work to port a existing program. For example if you have a temperature sensor on a pin 4: [code] TempSensor = 4 Temperature = pin(TempSensor) [/code] You would only need to change the pin number in one single location, preferably at the top, to port it to another chip. Microblocks. Build with logic. |
||||
| panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1116 |
@TZAdvantage, I understand and agree TZ but if multiple digital in, digital out and analog ports are being used in a particular program, it becomes a much more complex issue of deciding which pins to allocate to which tasks. This also greatly complicates board layout for someone trying to impliment my program on their board. panky ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9641 |
I feel your pain, panky. 
Yet, I agree with TZA. YES - it is a real pain if you find yourself in the situation you seem to be in, in that you need to port some code from one flavour to another in the series, but that is where defining the pins can be exceptionally helpful. I used to hard-code all my pin numbers, but any code I write now, I try to get all pins into variable names so if you DO have to move code across, as TZA says, all you have to do, is change the top chunk of code where these things are normally defined. Of coarse, if you have not done that, and hard-coded all the I/O pin references, then other then find/replace for each pin number, there is not much else you can do but plod through the code and change it all to what is needed. As for the actual pin numbering on MMBASIC vs the chips - I thought that WAS pretty much standard. Pin(2)=1 will set pin2 high on all the micromite chips and the Maximites I/O connector too, so I figured that it was already pretty standard in that respect...  Not sure about the ARMmite, but I would be surprised if it was any different.(read: Pin(2)=1 on the ARMmite should also set it's pin2 high)
Perhaps I am missing something? Smoke makes things work. When the smoke gets out, it stops! |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3303 |
That was a great "rant". I am afraid I had a laugh and then felt guilty about the frustration that you felt. The real question is... what would you suggest as the solution? I chose the physical pin numbers because it was easy to relate the program to the physical chip. I guess that I could have arbitrary numbered the I/O 1, 2, 3, etc but then you would need to lookup a chart to see what the corresponding physical pin number was. But that would not address your issue of moving the program from chip to chip either because each chip has a different number of analogue pins, 5V pins, etc. So each I/O number would have different characteristics from chip to chip. As TZ said, you should define the pins as constants. Something like: CONST InputPin = 26 CONST OutputPin = 2 etc This also has the advantage of making it clear what the pin does. Geoff Geoff Graham - http://geoffg.net |
||||
| panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1116 |
Thanks Geoff, I appreciate the response and understand your reasoning. Thanks again for a wonderful job with MMBasic. panky. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
