Idea for using features to select available hardware

[Phaiax]

Hey farcaller

(this is only an idea, its not for merging)

What do you think about using features to select not only the chip family but to select the available hardware features? The user would use his exact model number as a feature, e.g. mc_mk20dx256vlq10 and the feature system would use the Cargo.toml to select all available hardware parts. (at least the K20 family (and even the Kxx family) are build to be software compatible). It would also use the features to select the appropiate linker scripts using the correct flash sizes.
Also shortcuts for popular boards are possible, e.g. board_teensy. (That is the one I have :D)
This would also allow to use a special pin number assignment for these arduino like boards since their pins are labeled with a different enumerating system.

(I'm using some free time to make my teensy more rust compatible. But maybe you have some Ideas for zinc and no time to implement them / play with them. I would be happy to chat about zinc with you. I'm not yet an expert with all of this, but I am going to be :D)

PS: https://github.com/Phaiax/cargo-teensy

[coveralls]

Coverage remained the same at 90.397% when pulling f5c932c on Phaiax:idea_features into 1ad41f3 on hackndev:master.

[farcaller]

I think it's a bit of a mess and what platform trees were expected to solve: https://github.com/hackndev/zinc/blob/master/examples/adc_lpc17xx/src/main.rs#L44. The problem is that the feature list would be huge and it would be really hard to document it carefully.

[Phaiax]

Ok, the platform tree allows to select the hardware features. And I agree that the cargo.toml would really be too much of a mess.

I read some more documentation about the K20s and figured out that half of the K20s have a software selectable memory layout. You can optionally use up to half of the programm/data flash to instead be used as some kind of eeprom backend. This also changes some adress ranges from RAM functionality to function as EEPROM interface.

I think this is (the only?) thing that is not configurable via the current platformtree.

But I thought that it is possible to move the platform tree definition into the build.rs file of the users project. That would require him to create that build.rs file which is an additional burden. But this would also have some advantages:

• Use of a builder pattern instead of macro for platform tree definition
  • better documentation (all possible platformtree config parameters can be documented automatically)
  • generated code can be emitted into a new generated project within the user project or into some src/generated folder, but at least this allows the user to see what is happening in the background
• Use of more stable syntex_syntax crate for code parsing instead of compiler plugins
• The build script can check for needed entries in cargo.toml or the linker entries in .cargo/config and give hints to the user if there is something missing
• The build script would copy and eventually modify the linker files

The requirements of the users Cargo.toml would be somewhat like this

[package]
build = "build.rs"
[features]
default = ["mcu_k20"]
mcu_k20 = ["zinc/mcu_k20", "platformtree/mcu_k20"]

[dependencies]
zinc = { path =  "../zinc" }
macro_zinc = { path = "../zinc/macro_zinc" }
rust-libcore = "*"

[build-dependencies]
platformtree = { path =  "../zinc/platformtree" }

The build.rs somewhat like this

extern crate platformtree;
fn main() {
    platformtree::mk20().clock(1000000).....;
}

The only drawback is that the platformtree crate is not documented when executing cargo doc. It needs a cargo doc -p platformtree.

[farcaller]

True, I think the build.rs is actually the proper way forward, otherwise it becomes really hard to configure the code for several platforms.

[mcoffin]

I put a lot of thought in to trying to use features like this back when I did the initial rewrite of the build system a while ago in #285.

At the end of the day, I found cargo's features to be quite limiting, and that it was very annoying to gate code with them due to some limitations with macros.

I can't remember the specifics off the top of my head right now, but I remember them being more of a PITA than they were worth. Just my two cents though.