OVMS3-idf/components/soc
Felipe Neves f7ccc081a5 flash_encryption: replace spi crypt count efuse burning function by a esp_efuse_API
flash_encryption: modify additional efuses burning method to fix them are not being written

flass_encryption: burn efuse to disable boot from RAM space

flash_encryption: added better checking for key generation state plus set read and write protect for them

soc esp32s2: Add register-level bit definitions for read & wrote protect bits

esp32s2: Fixes for flash encryption

- Write efuses in a batch
- Fix some detection of whether existing efuse blocks are read/write protected
2020-04-24 12:43:47 -03:00
..
include timer_group: update hal api && fix intr_enable 2020-04-23 19:29:15 +08:00
soc flash_encryption: replace spi crypt count efuse burning function by a esp_efuse_API 2020-04-24 12:43:47 -03:00
src Merge branch 'bugfix/timer_group_intr_enable' into 'master' 2020-04-24 18:28:36 +08:00
test soc: change region in mpu test 2020-04-24 16:34:15 +08:00
CMakeLists.txt WDT: Add LL and HAL for watchdog timers 2020-03-26 02:14:02 +08:00
component.mk soc: use include_next for including common touch sensor hal header 2020-02-11 14:30:42 +05:00
linker.lf systimer: add HAL layer 2020-04-01 16:51:43 +08:00
README.md soc: separate abstraction, description and implementation 2020-02-11 14:30:42 +05:00

soc

The soc component provides abstraction, hardware description and implementation for targets suppported by ESP-IDF. This is reflected in the component's subdirectories:

  • soc/include - abstraction
  • soc/soc - description
  • soc/src - implementation

soc/include

soc/include contains header files which provide a hardware-agnostic interface to the SoC. The interface consists of function declarations and abstracted types that other, higher level components can make use of in order to have code portable to all targets ESP-IDF supports.

The hal subdirectory contains an abstraction layer for interacting with/driving the hardware found in the SoC such as the peripherals and 'core' hardware such as the CPU, MPU, caches, etc. It contains xxx_hal.h files for the function declarations and xxx_types.h for the abstracted types. The abstraction design is actually two levels -- oftentimes xxx_hal.h includes a lower-level header from a xxx_ll.h, which resides in the implementation, soc/src subdirectory. More on this abstraction design in the hal subdirectory's README.

The soc subdirectory contains other useful interface for SoC-level operations or concepts, such as the memory layout, spinlocks, etc.

soc/soc

The soc/soc subdirectory contains description of the underlying hardware:

- `xxx_reg.h`   - defines registers related to the hardware
- `xxx_struct.h` - hardware description in C `struct`
- `xxx_channel.h` - definitions for hardware with multiple channels
- `xxx_caps.h`  - features/capabilities of the hardware
- `xxx_pins.h`  - pin definitions
- `xxx_periph.h/*.c`  - includes all headers related to a peripheral; declaration and definition of IO mapping for that hardware

Since the hardware description is target-specific, there are subdirectories for each target containing copies of the files above. Furthermore, the files in this directory should be standalone, i.e. should not include files from outside directories.

soc/src

Provides the implementation of the hardware-agnostic interface in the abstraction. Target-specific subdirectories exist for wildly different implementations between targets; while code that are common/very similar might be placed in the top-level of soc/src, using some amount of conditional preprocessors. It is up to the developers' discretion on which strategy to use. Code usually reside in source files with same names to header files whose interfaces they implement, ex. xxx_hal.c for xxx_hal.h.

As mentioned previously, the lower-level abstraction header xxx_ll.h resides in this directory, since they contain hardware-specific details. However, what these can do is provide some abstraction among implementations, so that more code can be moved to the common, non-target-specific subdirectories.

This can also contain target-specific extensions to the HAL headers. These target-specific HAL headers have the same name and include the abstraction layer HAL header via include_next. These extensions might add more function declarations or override some things using macro magic.