modm-io / modm-devices Goto Github PK

View Code? Open in Web Editor NEW

49.0 49.0 27.0 3.1 MB

Curated device data for all AVR and ARM Cortex-M devices

Home Page: https://blog.salkinium.com/modm-devices

License: Mozilla Public License 2.0

Makefile 1.06% Python 98.94%

avr cortex-m data microcontroller modm nrf sam stm32

modm-devices's People

Contributors

Stargazers

Watchers

modm-devices's Issues

SAM device file inconsistency for MCAN peripheral

The following lines do not describe disjoint device sets, because both match e.g. the same70q19b-an device, which causes errors in lbuild:

modm-devices/devices/sam/same70_s70_v70_v71.xml

Lines 265 to 266 in e093fe8

    
           <instance device-series="e70|v70|v71" device-pin="n|q" device-flash="19|20" device-variant="b" value="1"/> 
        
           <instance device-series="e70|v71" device-pin="n|q" device-flash="19|20|21" device-variant="a|b" value="1"/>

SRAM incorrect for stm32g4 series devices

I did some digging to figure out why the modm generated openocd.cfg crashes when flashing my STM32G491 device (with RTT enabled). Turns out it tries to zero out more SRAM than the device actually has!
So I had a look at the device files for this series and found that the SRAM1 size is 112KB

modm-devices/devices/stm32/stm32g4-71_91_a1.xml

Line 77 in 0a6b13d

The reference manual specifies that all category 3 and 4 devices have 80KB of SRAM1.

The source of the problem is twofold:
First there is a problem with the raw_device_data for this line of devices (STM32G491). The <Ram> section specifies 128KB of total SRAM when it should be 112KB according to the reference manual.
The second problem is that the main_sram is calculated without taking the CCM SRAM into account resulting in more SRAM1 than is actually available.

modm-devices/tools/generator/dfg/stm32/stm.py

Lines 783 to 794 in 0a6b13d

    
           # Correct RAM size 
        
           main_sram = next( (name for (name, size) in mem_model.items() if size == 0), None ) 
        
           if main_sram is not None: 
        
               main_sram_name = next( ram for ram in mem_start.keys() if main_sram.startswith(ram) ) 
        
               # compute the size from total ram 
        
               mem_model[main_sram] = total_ram 
        
               main_sram_index = int(main_sram.split("sram")[-1]) if main_sram[-1].isdigit() else 0 
        
               for name, size in mem_model.items(): 
        
                   mem_index = int(name.split("sram")[-1]) if name[-1].isdigit() else 0 
        
                   if name.startswith(main_sram_name) and mem_index != main_sram_index: 
        
                       mem_model[main_sram] -= size

This second problem is present for all STM32G4 devices and probably any other that specifies SRAM in this way (ST apparently can't decide on a standard for these things 🤷‍♂️)

I'm unsure if it is intended that the CCM SRAM is counted as part of SRAM1 or if it truly is a problem. In either case, I hope you can clarify.

As an added bonus, I found that the STM32G471 devices are lobbed in with the category 4 devices when it should be in the category 3 devices

modm-devices/tools/generator/dfg/stm32/stm.py

Line 438 in 0a6b13d

'name': ['71', '91', 'a1'],

I can make a PR with whatever changes are required if that is desired :)

Add STM32 peripheral RCC enable bit enums

One of the most important thing for any peripheral driver is to be able to enable the root clock for the peripheral. On STM32's this is done via RCC A[H/P]nBENR registers. It would be nice if the database contained an enum like in https://github.com/IntergatedCircuits/STM32_XPD/blob/master/STM32F0_XPD/inc/xpd_rcc.h#L78, where the position consists of a register offset from the lowest A[H/P]nBENR register, and a bit offset within the register. Then the appropriate enum values should be bound to the peripheral instances, allowing a peripheral driver to call a uniform RCC driver API to enable/reset/enable in sleep mode a peripheral.

STM32H7 FDCAN type

In stm32h7-43_53.xml line 209 FDCAN type is stm32-h7, but lbuild not found it.
If I change to stm32, it will be found but the modm FDCAN template driver is not compatible with the STM32H7.

STM32F76x devices have wrong memories

