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 [ 20.11.2024 15:57] – [SPI group] ygramoelconfiguration_json [ 23.02.2025 15:27] (current) – [project_type] 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.
  
-The json format is defined here: https://www.json.org/json-en.html+{{odt>toc:leader_sign=.;indents=0,0.5,1;}} 
 + 
 +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 21: Line 23:
 The settings defined in this file cover different areas. The settings defined in this file cover different areas.
  
 +  * general settings
   * peripheral settings   * peripheral settings
   * driver layer   * driver layer
   * signal names   * signal names
 +
 +==== general settings ====
 +general settings affect the whole project. These settings are general configurations and switches to enable additional features or to select modes for the project.
  
 ==== peripheral settings ==== ==== peripheral settings ====
Line 55: 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.
 +
  
 ===== clock group ===== ===== clock group =====
  
-configuration of the used cocks+configuration of the used clocks
  
 TBD TBD
Line 98: Line 123:
   * open drain   * open drain
  
-type: enum+**type**: enum 
 + 
 +**default**: push pull
  
 ==== pad ==== ==== pad ====
Line 104: Line 131:
 defines the chip pad that the signal should be output on. defines the chip pad that the signal should be output on.
  
-type: string+**type**: string 
 + 
 +**default**: no default possible 
 + 
 +==== invert ==== 
 + 
 +If this setting is set to "on" then turning this output "on" will generate a Low (Gnd) signal. Turning it "off" will generate a High (Vcc) level. 
 + 
 +If this setting is set to "off" (=default) then turning this output "on" will generate a High (Vcc) signal. Turning it "off" will generate a Low (Gnd) level. 
 + 
 +**type**: string 
 + 
 +**default**: "off" 
  
 ===== digital_input group ===== ===== digital_input group =====
Line 117: Line 157:
 defines the chip pad that the signal should be read from. defines the chip pad that the signal should be read from.
  
-type: string+**type**: string
  
  
Line 143: Line 183:
 ===== UART group ===== ===== UART group =====
  
-TBD+This group defines all used UART interfaces. 
 + 
 +Each UART is a sub group with the UART name as the group name. 
 + 
 +<code> 
 +    "UART": { 
 +        "debug_uart": { 
 +            "pads": { 
 +              "TX": "PA5", 
 +              "RX": "PA6", 
 +              "CTS": "PA7", 
 +              "RTS": "PA15" 
 +            }, 
 +            "bits_per_packet": "8", 
 +            "parity": "None", 
 +            "stop_bits": "1", 
 +            "baud_rate": "115200", 
 +            "hardware_flow_control": "no", 
 +            "receive_buffer_size": "100", 
 +            "send_buffer_size": "500", 
 +        } 
 +    } 
 +</code> 
 + 
 + 
 +==== pads ==== 
 + 
 +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. 
 + 
 +=== TX === 
 + 
 +The UART will send data on this pin. (Idle = High). 
 + 
 +=== RX === 
 + 
 +The UART will receive (read) signals on this pin. 
 + 
 +=== CTS === 
 + 
 +Clear to send signal for flow control. 
 + 
 +=== RTS === 
 + 
 +Request to Send signal for flow control. 
 + 
 + 
 +==== bits_per_packet ==== 
 + 
 +defines the number of data bits. Possible values are: 
 +  * 7 
 +  * 8 
 +  * 9 
 + 
 +**type**: enum 
 + 
 +**default**: 8 
 + 
 +==== parity ==== 
 + 
 +defines the parity bit. Possible values are: 
 +  * None : no parity bit used. 
 +  * Odd :  the parity bits value makes sure that the packet contains an **__odd__** number of bits with value "1". 
 +  * Even : the parity bits value makes sure that the packet contains an **__even__** number of bits with value "1". 
 + 
 +**type**: enum 
 + 
 +**default**: None 
 + 
 + 
 +==== stop_bits ==== 
 + 
 +defines the number of stop bits. Possible values are: 
 +  * 1 
 +  * 1,5 
 +  * 2 
 + 
 +**type**: enum 
 + 
 +**default**: 8 
 + 
 + 
 +==== baud_rate ==== 
 + 
 +defines the number of bits send per second. 
 + 
 +**type**: int 
 + 
 +**default**: 115200 
 + 
 + 
 +==== hardware_flow_control ==== 
 + 
 +defines if the Request to Send (RTS) and Clear to send (CTS) signals should be used for flow control. Possible values are: 
 +  * off (RTS and CTS pins are not used. 
 +  * RTS only 
 +  * CTS only 
 +  * on (RTS and CTS signals are used) 
 + 
 +**type**: enum 
 + 
 +**default**: off 
 +==== receive_buffer_size ==== 
 + 
 +defines the number of bytes in the receive buffer of the driver. 
 + 
 +**type**: int 
 + 
 +**default**: 100 
 + 
 +==== send_buffer_size ==== 
 + 
 +defines the number of bytes in the send buffer of the driver. 
 + 
 +**type**: int 
 + 
 +**default**: 500
  
  
Line 177: Line 332:
   * //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.   * //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.
  
-  * //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.+  * //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. 
 +  * 
   * //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?)    * //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?) 
  
Line 187: Line 343:
  
 **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.   **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.  
 +
 +Maybe we just need a setting to specify which pad should be used for half-duplex communication.
 +
 +This whole //receive-only// setting is a bit obscure to me; shall we postpone it to a later version?
  
   * //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.   * //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.
Line 281: Line 441:
  
 TBD TBD
- 
-===== ... group ===== 
- 
-TBD 
- 
- 
- 
- 
- 
- 
  
configuration_json.1732114625.txt.gz · Last modified: 20.11.2024 15:57 by ygramoel