MBSP

Microcontroller Board Support Package

User Tools

Site Tools

Trace:
configuration_json

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
configuration_json [ 17.12.2024 23:54] – larsconfiguration_json [ 21.04.2025 12:14] (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>toc:leader_sign=.;indents=0,0.5,1;}} {{odt>toc:leader_sign=.;indents=0,0.5,1;}}
  
-The json format is defined here: https://www.json.org/json-en.html+The JSON format is defined here: https://www.json.org/json-en.html
  
 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
-  * driver layer +    * driver layer 
-  * 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. As listed on https://chipselect.org
  
 **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**: "make"
 +
 +Possible values are:
 +  * "hal only" : only creates the hardware driver files (in the hal/ folder) and hardware definitions (in the hal/hw/ folder)
 +  * "embeetle" : create an Embeetle IDE project
 +  * "make" :  creates a makefile based "blinky" project.
 +
 +
 +==== file_comment ====
 +
 +defines the comment at the top of each generated file.
 +
 +**type**: string
 +
 +**default**: "created"
 +
 +Possible values are:
 +  * "created" : file comment list date and time of file creation as well as configuration file name.
 +  * "minimal" : short comment only stating the file name and that it was automatically created.
 +
 +==== run_from ====
 +
 +defines the location of the firmware code when run.
 +
 +**type**: string
 +
 +**default**: "flash"
 +
 +Possible values are:
 +  * "flash" : firmware is located and run from the flash memory.
 +  * "ram" : firmware is located and run from the RAM.
 +  * "flash2ram" : firmware is located in flash, copied to RAM on boot and then executed from RAM.
 +
 +==== 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. 
 + 
 +<code> 
 +    "clock": { 
 +        "cpu": { 
 +            "source" : "hse", 
 +            "frequency" : "12 MHz", 
 +        } 
 +    } 
 +</code> 
 + 
 +==== source ==== 
 + 
 +defines the source of the clock signal. Supported clock sources are: 
 +  * "hse"  (High speed external) 
 +  * ... 
 + 
 +**type**: enum 
 + 
 +**default**: hse 
 + 
 +==== frequency ==== 
 + 
 +defines the frequency that this clock has.  
 + 
 +**type**: string (Hz, kHz, MHz) 
 + 
 +**default**: "1 MHz"
  
-TBD 
  
  
Line 154: Line 232:
 ===== Timer group ===== ===== Timer group =====
  
-TBD+This group contains all timer and counter peripherals. 
 + 
 +<code> 
 +    "timer": { 
 +        "ms_tick": { 
 +            "peripheral" : "systick", 
 +            "mode" : "count overflows", 
 +            "frequency" : "1 kHz", 
 +        } 
 +    } 
 +</code> 
 + 
 +==== peripheral ==== 
 + 
 +defines which peripheral to use. peripherals can be: 
 +  * systick (part of the ARM core) 
 +  * timer1 
 +  * timer2 
 +  * ... 
 + 
 +**type**: String 
 + 
 +**default**: systick 
 + 
 +==== mode ==== 
 + 
 +defines the operation mode the timer/counte operates in. Possible modes are: 
 +  * count overflows 
 + 
 + 
 +**type**: enum 
 + 
 +**default**: count overflows 
 + 
 +==== 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**: "1 kHz" 
  
  
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:
     "UART": {     "UART": {
         "debug_uart": {         "debug_uart": {
-            "pads": { +            "pad_tx": "PA5", 
-              "TX": "PA5", +            "pad_rx": "PA6", 
-              "RX": "PA6", +            "pad_cts": "PA7", 
-              "CTS": "PA7", +            "pad_rts": "PA15", 
-              "RTS": "PA15" +            "bits_per_packet": "8", 
-            } +            "parity": "None", 
-            "bits_per_packet": "8" +            "stop_bits": "1", 
-            "parity": "None" +            "baud_rate": "115200", 
-            "stop_bits": "1" +            "hardware_flow_control": "no", 
-            "baud_rate": "115200" +            "receive_buffer_size": "100", 
-            "hardware_flow_control": "no" +            "send_buffer_size": "500", 
-            "receive_buffer_size": "100" +            "peripheral" : "UART0", 
-            "send_buffer_size": "500"+            "IRQ" : "20",  
 +            "IRQ_priority" : "0",
         }         }
     }     }
 </code> </code>
 +
 +=== pad_tx ===
 +
 +The UART will send data on this pin. (Idle = High). Either this or the pad_rx must be given.
 +
 +=== pad_rx ===
 +
 +The UART will receive (read) signals on this pin. Either this or pad_rx must be given.
 +
 +=== pad_cts ===
 +
 +Clear to send signal for flow control. Will not be used if not defined.
 +
 +=== pad_rts ===
 +
 +Request to Send signal for flow control. Will not be used if not defined.
 +
  
 ==== bits_per_packet ==== ==== bits_per_packet ====
Line 236: 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**: no+**default**: off
  
-            "receive_buffer_size": "100" 
-            "send_buffer_size": "500" 
-             
 ==== receive_buffer_size ==== ==== receive_buffer_size ====
  