Hunting down my issue with memory corruptions I figured out that the XML of the STM32F76x devices have wrong entries for the memories:

      <memory device-size="g" name="flash" access="rx" start="0x8000000" size="1048576"/>
      <memory device-size="i" name="flash" access="rx" start="0x8000000" size="2097152"/>
      <memory name="dtcm" access="rwx" start="0x20000000" size="65536"/>
      <memory name="sram1" access="rwx" start="0x20010000" size="376832"/>
      <memory name="sram2" access="rwx" start="0x2006C000" size="16384"/>
      <memory name="backup" access="rwx" start="0x40024000" size="4096"/>

But the DTCM is actually 128kB, which would shift the addresses of SRAM1/SRAM2 too.

If you could point me to the right location to fix it...

STM32 DMAMUX request mapping data is broken

We are parsing the DMA IP file in the CubeMX data to obtain the mappings between request id and peripherals/signals:
Raw data example:

        <RefParameter Comment="Request number" DefaultValue="" Group="" Name="Request" Type="list" Visible="false">
                <PossibleValue Comment="MEMTOMEM" Value="DMA_REQUEST_MEM2MEM"/>
                <PossibleValue Comment="DMA_GENERATOR0" Value="DMA_REQUEST_GENERATOR0"/>
                <PossibleValue Comment="DMA_GENERATOR1" Value="DMA_REQUEST_GENERATOR1"/>
                <PossibleValue Comment="DMA_GENERATOR2" Value="DMA_REQUEST_GENERATOR2"/>
                <PossibleValue Comment="DMA_GENERATOR3" Value="DMA_REQUEST_GENERATOR3"/>
                <PossibleValue Comment="DMA_GENERATOR4" Value="DMA_REQUEST_GENERATOR4"/>
                <PossibleValue Comment="DMA_GENERATOR5" Value="DMA_REQUEST_GENERATOR5"/>
                <PossibleValue Comment="DMA_GENERATOR6" Value="DMA_REQUEST_GENERATOR6"/>
                <PossibleValue Comment="DMA_GENERATOR7" Value="DMA_REQUEST_GENERATOR7"/>
                <PossibleValue Comment="ADC1" Value="DMA_REQUEST_ADC1"/>
                <PossibleValue Comment="ADC2" Value="DMA_REQUEST_ADC2"/>
                <PossibleValue Comment="TIM1_CH1" Value="DMA_REQUEST_TIM1_CH1"/>
                <PossibleValue Comment="TIM1_CH2" Value="DMA_REQUEST_TIM1_CH2"/>
                <PossibleValue Comment="TIM1_CH3" Value="DMA_REQUEST_TIM1_CH3"/>
[…]

We are making the assumption that the index in the list represents the request index. Thus, the data is assumed to be ordered by request index and must not have gaps with reserved ids. By accident this seems to be true for G4 but not for H7.

The values refer to constants inside the CubeHAL headers. At least there is only one such table per device family. We have to somehow copy the data from the header and use it in the generator for finding the correct mappings.

@salkinium

Peripheral instances with different feature sets not supported

I'm currently updating the I2C peripheral information. On some controllers (F0, L0) the features of the stm32-extended IP depend on the peripheral instance. I would have expected the DFG to generate multiple <driver> tags for the different instances.

Output:

     <driver name="i2c" type="stm32-extended">
        <feature value="dnf"/>
        <feature device-name="30|70" device-pin="c" value="fmp"/>
        <feature device-name="70" device-pin="r" value="fmp"/>
        <instance value="1"/>
        <instance value="2"/>
     </driver>

Expected:

     <driver name="i2c" type="stm32-extended">
       <feature value="dnf"/>
       <feature value="fmp"/>
       <instance value="1"/>
     </driver>
     <driver name="i2c" type="stm32-extended">
       <feature value="dnf"/>
       <instance value="2"/>
     </driver>

Actions are broken?

Neither the PR event nor the regular scheduled CI Actions is running.

Completely unclear why? Perhaps something was deprecated.

Memory data wrong for some H7

The memory map data in the device file generator is wrong for some H7 devices.

Datasheet H723ZG:

Device file:

