configuration_json
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
configuration_json [ 20.12.2024 01:55] – lars | configuration_json [ 21.06.2025 20:51] (current) – lars | ||
---|---|---|---|
Line 3: | Line 3: | ||
====== File format specification of configuration definition ====== | ====== File format specification of configuration definition ====== | ||
- | this describes the possible elements of a configuration description in json format. | + | this describes the possible elements of a configuration description in JSON format. |
{{odt> | {{odt> | ||
- | The json format is defined here: https:// | + | The JSON format is defined here: https:// |
All elements not listed as essential are optional. Being optional means that they can be missing and the configuration is still valid. | All elements not listed as essential are optional. Being optional means that they can be missing and the configuration is still valid. | ||
Line 25: | Line 25: | ||
* general settings | * general settings | ||
* peripheral settings | * peripheral settings | ||
- | | + | |
- | * signal names | + | * signal names |
==== general settings ==== | ==== general settings ==== | ||
Line 61: | Line 61: | ||
Keys like *digital_output* and *SPI* represent group names and are taken from a predefined set of group names understood by MBSP. Keys nested within them are arbitrary user-defined names for a instance in that group. In those instances the keys are from the defined set specific for that group. | Keys like *digital_output* and *SPI* represent group names and are taken from a predefined set of group names understood by MBSP. Keys nested within them are arbitrary user-defined names for a instance in that group. In those instances the keys are from the defined set specific for that group. | ||
+ | |||
+ | ===== general settings ===== | ||
+ | |||
+ | these are settings on the top layer that effect the whole project. | ||
- | ===== vendor_name | + | ==== vendor_name ==== |
- | Name of the company that sells the micro controller. As listed on chipselect.org | + | Name of the company that sells the micro controller. As listed on https://chipselect.org |
**type**: string | **type**: string | ||
- | ===== chip_name | + | ==== chip_name ==== |
- | model number of the micro controller. | + | Model number of the micro controller. |
**type**: string | **type**: string | ||
Model number is truncated so that it only contains relevant differences for code generation: flash and ram sizes are relevant, temperature range or package are not. | Model number is truncated so that it only contains relevant differences for code generation: flash and ram sizes are relevant, temperature range or package are not. | ||
+ | |||
+ | |||
+ | ==== project_type ==== | ||
+ | |||
+ | what type of project to generate. | ||
+ | |||
+ | **type**: string | ||
+ | |||
+ | **default**: | ||
+ | |||
+ | Possible values are: | ||
+ | * "hal only" : only creates the hardware driver files (in the hal/ folder) and hardware definitions (in the hal/hw/ folder) | ||
+ | * " | ||
+ | * " | ||
+ | |||
+ | |||
+ | ==== file_comment ==== | ||
+ | |||
+ | defines the comment at the top of each generated file. | ||
+ | |||
+ | **type**: string | ||
+ | |||
+ | **default**: | ||
+ | |||
+ | Possible values are: | ||
+ | * " | ||
+ | * " | ||
+ | |||
+ | ==== run_from ==== | ||
+ | |||
+ | defines the location of the firmware code when run. | ||
+ | |||
+ | **type**: string | ||
+ | |||
+ | **default**: | ||
+ | |||
+ | Possible values are: | ||
+ | * " | ||
+ | * " | ||
+ | * " | ||
+ | |||
+ | ==== path_prefix ==== | ||
+ | |||
+ | if you use a "hal only" MBSP project located in a sub folder of your project then the name of the sub folder goes here. | ||
+ | |||
+ | **type**: string | ||
+ | |||
+ | **default**: | ||
===== clock group ===== | ===== clock group ===== | ||
- | configuration of the used clocks | + | configuration of the used clocks. |
+ | |||
+ | < | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | ==== source ==== | ||
+ | |||
+ | defines the source of the clock signal. Supported clock sources are: | ||
+ | * " | ||
+ | * ... | ||
+ | |||
+ | **type**: enum | ||
+ | |||
+ | **default**: | ||
+ | |||
+ | ==== frequency ==== | ||
+ | |||
+ | defines the frequency that this clock has. | ||
+ | |||
+ | **type**: string (Hz, kHz, MHz) | ||
+ | |||
+ | **default**: | ||
- | TBD | ||
Line 154: | Line 232: | ||
===== Timer group ===== | ===== Timer group ===== | ||
- | TBD | + | This group contains all timer and counter peripherals. |
+ | |||
+ | < | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | ==== peripheral ==== | ||
+ | |||
+ | defines which peripheral to use. peripherals can be: | ||
+ | * systick (part of the ARM core) | ||
+ | * timer1 | ||
+ | * timer2 | ||
+ | * ... | ||
+ | |||
+ | **type**: String | ||
+ | |||
+ | **default**: | ||
+ | |||
+ | ==== mode ==== | ||
+ | |||
+ | defines the operation mode the timer/ | ||
+ | * count overflows | ||
+ | |||
+ | |||
+ | **type**: enum | ||
+ | |||
+ | **default**: | ||
+ | |||
+ | ==== frequency ==== | ||
+ | |||
+ | The frequency defines the time between timer overflows. 1kHz means that the time between overflow events is 1/(1 kHz) = 1 ms. | ||
+ | |||
+ | **type**: string (Hz, kHz, MHz) | ||
+ | |||
+ | **default**: | ||
Line 165: | Line 284: | ||
===== UART group ===== | ===== UART group ===== | ||
- | This group defines all used UART interfaces. | + | This group defines all used Universal Asynchronous Receiver Transmitter (UART) interfaces. |
Each UART is a sub group with the UART name as the group name. | Each UART is a sub group with the UART name as the group name. | ||
Line 172: | Line 291: | ||
" | " | ||
" | " | ||
- | "pads": { | + | "pad_tx": " |
- | "TX": " | + | "pad_rx": " |
- | "RX": " | + | "pad_cts": " |
- | "CTS": " | + | "pad_rts": " |
- | "RTS": " | + | " |
- | } | + | " |
- | " | + | " |
- | " | + | " |
- | " | + | " |
- | " | + | " |
- | " | + | " |
- | " | + | " |
- | " | + | " |
+ | " | ||
} | } | ||
} | } | ||
</ | </ | ||
+ | === pad_tx === | ||
- | ==== pads ==== | + | The UART will send data on this pin. (Idle = High). Either this or the pad_rx must be given. |
- | defines the used signal pins. At least one pin must be present(either TX or RX). Pins that are not present will not be used/ are not available for functionality. | + | === pad_rx === |
- | === TX === | + | The UART will receive (read) signals on this pin. Either this or pad_rx must be given. |
- | The UART will send data on this pin. (Idle = High). | + | === pad_cts === |
- | === RX === | + | Clear to send signal for flow control. Will not be used if not defined. |
- | The UART will receive (read) signals on this pin. | + | === pad_rts === |
- | === CTS === | + | Request to Send signal for flow control. Will not be used if not defined. |
- | + | ||
- | Clear to send signal for flow control. | + | |
- | + | ||
- | === RTS === | + | |
- | + | ||
- | Request to Send signal for flow control. | + | |
Line 258: | Line 373: | ||
defines if the Request to Send (RTS) and Clear to send (CTS) signals should be used for flow control. Possible values are: | defines if the Request to Send (RTS) and Clear to send (CTS) signals should be used for flow control. Possible values are: | ||
- | * no (RTS and CTS pins are not used. | + | * off (RTS and CTS pins are not used. |
* RTS only | * RTS only | ||
* CTS only | * CTS only | ||
- | * yes (RTS and CTS signals are used) | + | * on (RTS and CTS signals are used) |
**type**: enum | **type**: enum | ||
- | **default**: | + | **default**: |
==== receive_buffer_size ==== | ==== receive_buffer_size ==== | ||
Line 281: | Line 397: | ||
**default**: | **default**: | ||
+ | |||
+ | ==== peripheral ==== | ||
+ | |||
+ | name of the UART peripheral to use. | ||
+ | |||
+ | **type**: String | ||
+ | |||
+ | ==== IRQ ==== | ||
+ | |||
+ | The interrupt number of the peripheral. | ||
+ | |||
+ | **type**: int | ||
+ | |||
+ | ==== IRQ_priority ==== | ||
+ | |||
+ | The interrupt priority of the interrupt. | ||
+ | |||
+ | **type**: int | ||
===== SPI group ===== | ===== SPI group ===== | ||
+ | |||
+ | This group defines all used Serial Peripheral Interface (SPI) interfaces. | ||
+ | |||
+ | Each SPI interface is a sub group with the SPI name as the group name. | ||
< | < | ||
" | " | ||
" | " | ||
- | "pads": { | + | "pad_sck": " |
- | "SCK": " | + | "pad_miso": " |
- | "MISO": " | + | "pad_mosi": " |
- | "MOSI": " | + | "pad_ncs": " |
- | "NSS": " | + | |
- | | + | |
" | " | ||
" | " | ||
Line 300: | Line 437: | ||
" | " | ||
" | " | ||
- | | + | " |
- | | + | |
- | " | + | |
- | " | + | |
} | } | ||
} | } | ||
</ | </ | ||
- | * // | ||
- | * //pads// specifies the desired pad for each signal of this SPI peripheral. Usually, this will uniquely define the peripheral to be used. Unused signals can be skipped. | + | === pad_sck === |
- | * //role: master//: role can be //master// or // | + | Serial Clock. |
- | | + | **type**: String |
- | | + | |
- | | + | |
- | **DICUSS(Lars): | + | === pad_mosi === |
- | **REPLY(Johan)** Half duplex is different from unidirectional communication. | + | " |
- | **DICUSS(Lars): | + | **type**: String |
- | **REPLY(Johan)** I agree: this is a bad idea. Unfortunately, | + | === pad_miso === |
- | Maybe we just need a setting to specify which pad should be used for half-duplex communication. | + | " |
- | This whole // | + | **type**: String |
- | * // | + | === pad_ncs === |
- | * // | + | Chip Select signal (Low active). |
- | | + | **type**: String |
- | Sometimes the documentation talks about a SPI Mode with the value of 0 to 3. This mode maps to the phase and polarity as described in the following table: | + | ==== peripheral ==== |
- | ^ Mode ^ CPOL ^ CPHA ^ description^ | + | name of the SPI peripheral to use. |
- | | 0 | 0 | 0 | clock: idle_low, phase: sample_on_leading_edge | | + | |
- | | 1 | 0 | 1 | clock: idle_low, phase: sample_on_trailing_edge | | + | |
- | | 2 | 1 | 0 | clock: idle_high, phase: sample_on_leading_edge | | + | |
- | | 3 | 1 | 1 | clock: idle_high, phase: sample_on_trailing_edge | | + | |
- | | + | **type**: String |
- | * // | + | === role === |
- | **DICUSS(Lars):** What do you have in mind? How can the code generator provide feedback? Shall we define some sort of log file that goes into the zip with the generated code that you can read and check for things like this? | + | Is either master(host) or slave(device). |
- | **REPLY(Johan): | + | **type**: enum |
- | **DICUSS(Lars): | + | **default**: master |
- | **REPLY(Johan): | + | === communication_mode === |
- | | + | Describes the communication. Possible values are: |
+ | | ||
+ | * half-duplex : meaning the same wire between master | ||
+ | * receive-only : send line is not used | ||
+ | * send-only : receive Line is not used. | ||
- | **DICUSS(Lars): | + | **type**: enum |
- | **REPLY(Johan): | + | **default**: duplex |
- | * // | + | === frame_format === |
- | **DICUSS(Lars):** The 7 has no meaning at all for me. We at least need the documentation that explains how to interpret the value. Also driver layer. Documentation can be a link to wikipedia or whatever. | + | Describes the communication. Possible values are: |
+ | | ||
+ | * ti : | ||
- | **REPLY(Johan)** You are right. Wikipedia https:// | + | **type**: enum |
- | **DICUSS(Lars): | + | **default**: motorola |
- | **REPLY(Johan)** Agreed: let's postpone this. It is not essential for a demo, so we can even postpone it until after the demo. | + | === clock_polarity === |
+ | Also often called CPOL. Describes | ||
+ | * idle_low | ||
+ | * idle_high | ||
- | **REPLY(Johan)** How/where would you specify the parameters of the connected device? Many other SPI parameters specified here also depend on the connected device. For example clock polarity and phase and bit order must match the device' | + | **type**: enum |
- | **DICUSS(Lars): | + | **default**: idle_low |
- | **REPLY(Johan)** Does that mean that for supported devices, | + | === clock_phase === |
+ | Also often called CPHA. Describes | ||
+ | * sample_on_leading_edge : samples the data on the edge from idle value to non-idle value. | ||
+ | * sample_on_trailinging_edge : samples the data on the edge from non-idle value to idle value. | ||
- | ===== QSPI group ===== | + | **type**: enum |
- | TBD | + | **default**: |
- | ===== SDIO group ===== | ||
- | TBD | + | === SPI Mode === |
+ | Sometimes the documentation talks about a SPI Mode with the value of 0 to 3. This mode maps to the phase and polarity as described in the following table: | ||
- | ===== I2C group ===== | + | ^ Mode ^ CPOL ^ CPHA ^ description^ |
+ | | 0 | 0 | 0 | clock: idle_low, phase: sample_on_leading_edge | | ||
+ | | 1 | 0 | 1 | clock: idle_low, phase: sample_on_trailing_edge | | ||
+ | | 2 | 1 | 0 | clock: idle_high, phase: sample_on_leading_edge | | ||
+ | | 3 | 1 | 1 | clock: idle_high, phase: sample_on_trailing_edge | | ||
- | TBD | ||
- | ===== I3C group ===== | + | === bit_order |
+ | Describes the communication. Possible values are: | ||
+ | * msb_first : most significant bit first (bits on the line : 76543210 ) | ||
+ | * lsb_first : least significant bit first (bits on the line: 01234567 ) | ||
- | TBD | + | **type**: enum |
+ | **default**: | ||
- | ===== I2S group ===== | + | === baud_rate |
- | TBD | + | Is the number of bits per second exchanged on the data lines. Expressed as frequency of the clock line. |
+ | **type**: int (Hz) | ||
- | ===== CAN group ===== | + | ===== |
- | TBD | + | This group defines all used Inter-Integrated Circuit (I2C) interfaces. |
+ | Each I2C interface is a sub group with the I2C name as the group name. | ||
- | ===== USB group ===== | + | < |
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | " | ||
+ | } | ||
+ | } | ||
+ | </ | ||
- | TBD | ||
+ | === pad_scl === | ||
- | ===== Watchdog group ===== | + | Serial Clock. |
- | TBD | + | **type**: String |
- | ===== Random_Number group ===== | + | === pad_sda |
- | TBD | + | serial data signal. |
+ | **type**: String | ||
- | ===== CRC group ===== | + | ==== peripheral |
- | TBD | + | name of the I2C peripheral to use. |
- | ===== ... group ===== | + | **type**: String |
+ | |||
+ | === role === | ||
+ | Describes the role in the communication. Possible values are: | ||
+ | * master | ||
+ | * slave | ||
+ | |||
+ | **type**: enum | ||
- | TBD | ||
+ | === address_bits === | ||
+ | 7bit Address or 10 bit Address | ||
+ | === clock_max_frequency === | ||
+ | fastest speed (shotest bit time) to use on the SCL line. | ||
+ | * Standard Speed (up to 100 kHz) | ||
+ | * fast mode (up to 400 kHz) | ||
+ | * fast mode plus (up to 1000 kHz = 1 MHz) | ||
+ | * high speed mode (up to 3.4 MHz) | ||
+ | * ultra fast mode (up to 5 MHz) | ||
configuration_json.1734659710.txt.gz · Last modified: by lars