libboard_zynq: dead code, peripheral & regblock ctor names consistency #63

Manually merged
astro merged 3 commits from harry/zynq-rs:cleanup into master 2020-08-17 23:38:22 +08:00

This is an attempt to clean up some code, as well as unify the nomenclature for each peripheral device and their corresponding memory-mapped registers (RegisterBlock). The rules for such unification is as follows:

  • For the struct intended for accessing each peripheral, e.g. a struct named Periph:
    • The struct is always in PascalCase, not UPPERCASE or lowercase (e.g. sdio::Sdio, uart::Uart, ddr::DdrRam).
    • If only 1 such peripheral device can be independently used, then there is only 1 constructor and it is named Periph::periph() (note: there is an exception: gic::InterruptController::gic() is named as-is instead of interrupt_controller()).
    • If more than 1 devices can be independently used, then there are more than 1 constructors and they are named Periph::periph0(), Periph::periph1(), etc.
  • For the struct intended for accessing the memory-mapped register(s) for each module, e.g. a set of registers defined in module::regs:
    • Such struct is always named module::RegisterBlock, regardless of its implementation (e.g. i2c::regs::RegisterBlock is not actually using the I2C controller registers on Zynq, but the GPIO registers for bitbanging).
    • If only 1 register (block) is used by the module, then there is only 1 constructor and its name is the lower-case version of its software register name (e.g. ddr::regs::RegisterBlock::ddrc()), or its module name if software register name is inapplicable (e.g. i2c::regs::RegisterBlock::i2c(), since i2c0 or i2c1 are the I2C controller register names)
    • If more than 1 registers are used by the module, then there are more than 1 constructors and their names are the lower-case version of their corresponding software register names (e.g. uart::regs::RegisterBlock::uart0(), uart::regs::RegisterBlock::uart1()).
This is an attempt to clean up some code, as well as unify the nomenclature for each peripheral device and their corresponding memory-mapped registers (`RegisterBlock`). The rules for such unification is as follows: * For the `struct` intended for accessing each peripheral, e.g. a struct named `Periph`: * The `struct` is always in PascalCase, not UPPERCASE or lowercase (e.g. `sdio::Sdio`, `uart::Uart`, `ddr::DdrRam`). * If only 1 such peripheral device can be independently used, then there is only 1 constructor and it is named `Periph::periph()` (note: there is an exception: `gic::InterruptController::gic()` is named as-is instead of `interrupt_controller()`). * If more than 1 devices can be independently used, then there are more than 1 constructors and they are named `Periph::periph0()`, `Periph::periph1()`, etc. * For the `struct` intended for accessing the memory-mapped register(s) for each module, e.g. a set of registers defined in `module::regs`: * Such `struct` is always named `module::RegisterBlock`, regardless of its implementation (e.g. `i2c::regs::RegisterBlock` is not actually using the I2C controller registers on Zynq, but the GPIO registers for bitbanging). * If only 1 register (block) is used by the module, then there is only 1 constructor and its name is the lower-case version of its software register name (e.g. `ddr::regs::RegisterBlock::ddrc()`), or its module name if software register name is inapplicable (e.g. `i2c::regs::RegisterBlock::i2c()`, since `i2c0` or `i2c1` are the I2C controller register names) * If more than 1 registers are used by the module, then there are more than 1 constructors and their names are the lower-case version of their corresponding software register names (e.g. `uart::regs::RegisterBlock::uart0()`, `uart::regs::RegisterBlock::uart1()`).

@astro can you review this?

@astro can you review this?

These proposals make 100% sense. It was my negligence that I didn't name things like that in the first place.

These proposals make 100% sense. It was my negligence that I didn't name things like that in the first place.
astro closed this pull request 2020-08-17 23:38:22 +08:00
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/zynq-rs#63
There is no content yet.