<memory name="itcm" access="rwx" start="0x00" size="65536"/>
<memory device-size="e" name="flash" access="rx" start="0x8000000" size="524288"/>
<memory device-size="g" name="flash" access="rx" start="0x8000000" size="1048576"/>
<memory name="dtcm" access="rwx" start="0x20000000" size="131072"/>
<memory name="d1_sram" access="rwx" start="0x24000000" size="524288"/>
<memory name="d2_sram1" access="rwx" start="0x30000000" size="131072"/>
<memory name="d2_sram2" access="rwx" start="0x30020000" size="131072"/>
<memory name="d2_sram3" access="rwx" start="0x30040000" size="32768"/>
<memory name="d3_sram" access="rwx" start="0x38000000" size="65536"/>
<memory name="backup" access="rwx" start="0x38800000" size="4096"/>

The data sheet has max. 320 kB AXI SRAM but the device file says 524288. Also our device files probably can't model the memory that is remappable between ITCM and AXI SRAM.

Device Support

Hi, In the modm repository i can see support for nxp devices but i can't find NXP device file generator in this repository.

Where can i find the NXP device file generator?
Does modm-devices support ESP32 devices?

Add Port multiplexer data to SAM devices

Currently, a typical SAM gpio port looks like this:

<gpio port="A" pin="21">
  <signal driver="eic" name="extint5"/>
  <signal driver="gclk" name="io5"/>
  <signal driver="i2s" name="fs0"/>
  <signal driver="ptc" name="x9"/>
  <signal driver="sercom" instance="3" name="pad3"/>
  <signal driver="sercom" instance="5" name="pad3"/>
  <signal driver="tcc" instance="0" name="wo7"/>
</gpio>

We need to add the peripheral function of the port multiplexer (A-H) to this data, essentially encoding Table 7-1 (PORT Function Multiplexing) from the datasheet. See modm-io/modm#430 for an example where this would have been useful.

http://ww1.microchip.com/downloads/en/DeviceDoc/SAM_D21_DA1_Family_DataSheet_DS40001882F.pdf

STM32U595/5A5/599/5A9 not being generated

It looks like stm.py was set up to ignore STM32U59 and STM32U5A prefixes at some point. We are considering using one of these due to their larger 4M flash sizes and I wanted to view their pinouts in my stm_layout_tk tool, so I updated modm-devices on my system but was surprised to see these ones missing. I eventually found where they were being ignored and removed those lines, but then it errors out about missing memory models for the 599/5A9 series so I put those back on ignore. I also noticed that these are listed as 85C parts and there wasn't an 85C entry in the temperature map.

This is my diff so far:

