Reserving pins for future use

[Fred]

How is it a liability, I don't understand.

[KW1252]

If the said functions are to be adopted as FreeEMS spec in the future without assigned pins, they will need jumper wires to connect to the CPU, and the pins must then be manually configured in the software. For a piece of hardware that's more or less the same for everyone that's not a benefit. It adds a weak point in mechanical and electrical sense, and unnecessary configuration steps.

If it's not going to be included into the spec OTOH, then I guess it's nobody's business how one should set his hardware.

[Fred]

I envisage a situation where the software doesn't care which pins and modules are used and it can just be setup however. Then for each hardware design, various things are included, or not, and a configuration provided for the pin/accessory setup and just loaded and modified along with the hardware, if desired. Does that make sense? In the short term, yeah, some sort of "use this for that" guide would be good, as the abstract stuff isn't written yet.

[KW1252]

By software I actually meant firmware - but it'll be absolutely fantastic if the MCU is going to run software on top of kernel/firmware. Hardware abstraction layer will make many things much smoother and easier. The software doesn't need to know the hardware, it only needs to access the interface provided by the kernel.

However, like said, HAL needs to be adjusted for each physical layout. This is exactly the situation I really don't want to happen, a repository full of different configuration files for kernels of different HW forks (that are essentially the same, just shuffled around a bit). It will be a confusing mess, and it will put people off. Different kernels should be used only for truly substantial changes, like for different platforms.

There should be a reasonable number of pins available for hardware experimentation, and withing this area the designers have quite free reigns, limited by the MCU itself of course. These pins would be accessed through the HAL too, perhaps as symbols, and controlled by software drivers. Outside the sandbox there should be some pins reserved for future use, and defined pins for modules the kernel would offer as services through the software interface. Going laissez-faire won't help here; either there is a feature or there isn't, but it shouldn't be randomly placed. Also there are various buses that shouldn't be forgotten when planning for expansions and enhancements to the system.

[Fred]

The HAL won't be anywhere close to as extreme as you describe it, it will just be a registry of available IO and accessor functions for them in a way that functions pass in an ID and get an error or not when trying to do things. I meant firmware when I said software, apologies for the more general/broad term.

[KW1252]

I wonder though, would it be possible though to executable code uploaded onto the memory without having to reflash the firmware? It'd have long-term benefits if it was.

[jbelanger]

I wonder though, would it be possible though to executable code uploaded onto the memory without having to reflash the firmware? It'd have long-term benefits if it was.

That's kind of what the bootloader does. But that requires self-sufficient code at a fixed address, a dedicated block of flash and a known stable interface. And it may be tricky to get the compiler to do what you want with a piece of code (or not).

Jean

[Fred]

The practical truth is, that for that to work, the var locations etc inside the code would need to remain static. Now, I'm all for interfaces and them being static, but any static interface is a restriction in a straight jacket like way. Which INTERNAL to the code is the last thing you want. You couldn't add an arbitrary var in an arbitrary struct position and have older binaries keep working. Telling the compiler where to put things isn't a big deal. Function pointers aren't a big deal either. It's not going to happen for a large number of other reasons, though.

[Fred]

http://issues.freeems.org/view.php?id=190 For reference.