Line 263: Line 397:
  
 **default**: 500 **default**: 500
 +
 +==== 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.
  
 <code> <code>
     "SPI": {     "SPI": {
         "encoder_spi": {         "encoder_spi": {
-            "pads": { +            "pad_sck": "PA5", 
-              "SCK": "PA5", +            "pad_miso": "PA6", 
-              "MISO": "PA6", +            "pad_mosi": "PA7", 
-              "MOSI": "PA7", +            "pad_ncs": "PA15",
-              "NSS": "PA15" +
-            }+
             "role": "master",             "role": "master",
             "communication_mode": "duplex",             "communication_mode": "duplex",
Line 282: Line 436:
             "clock_phase": "sample_on_leading_edge",             "clock_phase": "sample_on_leading_edge",
             "bit_order": "msb_first",             "bit_order": "msb_first",
-            <del>frame_size: 8</del> +            "baud_rate": "10 MHz",
-            "baud_rate": "10Mhz", +
-            "crc": "enabled", +
-            "crc_polynomial": <del>7</del>+
         }         }
     }     }
 </code> </code>
  
-  * //encoder_spi//: the user-defined name of the SPI peripheral. It is possible to call it SPI1,  but that doesn't necessarily mean that it will be mapped to the SPI1 peripheral of the target microcontroller. The mapping will be determined by the desired pads for the SPI signals and possibly other desired settings. 
  
-  * //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 //slave//,  also known as //host// and //device//. There exist a number of other terms, but we limit ourselves to two terms for each role.  We include //master// and //slave// because these are the most common ones,  and //host// and //device// to offer an alternative for those who are not happy with these historically charged terms.+Serial Clock.
  
-  * //communication_mode: duplex//: communication mode can be //duplex// (the traditional mode using MISO and MOSI to transmit and receive at the same time) or //half-duplex//, meaning the same wire between master MOSI and slave MISO is used for both directions. Unidirectional communication can be achieved by specifying //duplex// and connecting only MISO-to-MISO or MOSI-to-MOSI wires. See also //receive-only// below. +=== pad_mosi ===
-  *  +
-  * //receive-only// (RXOMEN in the F411) disables the transmission signal (MISO in slave mode, MOSI in master mode). According to the F411 manual, it is useful when communicating with multiple slaves to avoid data collisions (not completely clear to me;  avoids NSS signals for master-to-slave communication?) +
  
-**DICUSS(Lars):** I assume they mean that you can use the unused pin for other usages/ do not read noise on the unconnected pin? Anyhow, A send only should also be given for symmetry. But then I think we have this double with the duplex / half duplex setting. So maybe consolidate those together?+"Master Out Slave In" data signal.
  
-**REPLY(Johan)** Half duplex is different from unidirectional communication.  See figures in APM32F411xCxE user manual v1.4 page 327. In half-duplex mode (what they call bidirectional mode), master-MOSI is connected to slave-MISO. In unidirectional mode, master-MOSI is connected to slave-MOSI or master-MISO is connected to slave-MISO,  depending on the desired direction.+=== pad_miso ===
  
-**DICUSS(Lars):** " master-MOSI is connected to slave-MISO" AHHH. Why? That is just wrong!+"Master In Slave Out" data signal.
  
-**REPLY(Johan)** I agree: this is a bad idea. Unfortunately,  it is what they do in the F411 chip. Whether you actually need to mkae that connection depends on the other device;  in the F411 settings,  it only means that half duplex communication uses MOSI in master mode and MISO in slave mode. Unidirectional receive-only uses MISO in master mode and MOSI in slave mode,  and vice-versa for transmit-only.  +=== pad_ncs ===
  
-Maybe we just need a setting to specify which pad should be used for half-duplex communication.+Chip Select signal (Low active).
  
-This whole //receive-only// setting is a bit obscure to me; shall we postpone it to a later version?+=== role ===
  
-  * //frame_format// can be //motorola// or //ti//. //ti// format has implications for clock polarity and phase and nss handling that are currently unclear;  we may need to figure this out and possibly replace this parameter by more explicit settings.+Is either master(host) or slave(device).
  
-  * //clock_polarity//: //idle_low// or //idle_high// sets the clock level between transmissions of data. Also often called CPOL.+**type**: enum
  
-  * //clock_phase// sets the clock transition at which the data is sampled;  //sample_on_leading_edge// samples the data on the edge from idle value to non-idle value, and //sample_on_trailinging_edge// samples the data on the edge from non-idle value to idle value. Also often called CPHA.+**default**: master
  
-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:+=== communication_mode ===
  
-^ Mode ^ CPOL ^ CPHA ^ description^ +Describes the communication. Possible values are: 
-| 0 | 0 | 0 | clock: idle_low, phase: sample_on_leading_edge | +  * duplex : the traditional mode using MISO and MOSI to transmit and receive at the same time. 
-| 1 | 0 | 1 | clock: idle_low, phase: sample_on_trailing_edge | +  * half-duplex : meaning the same wire between master and slave is used for both directions. 
-| 2 | 1 | 0 | clock: idle_high, phase: sample_on_leading_edge | +  * receive-only : send line is not used 
-| 3 | 1 | 1 | clock: idle_high, phase: sample_on_trailing_edge |+  * send-only : receive Line is not used.
  