diff --git a/tools/generator/dfg/stm32/stm.py b/tools/generator/dfg/stm32/stm.py
index 362a04a..00ffb4c 100644
--- a/tools/generator/dfg/stm32/stm.py
+++ b/tools/generator/dfg/stm32/stm.py
@@ -8,8 +8,8 @@ LOGGER = logging.getLogger("dfg.stm.data")

 ignored_devices = \
 [
-    "STM32U59",
-    "STM32U5A",
+    "STM32U599",
+    "STM32U5A9",
     "STM32WL5M",
     "STM32WB1M",
     "STM32WB5M",
diff --git a/tools/generator/dfg/stm32/stm_device_tree.py b/tools/generator/dfg/stm32/stm_device_tree.py
index 7896252..2190680 100644
--- a/tools/generator/dfg/stm32/stm_device_tree.py
+++ b/tools/generator/dfg/stm32/stm_device_tree.py
@@ -26,7 +26,7 @@ class STMDeviceTree:
     """
     rootpath = os.path.join(os.path.dirname(__file__), "..", "..", "raw-device-data", "stm32-devices", "mcu")
     familyFile = XMLReader(os.path.join(rootpath, "families.xml"))
-    TemperatureMap = {0: "6", 105: "7", 125: "3"}
+    TemperatureMap = {0: "6", 85: "6", 105: "7", 125: "3"}

     @staticmethod
     def _format_raw_devices(rawDevices):

I'm not sure why those MCUs were originally put on ignore, so maybe there's some other reason to blacklist them? I can also try and sort out the missing memory models if you like.

Incorrect table for Flash wait-state on STM32L4+ devices

I am playing with a new devkit, the SensorTile.Box which has a STM32L4+ processor in it.

This processor is in modm-devices already so i figured I would make some examples for modm! The default CubeMX project sets the clock to 120MHz, but trying to do that in modm causes a compile time failure. I traced it back to the device XML devices/stm32/stm32l4-r5_r7_r9.xml line 150.

I manually fixed this in my fork, but since I assume this is pulled from cubeMX somehow that doesn't seem like something I should open a PR for (??) The higher clock speed is the main selling point of L4+ so this seems pretty important 😄.

For reference, here is the table(s) from the CubeMX header stm32l4xx_jal_flash.h

           Table 1. HCLK clock frequency for other STM32L4 devices
           +-------------------------------------------------------+
           | Latency         |    HCLK clock frequency (MHz)       |
           |                 |-------------------------------------|
           |                 | voltage range 1  | voltage range 2  |
           |                 |      1.2 V       |     1.0 V        |
           |-----------------|------------------|------------------|
           |0WS(1 CPU cycles)|  0 < HCLK <= 16  |  0 < HCLK <= 6   |
           |-----------------|------------------|------------------|
           |1WS(2 CPU cycles)| 16 < HCLK <= 32  |  6 < HCLK <= 12  |
           |-----------------|------------------|------------------|
           |2WS(3 CPU cycles)| 32 < HCLK <= 48  | 12 < HCLK <= 18  |
           |-----------------|------------------|------------------|
           |3WS(4 CPU cycles)| 48 < HCLK <= 64  | 18 < HCLK <= 26  |
           |-----------------|------------------|------------------|
           |4WS(5 CPU cycles)| 64 < HCLK <= 80  | 18 < HCLK <= 26  |
           +-------------------------------------------------------+

           Table 2. HCLK clock frequency for STM32L4+ devices
           +--------------------------------------------------------+
           | Latency         |     HCLK clock frequency (MHz)       |
           |                 |--------------------------------------|
           |                 |  voltage range 1  | voltage range 2  |
           |                 |       1.2 V       |     1.0 V        |
           |-----------------|-------------------|------------------|
           |0WS(1 CPU cycles)|   0 < HCLK <= 20  |  0 < HCLK <= 8   |
           |-----------------|-------------------|------------------|
           |1WS(2 CPU cycles)|  20 < HCLK <= 40  |  8 < HCLK <= 16  |
           |-----------------|-------------------|------------------|
           |2WS(3 CPU cycles)|  40 < HCLK <= 60  | 16 < HCLK <= 26  |
           |-----------------|-------------------|------------------|
           |3WS(4 CPU cycles)|  60 < HCLK <= 80  | 16 < HCLK <= 26  |
           |-----------------|-------------------|------------------|
           |4WS(5 CPU cycles)|  80 < HCLK <= 100 | 16 < HCLK <= 26  |
           |-----------------|-------------------|------------------|
           |5WS(6 CPU cycles)| 100 < HCLK <= 120 | 16 < HCLK <= 26  |
           +--------------------------------------------------------+

STM32L431 RAM configuration is wrong

This MCU has a total RAM of 64kB, divided into 48kB SRAM1 and 16kB SRAM2. modm configures both of a size of 32kB. Not sure where the error comes from, looking at similar MCU their configuration is fine. Neither I have an idea how to fix that. So I'd ask for help. :-)

Not sure if it would be part of modm-devices as well, maybe the linker script could be updated to include SRAM2 section as well? Switching the MCU to a power savings mode retains SRAM2 only.

STM32G4 Internal temperature sensor has wrong channel mapping

The reference manual p.615 says:

The internal temperature sensor (VTS) is connected to ADC1_INP16 and ADC5_INP4

The adc.hpp file, generated by modm assigns temperature sensor to Channel 17. Similarly, the voltage reference channel is shifted by 1.

class Adc1
{
...
	/// Channels, which can be used with this ADC.
	enum class Channel : uint8_t	// TODO: What is the best type?
	{
		...

		Temperature = 17,
		BatDiv3     = 18,
	};
};

Remapped pins on STM32{F0, G0} are not modelled

Example data sheet (STM32G071) in SYSCFG_CFGR1:

Example data set (STM32G071R(6-8-B)Tx.xml):

<Pin Name="PA11 [PA9]" Position="43" Type="I/O">
	<Signal Name="ADC1_EXTI11"/>
	<Signal Name="COMP1_OUT"/>
	<Signal Name="I2C2_SCL"/>
	<Signal Name="I2S1_MCK"/>
	<Signal Name="SPI1_MISO"/>
	<Signal Name="TIM1_BK2"/>
	<Signal Name="TIM1_CH4"/>
	<Signal Name="USART1_CTS"/>
	<Signal Name="USART1_NSS"/>
	<Signal IOModes="Input,Output,Analog,EXTI" Name="GPIO"/>
</Pin>
<Pin Name="PA9 [PA11]" Position="43" Type="I/O" Variant="PINREMAP">
	<Signal Name="DAC1_EXTI9"/>
	<Signal Name="I2C1_SCL"/>
	<Signal Name="RCC_MCO"/>
	<Signal Name="SPI2_MISO"/>
	<Signal Name="TIM15_BK"/>
	<Signal Name="TIM1_CH2"/>
	<Signal Name="USART1_TX"/>
	<Signal IOModes="Input,Output,Analog,EVENTOUT,EXTI" Name="GPIO"/>
</Pin>
<Pin Name="PA12 [PA10]" Position="44" Type="I/O">
	<Signal Name="COMP2_OUT"/>
	<Signal Name="I2C2_SDA"/>
	<Signal Name="I2S1_SD"/>
	<Signal Name="I2S_CKIN"/>
	<Signal Name="SPI1_MOSI"/>
	<Signal Name="TIM1_ETR"/>
	<Signal Name="USART1_CK"/>
	<Signal Name="USART1_DE"/>
	<Signal Name="USART1_RTS"/>
	<Signal IOModes="Input,Output,Analog,EXTI" Name="GPIO"/>
</Pin>
<Pin Name="PA10 [PA12]" Position="44" Type="I/O" Variant="PINREMAP_10_12">
	<Signal Name="I2C1_SDA"/>
	<Signal Name="SPI2_MOSI"/>
	<Signal Name="TIM17_BK"/>
	<Signal Name="TIM1_CH3"/>
	<Signal Name="USART1_RX"/>
	<Signal IOModes="Input,Output,Analog,EVENTOUT,EXTI" Name="GPIO"/>
</Pin>

#13 removed the GPIOs of PINREMAP variant completely from the dataset, however, this is not the correct response and requires better data modelling.

Data Sources for more Platforms

Just for future reference, here are some machine-readable data sources I found over the time:

Nuvoton NuTool Suite:
- NuTool PinConfigure: contains JSON files describing package, pinout and signals.
- NuTool ClockConfigure: contains JSON files describing some of the clock graph and configuration.
NXP: requires login, unclear data format, something with Java
- MCUXpresso
- i.MX Config Tool

CI has gotten deprecated

Travis-ci.org is deprecated, and we need to migrate ideally to GitHub Actions.

DMA instance count wrong for many STM32F1

All STM32F1 of sizes 4, 6, 8 and b which are neither F105 nor F107 don't have a second DMA instance but it is specified as available in the device files. The same is true for F030xC. These don't define the second instance in the device headers. Some of them also specify signals in the device files for the non-existent DMA2.

I found a workaround in the DMA driver for now but it would be nicer if we could fix the device files.

@salkinium

make generate-stm32 fails for stm32l412c8t

./stm_generator.py STM32L4
[INFO] dfg.stm.reader: Found devices for prefix 'STM32L4': STM32L412C8T, STM32L412C8U, STM32L412CBT, STM32L412CBU, STM32L412K8T, STM32L412K8U, STM32L412KBT, STM32L412KBU, STM32L412R8I, STM32L412R8T, STM32L412RBI, STM32L412RBT, STM32L412T8Y, STM32L412TBY, STM32L422CBT, STM32L422CBU, STM32L422KBT, STM32L422KBU, STM32L422RBI, STM32L422RBT, STM32L422TBY, STM32L431CBT, STM32L431CBU, STM32L431CBY, STM32L431CCT, STM32L431CCU, STM32L431CCY, STM32L431KBU, STM32L431KCU, STM32L431RBI, STM32L431RBT, STM32L431RBY, STM32L431RCI, STM32L431RCT, STM32L431RCY, STM32L431VCI, STM32L431VCT, STM32L432KBU, STM32L432KCU, STM32L433CBT, STM32L433CBU, STM32L433CBY, STM32L433CCT, STM32L433CCU, STM32L433CCY, STM32L433RBI, STM32L433RBT, STM32L433RBY, STM32L433RCI, STM32L433RCT, STM32L433RCY, STM32L433VCI, STM32L433VCT, STM32L442KCU, STM32L443CCT, STM32L443CCU, STM32L443CCY, STM32L443RCI, STM32L443RCT, STM32L443RCY, STM32L443VCI, STM32L443VCT, STM32L451CCU, STM32L451CEU, STM32L451RCI, STM32L451RCT, STM32L451RCY, STM32L451REI, STM32L451RET, STM32L451REY, STM32L451VCI, STM32L451VCT, STM32L451VEI, STM32L451VET, STM32L452CCU, STM32L452CEU, STM32L452RCI, STM32L452RCT, STM32L452RCY, STM32L452REI, STM32L452RET, STM32L452REY, STM32L452VCI, STM32L452VCT, STM32L452VEI, STM32L452VET, STM32L462CEU, STM32L462REI, STM32L462RET, STM32L462REY, STM32L462VEI, STM32L462VET, STM32L471QEI, STM32L471QGI, STM32L471RET, STM32L471RGT, STM32L471VET, STM32L471VGT, STM32L471ZET, STM32L471ZGT, STM32L475RCT, STM32L475RET, STM32L475RGT, STM32L475VCT, STM32L475VET, STM32L475VGT, STM32L476JEY, STM32L476JGY, STM32L476MEY, STM32L476MGY, STM32L476QEI, STM32L476QGI, STM32L476RCT, STM32L476RET, STM32L476RGT, STM32L476VCT, STM32L476VET, STM32L476VGT, STM32L476ZET, STM32L476ZGT, STM32L485JCY, STM32L485JEY, STM32L486JGY, STM32L486QGI, STM32L486RGT, STM32L486VGT, STM32L486ZGT, STM32L496AEI, STM32L496AGI, STM32L496QEI, STM32L496QGI, STM32L496RET, STM32L496RGT, STM32L496VET, STM32L496VEY, STM32L496VGT, STM32L496VGY, STM32L496ZET, STM32L496ZGT, STM32L4A6AGI, STM32L4A6QGI, STM32L4A6RGT, STM32L4A6VGT, STM32L4A6VGY, STM32L4A6ZGT, STM32L4R5AGI, STM32L4R5AII, STM32L4R5QGI, STM32L4R5QII, STM32L4R5VGT, STM32L4R5VIT, STM32L4R5ZGT, STM32L4R5ZGY, STM32L4R5ZIT, STM32L4R5ZIY, STM32L4R7AII, STM32L4R7VIT, STM32L4R7ZIT, STM32L4R9AGI, STM32L4R9AII, STM32L4R9VGT, STM32L4R9VIT, STM32L4R9ZGJ, STM32L4R9ZGT, STM32L4R9ZGY, STM32L4R9ZIJ, STM32L4R9ZIT, STM32L4R9ZIY, STM32L4S5AII, STM32L4S5QII, STM32L4S5VIT, STM32L4S5ZIT, STM32L4S5ZIY, STM32L4S7AII, STM32L4S7VIT, STM32L4S7ZIT, STM32L4S9AII, STM32L4S9VIT, STM32L4S9ZIJ, STM32L4S9ZIT, STM32L4S9ZIY
[INFO] dfg.stm.reader: Parsing 'stm32l412c8t'
[ERROR] dfg.stm.data: Memory model not found for device 'stm32l412c8t'
make: *** [generate-stm32] Error 1

git submodule status
 ac6a86c6a81ab316f2e4780c5aa7ab794b9e7fb5 cmsis-header-stm32 (ac6a86c)

Same with cmsis-header-stm32 at master.

	<instance device-series="e70\|v70\|v71" device-pin="n\|q" device-flash="19\|20" device-variant="b" value="1"/>
	<instance device-series="e70\|v71" device-pin="n\|q" device-flash="19\|20\|21" device-variant="a\|b" value="1"/>

	# Correct RAM size
	main_sram = next( (name for (name, size) in mem_model.items() if size == 0), None )
	if main_sram is not None:
	main_sram_name = next( ram for ram in mem_start.keys() if main_sram.startswith(ram) )
	# compute the size from total ram
	mem_model[main_sram] = total_ram
	main_sram_index = int(main_sram.split("sram")[-1]) if main_sram[-1].isdigit() else 0
	for name, size in mem_model.items():
	mem_index = int(name.split("sram")[-1]) if name[-1].isdigit() else 0
	if name.startswith(main_sram_name) and mem_index != main_sram_index:
	mem_model[main_sram] -= size

modm-io / modm-devices Goto Github PK

modm-devices's People

Contributors

Stargazers

Watchers

Forkers

modm-devices's Issues

Recommend Projects

Recommend Topics

Recommend Org