Raspberry Pi 3 Model B GPIO 40 Pin Block Pinout

No criticism intended. I am simply trying to say that as you go closer to the hardware there will always be more issues with compatibility, it is inevitable

There are always a few exceptions that need the lower level access but for the general populous this is not true, writing high performance real time apps, Timing Critical, Device Drivers and the like.. then sure but most folks don't do that

Even with Windows there are now a select few that work in the HAL (Hardware Abstraction Layer) or lower but most programmers simply talk to the API's and are strongly encouraged to do so

It is a very different skill set to design to talk to hardware than writing a higher level app, You know this, I know this as do many of our TM's and some other community members

Somewhere under the covers of the PI startup routines there will be decisions that direct the stack based on detected hardware, it may not be in the config.txt but it will be there somewhere, otherwise the current Jessie (Feb 29 2016) would be a pointless addition with the exception of adding the wireless drivers as it would still all be 32 bit. It would be a sad day to celebrate the birthday by only adding wireless with the release of their first 64bit platform ??

to your point about things like /dev/ttyAMA0 no longer going to the same physical pins on the GPIO is an excellent example of where the designers have failed, at this level the link should still work, what could change is the BCM pins that are used and this is where the driver / API or what ever (fs) in linux it is should hide this change. The logic name like ttyAMA0 or ttyS0 should always result in the same connector pins being used, what happens in between... who cares (For most of us that is), the memory or IO location can be completely different but this is transparent to the developer and user

rew I think at the end of the day we are saying the same thing but from a different perspective, I may not be using the right words from a Linux perspective (I'm a long time windows programmer and support engineer). I dont regard using the file system "fs" access mechanisms as a hardware access, rather an abstracted API of sorts.

Regards

Peter

Both rewand Robert Peter Oakeshave good points. But the compatible issue needs to hide hardware differences down to the lowest level. The GUI/interface needs to be clean. If you go to lower levels I expect less compatible results. The hardware will be different and needs to be documented for the electrical engineers because electrons know nothing about software.  Are you listening, RPF(Eben Upton)?

Clem

The config files DO NOT reconfigure themselves. My /boot/cmdline.txt still mentions ttyAMA0, while the running kernel says that it was started with ttyS0 in that place in the commandline.

You are vaguely criticizing me for accessing the hardware when I'm going through the provided driver: /dev/ttyAMA0. The problem is that on RPI3 /dev/ttyAMA0 seems to refer to different pins than on previous raspberries.

If instead of having the VC patch the kernel commandline on booting, the foundation would promote a "compatiblity" script somewhere in the startup, that would create a compatibility link, then it would be POSSBILE to cleanly upgrade software that runs into an unexpected compatibiltiy issue like this.

Now, software running under Linux that needs to access the serial port connected to its hardware on the GPIO pins needs to detect if it is running on a PI3, and then use /dev/ttyS0 whereas on older pi's it needs to use /dev/ttyAMA0. Concentrating such hardware dependencies in an abstraction layer is exactly what this is about.

A year ago, nobody could suspect that the serial port on /dev/ttyAMA0 would now no longer refer to GPIO14/15 on the GPIO connector. So software will rightfully refer to /dev/ttyAMA0. Having those symlinks would have allowed an easy upgrade, but lacking that software that you want to "just work" will have to figure out that it's running on an RPI3 and then use ttyS0 instead of ttyAMA0.

And about 32-bit to 64-bit upgrades, let me state that Intel has made it possible for software to "not know" that the processor has started supporting newer features. The i386 has always been able to run 8086 software that was not aware of the "new" i386 features. THATs upward compatibility.

Ah the joys of working at the Hardware level.

This is why we have abstraction layers and encourage folks to use them rather than the hardware

Talking to a /dev/ttynnn keeps you away from the hardware and will keep compatibility even between completely different vendor hardware, same goes for GPIO Pins, I2C, SPI etc

So if a developer tried to do hardware level control they will almost ALWAYS have issues when the chips change even a little, never mind from 32bit to 64bit etc.

In general people should avoid coding to the hardware and stick to the compatibility layer

Why is Wiring and the Arduino IDE so popular... because it hides all the nuances of the real hardware and adds a sense of compatibility even between very different MPU's

The config files could at first startup re-configure themselves to suit the detected chip set though... this is not new and a relatively common practice