-  * //bit_order// can be //msb_first// or //lsb_first//+**type**: enum
  
-  * //baud_rate// is the desired clock frequency during transmission. Code generation should try to approach it as closely as possible. Will there be a feedback mechanism to report the achieved (nominal) frequency?+**default**: duplex
  
-**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?+=== frame_format ===
  
-**REPLY(Johan):** I am not sure yet.  My ideal for baud rate would be to show immediately in the UI what the closest achievable baud rate is. If that is not (yet) possible,  I would like at least to be able to show the actual baud rate in the UI. So some structured feedback would be useful;  maybe another json file in the generated code? It could also be useful to provide error feedback from code generation, e.g. if the requested parameters are not achievable.+Describes the communication. Possible values are: 
 +  * motorola : the "normal" SPI. 
 +  * ti : 
  
-**DICUSS(Lars):** I added a report file to the list of generated files.(mbsp_report.txt) We probably then need a format for that also,...+**type**: enum
  
-**REPLY(Johan):** Right, but probably not necessary for version 1.+**default**: motorola
  
-  * //crc//: //enabled// or //disabled//. The Geehy F411 SPI peripherals provide hardware for CRC generation and checking +=== clock_polarity === 
 +Also often called CPOL. Describes the communication. Possible values are: 
 +  * idle_low 
 +  * idle_high
  
-**DICUSS(Lars):** I think that is something the driver layer should deal with. But not sure. +**type**: enum
  
-**REPLY(Johan):** CRC settings must match the expectations of the device+**default**: idle_low
  
-  * //crc_polynomial//: an unsigned integer representing the polynomial to be used for CRC generation and checking. Do we need to specify the number of bits as well?+=== clock_phase === 
 +Also often called CPHA. Describes the communication. Possible values are: 
 +  * 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.
  
-**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. +**type**: enum
  
-**REPLY(Johan)** You are right. Wikipedia https://en.wikipedia.org/wiki/Cyclic_redundancy_check mentions four different notations to specify a polynomial for a CRC: normal, reversed, reciprocal and reversed reciprocal. They can be converted into each other, so we can choose one. The reciprocal versions have the advantage that you need to specify only a single number, not a separate length and value. Some standardized CRC algorithms have extra steps in addition to the core CRC calculation,  like prepending an initial value or xor-ing the final value with some constant. I assume that these steps are usually not implemented in hardware. Do we need to take that into account for code generation?+**default**: sample_on_leading_edge
  
-**DICUSS(Lars):** can we move this to version 2? long answer: It depends. The CRC, as you said, depends on the device/communication partner. And that might expect some crazy initialization value and some Xor at the end or whatever. I would suggest to look at this from the use case perspective and find solutions for one use case after the other. That way these settings are derived from the use case and we do not depend on the user to provide consistent settings. Then we can also have a generic solution where the user has to give all the variables (initialization, Xor,..) and w then do exactly that and hope for the best. 
  
-**REPLY(Johan)** Agreed: let's postpone this.  It is not essential for a demo, so we can even postpone it until after the demo.+=== 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:
  
-**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's expectations. +^ Mode ^ CPOL ^ CPHA ^ description^ 
- +| 0 | 0 | 0 | clock: idle_low, phase: sample_on_leading_edge | 
-**DICUSS(Lars):** We could add explicit support for some devices. Then the user would just select the device and all the dependent settings (CPOL/CPHA,CRC, bits per transfer..) would be set accordingly. Does that make sense?+| 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 |
  
-**REPLY(Johan)** Does that mean that for supported devices,  you don't need an explicit SPI configuration?  That makes sense to me. I think we would still need an SPI configuration for unsupported devices; it will take some time before we can support all existing devices in the world :-) . It is OK for me to initially only provide SPI settings for unsupported devices without CRC; that can be added later. 
  
-===== QSPI group ===== 
- 
-TBD 
- 
-===== SDIO group ===== 
- 
-TBD 
- 
-===== I2C group ===== 
- 
-TBD 
- 
- 
-===== I3C group ===== 
- 
-TBD 
- 
- 
-===== I2S group ===== 
- 
-TBD 
- 
- 
-===== CAN group ===== 
- 
-TBD 
- 
- 
-===== USB group ===== 
- 
-TBD 
- 
- 
-===== Watchdog group ===== 
- 
-TBD 
- 
-===== Random_Number group ===== 
- 
-TBD 
- 
- 
-===== CRC group ===== 
- 
-TBD 
- 
-===== ... group ===== 
- 
-TBD 
  
 +=== 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 )
  
 +**type**: enum
  
 +**default**: msb_first
  
 +=== baud_rate ===
  
 +Is the number of bits per second exchanged on the data lines. Expressed as frequency of the clock line.
  
 +**type**: int (Hz)
  
configuration_json.1734479643.txt.gz · Last modified: by lars