periph: remove dev_enums.h

[haukepetersen]

The drivers/include/periph/dev_enums.h file was introduced for backwards compatibility when we changed the style of doing the board configuration in periph_conf.h some time ago. Most of the periph drivers are remodeled by now, though some are open. Except the i2c drivers, which will be remodeled while reworking the complete interface, the following drivers need adaption:

timer:

• samd21
• saml21 (best to unify these two into sam0_common in the same process)
• lm4f120
• lpc1768

uart:

• cc2538
• lm4f120
• lpc1768

I did not really check the open PRs though, so there might be a fix for some of the mentioned in the pipeline already. Please check before starting to work on any of these...

[danpetry]

No fixes in open PRs that I can see. Related open PRs are as follows:

• boards: move shared code to boards/common/xx #8058 - some info on sam0_common
• timer: remove usage of TIMER_X_MAX_VALUE #7694 - affects lm4f120 timer driver
• cpu, cc2538: adapt periph uart to GPIO API #7310 - affects cc2538 UART driver

I'll read these before starting work on the relevant driver.

[danpetry]

I think I also need to change the periph_conf files for the boards that have the above cpus on them. Will include the changes for those in the PR I submit for each cpu peripheral.

These are:

cc2538:

• openmote-cc2538
• cc2538dk

[haukepetersen]

I think I also need to change the periph_conf files for the boards that have the above cpus on them

Yes, you will certainly :-)

[danpetry]

@haukepetersen there are aliases for UART_X called UART_X_DEV in the cc2538 driver. I can't see any functional purpose that they serve, but am I missing something? Can they be taken out, i.e. replaced with just UART_X?

[danpetry]

@smlng for the 2538, are the above boards the only ones with this CPU? Also, would you mind testing the changes for the other boards once I've made them? (I only have the openmote at the moment).

[danpetry]

Note for reviewer: now that I've removed the switch/case statement, device numbers outside the ones actually implemented can be used. They won't be caught by the default statement as before, and there's no value restriction on uart_t. What would be the effect of this?

[MrKevinWeiss]

Just FYI I am working on updating the uart config for the lm4f120 based off @danpetry work.

[MrKevinWeiss]

I think I will work on the UART for the lpc1768 next. There are some shared files that #6472 is working on but it seems to be in different sections.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[miri64]

@haukepetersen @MrKevinWeiss what is the state on this?

[MrKevinWeiss]

Ahh yes, one of my first riot tasks still not done :)

[MrKevinWeiss]

It seems like the slwstk6220a board uses I2C0

The lm4f120 and lpc1768 use TIMER_x and UART_x.

Both of those boards are obsolete. Maybe we can just hardcode UART_0 for the lm4f120 as the uart_init asserts the uart==0 anyways. Then it will be similar to the nrf52dk I think.

The lpc might take a bit more.

[haukepetersen]

what he said :-)

[MrKevinWeiss]

This is on the list, as soon as I put out all the fires I will get to it... or maybe find a student 👿