XMC™ Forum Discussions

Hi.

How can I be reliable detect the baudrate from a can bus?


I set the Node in Mode: Bit Timing Mode (CFMODL:10b).

If i set CFSEL to 0 and poll the NFCR0->CFC to get the minimum value,
it varies a lot.. ( 0x2FC .. 0x789 @ 125k; 0xC7 .. 0x1FE @ 250k; 0x01 .. 0xBF @ 500k),


If i set CFSEL to 1 and poll the NFCR0->CFC to get the minimum value,.
it varies a lot.. (0x51 .. 0x1BC @ 250k; 0x01 .. 0x5C @ 500k),


So I can not find a safe value to distinguish whether it is an outlier at the low, or at least the high baudrate.


Is the a code snippet or a app note available?
What is the best CFSEL value for unknown Data on the CAN Bus? Show Less

Hi Infineon Forum,

my problem is similar to " XMC1100 Problems changing BMI from UART to SWD"
I develop new device with XMC1202Q24X0032ABXUMA1 and XMC1402Q040X0032AAXUMA1.(The Samples I get in mai and june.)


My Problem Is to get connection to the XMC1402 with SWD0, after I switched BMI ASC_BSL 0xFFC0 to User Mode(HAR) SWD0 0xF8C7
with Segger J-Link Commander to Mode 2, connetction to XMC is lost.

I tried J-Link Commander again, but get only ErrorCode: -262

With Memtool 4.7 (and COMXX: Jlink CDC UART Port) I get "Can´t connect to Target"

With Hterm I tried with COMxx After I send 0x00 and 0x6C, I don´t get 0x5D

Here a picture from J-Link Commander

Show Less

Hi All,

I am attempting to read memory via EBU interface.
In my hardware ALE is connected to pin AD11 and CLE is connected to pin AD12.
Based on addressing alignment mentioned in reference manual 14.6.7 I i understand that internal pin mapping is ABH [16:1], and external pin mapping is AD[15:0]
With this understanding, since my CLE is connected to pin AD12 , internally its connected to ABH13 hence I am wrtiting command at address 0x60002000.
Similarly ALE is connected to pin AD11, internally its connected to ABH12 hence i am writing command at address 0x60001000.

*(volatile uint16_t*)(0x60001000) = 0x0020;// ALE
*(volatile uint16_t*)(0x60002000) = 0x0090;// CLE

However, when i dont see expected result. Like when i am writing address 0x0020 i see dont see ALE going high at all.

Can someone please let me know if my understanding on addressing is correct ?

P.S- Also, i have tried using addressing based on external pin mapping AD[15-0], i still dont see any difference.

Regards,
Query1920 Show Less

I have spent the last days evaluating and reviewing the XMC FOC sensorless libraries for an ebike solution proof-of-concept.
Here I expose certain thoughts and questions that came up...

- I have noticed that the last version of the library (4.2.8) is provided at the DAVE repos as a pre-compiled library without chance to access the source code.
However I saw that previous versions are provided open-sourced with only some modules pre-compiled (like the PLL position estimator).
This implies certain restrictions when developing on-top solutions. Is the library offered somewhere open-source or at least partially open-sourced (like it used to be)? Would it be possible to get such code under request?

- Having a position feedback over Hall sensors might be required/interesting for certain applications. It is the case for my application. However, with this pre-compiled FOC library I am not even able to try to include such modification on my own.
With previous versions it was possible for developers to include and evaluate such functionalities. Is there really no way now to give a try to a Hall sensored self-implementation with the latest version?

- Previous versions have a comprehensive documentation. For the latest version all the documentation is a brief Help in DAVE which is somehow poor and certainly misleading in some cases.
No plan for an updated further documentation of the library?

- There are certain unstable and undesired behaviors of the library that would require in-depth analysis and debugging before going into an end-product, therefore my need of having the library code. See for example the video attached.

In the video I am running the motor under torque control at a constant torque and maximum controller output of 50%. It can be observed how the motor reacts to an opposite load (my fingers) differently in 2 consecutive attempts.
The first time, the motor slows down until stopped and after releasing the load, the motor resumes spinning normally (this is how it should be). The second time, the motor slows down until stopped and remains stall (this should not be).
Am I very wrong about this?




I hope someone find this thoughts interesting and can help me out with my questions.
Thanks for reading and all the best. Show Less

Hi All,

I am having trouble interfacing XMC4700 (100 pins)with NAND flash via EBU. In my project EBU lines are shared with NAND flash and FPGA. FPGA is configured to pull up all AD/CLE/ALE lines.
So on power up all lines are pulled up. Even though lines are pulled high, when EBU is initialized, EBU should take control of these lines and control accordingly.
I have configured all EBU related general control and region control registers. I have made sure-
1. EBU is enabled on power on
2. Master mode is selected
3. Region 0 is selected and write is enabled for region 0.
4. All EBU related pins are configured to Hardware control as per the IO pin assignment.
5. EBUCLK status is enabled.
6. 16 bit mode is selected

Inspite of all these configuration, when i try to write cmd at 0x60000000 none of the EBU related pin seems to be changing.
For ex. since i have enabled default Region-0 in ADDRSEL register and Arb_mode as master in MODCON register, as per the user manual CS0 should go low but i dont see any changes on CS0.
To me it looks like, even though EBU is in master mode its still acting like a No Bus mode where it doesnt have control over ports pin yet

Just to ensure FPGA is not overwriting on AD lines, I tried toggling one of the AD line by making it GPIO and it worked as expected. \
Below is my EBU configuration

    // These values get written to the CLC register.
    
       configuration.ebu_clk_config.ebu_clk_mode           = 1U;
       configuration.ebu_clk_config.ebu_div2_clk_mode      = 1U;
       configuration.ebu_clk_config.ebu_clock_divide_ratio = 1U;
																 
    // These values get written to the MODCON register.
       configuration.ebu_mode_config.ebu_sdram_tristate   = 1U;														 
       configuration.ebu_mode_config.ebu_extlock          = 1U; 
       configuration.ebu_mode_config.ebu_arbsync          = 0U;
       configuration.ebu_mode_config.ebu_arbitration_mode = 3U;														 
       configuration.ebu_mode_config.bus_timeout_control  = 0U;
       configuration.ebu_mode_config.ebu_ale_mode         = 1U; // Output is ALE

       // These values get written to the USERCON register.
        configuration.ebu_free_pins_to_gpio.address_pins_gpio = 0x1FFU;
	configuration.ebu_free_pins_to_gpio.adv_pin_gpio      = 0U;
    
       region.read_config.ebu_bus_read_config.raw0   = 0x20500024U;
       region.read_config.ebu_bus_read_config.raw1   = 0x00000000U;
       region.write_config.ebu_bus_write_config.raw0 = 0x20500004U;
       region.write_config.ebu_bus_write_config.raw1 = 0x00000000U;
		
		 
	ebu_status = XMC_EBU_Init(XMC_EBU, &configuration);
		
	if (ebu_status != XMC_EBU_STATUS_OK)
	{
		error_flag = true;
	}
	XMC_EBU_ConfigureRegion(XMC_EBU, &region);
        XMC_EBU_AddressSelectEnable(XMC_EBU, 1U, 0U);
	XMC_EBU_AddressSelectDisable(XMC_EBU, 2U, 0U);
	XMC_EBU_AddressSelectDisable(XMC_EBU, 4U, 0U);

Below is my configuration for ports--( i have just mentioned configuration till AD4 below but similar configuration is present for all other pins as welli.e. AD5-AD15, CLE, ALE, CS, RD And WR) 
XMC_GPIO_CONFIG_t config;

    config.mode = XMC_GPIO_MODE_OUTPUT_PUSH_PULL;
    config.output_level = XMC_GPIO_OUTPUT_LEVEL_LOW;
    config.output_strength = XMC_GPIO_OUTPUT_STRENGTH_STRONG_SHARP_EDGE;

    XMC_GPIO_Init(EBU_AD0_PORT, EBU_AD0_PIN, &config);
    XMC_GPIO_SetHardwareControl(EBU_AD0_PORT, EBU_AD0_PIN, XMC_GPIO_HWCTRL_PERIPHERAL2);

    XMC_GPIO_Init(EBU_AD1_PORT, EBU_AD1_PIN, &config);
    XMC_GPIO_SetHardwareControl(EBU_AD1_PORT, EBU_AD1_PIN, XMC_GPIO_HWCTRL_PERIPHERAL2);

    XMC_GPIO_Init(EBU_AD2_PORT, EBU_AD2_PIN, &config);
    XMC_GPIO_SetHardwareControl(EBU_AD2_PORT, EBU_AD2_PIN, XMC_GPIO_HWCTRL_PERIPHERAL2);

    XMC_GPIO_Init(EBU_AD3_PORT, EBU_AD3_PIN, &config);
    XMC_GPIO_SetHardwareControl(EBU_AD3_PORT, EBU_AD3_PIN, XMC_GPIO_HWCTRL_PERIPHERAL2);

    XMC_GPIO_Init(EBU_AD4_PORT, EBU_AD4_PIN, &config);
    XMC_GPIO_SetHardwareControl(EBU_AD4_PORT, EBU_AD4_PIN, XMC_GPIO_HWCTRL_PERIPHERAL2);

Is there anything I am missing on my configuration ?

Any information is appreciated.

Thanks Show Less

Hello All,
I am currently working on an audio project where I am required to collect audio samples for something similar to speech processing. I
am using the XMC4500 hexagon application kit for this purpose. I am using the on board TLV320AIC audio codec to recieve the data.
This codec serves me as an I2S slave. I am using the USIC0_Channel1 as the I2S master. I am working on 48 kHz sampling rate.
The baud rate for communication is 1536105 hz. Following is the code for the initialization of the (USIC0_CH1) I2S channel.

I tested the audio trannsmission and it works fine. I can hear exactly the audio I send (DAC functionality of the codec).Whatever I sent
on the left channel I could hear in my left ear piece and similarly on the right ear piece. But when I try to get the recorded audio data
from the codec (using ADC functionality of the codec), it doesnot work the way exactly I want. The hardware configuration of the codec
is made such that only the left channel of the microphone is enabled inside the codec for sampling. The right channel of the microphone
is grounded. I have moreoever, as seen in the code, used separate interrupt nodes for STANDARD_RECEIVE (left channel data
interrupt) and ALTERNATE_RECEIVE (right channel data interrupt) events. Hence, according to me I should only receive data in the
left channel interrupt and no data in the right channel interrupt. By this I mean that, in the left channel i should have some meaningful
data, whereas in the right channel I should receive only '0'(since it is grounded). But I receive data in both the channels. And to my
suprise, I have more number of zeros in the left channel buffer whereas not a single buffer element is '0' in the right channel buffer.

Before this, I have also tried to test my receive interrupt routine using the internal loopback mode available in the USIC channel
(the transmitter is directly connected to the receiver internally, disconnecting the external pins). In this case, it worked well, I could get
the data exactly as I had sent. But the only problem was that, the channels were interchanged. The left_channel_buffer had all the
data tranmitted on the right channel in my trnamission routine and right_channel_buffer had all the data transmitted on the left_channel
I investigated but could not find any reason behind this behaviour.

I highly doubt that there is something wrong in my receive interrupt routine. I am very frustated at this point. It would really be a great
help if somebody can help me.
Thanks in advance.

void AudioI2S_INIT(void){

	XMC_GPIO_Init(PIN_I2S_MRST, &I2S_MRST);
	XMC_GPIO_Init(PIN_I2S_MTSR, &I2S_MTSR);
	XMC_GPIO_Init(PIN_I2S_SCLK, &I2S_SCLK);
	XMC_GPIO_Init(PIN_I2S_WA, &I2S_WA);

	/* Initialize USIC channel in I2S mode */
	XMC_I2S_CH_Init(XMC_I2S0_CH1, &I2S_CONFIG_0_channel_config);

	/* Set the frame length, word length and system word length */
	XMC_I2S_CH_SetWordLength(XMC_I2S0_CH1, 16U);
	XMC_I2S_CH_SetFrameLength(XMC_I2S0_CH1, 16U);
	XMC_I2S_CH_SetSystemWordLength(XMC_I2S0_CH1, 16U);

	/* Set MSB data shift direction */
	XMC_I2S_CH_SetBitOrderMsbFirst(XMC_I2S0_CH1);

	/* Set input source for input stage dx0 (receive pin) */
	XMC_I2S_CH_SetInputSource(XMC_I2S0_CH1, XMC_I2S_CH_INPUT_DIN0, USIC0_CH1_DX0B);

	/* Configure the clock polarity and clock delay */
	XMC_I2S_CH_ConfigureShiftClockOutput(XMC_I2S0_CH1,  XMC_I2S_CH_BRG_SHIFT_CLOCK_OUTPUT_SCLK); //to be tested

	NVIC_SetPriority(I2S_LEFTCHANNEL_RX_INT, NVIC_EncodePriority(NVIC_GetPriorityGrouping(),RX_PREEMPT_PRIOR, RXTX_SUB_PRIOR));
	NVIC_EnableIRQ(I2S_LEFTCHANNEL_RX_INT);

	NVIC_SetPriority(I2S_RIGHTCHANNEL_RX_INT, NVIC_EncodePriority(NVIC_GetPriorityGrouping(),RX_PREEMPT_PRIOR, RXTX_SUB_PRIOR));
	NVIC_EnableIRQ(I2S_RIGHTCHANNEL_RX_INT);

	/* Set the service request line for the standard receive event*/
	XMC_I2S_CH_SelectInterruptNodePointer(XMC_I2S0_CH1, XMC_I2S_CH_INTERRUPT_NODE_POINTER_RECEIVE, SR_RQ2);

	/*Set the service request line for the alternative receive event*/
	XMC_I2S_CH_SelectInterruptNodePointer(XMC_I2S0_CH1, XMC_I2S_CH_INTERRUPT_NODE_POINTER_ALTERNATE_RECEIVE, SR_RQ3);

	/* Enable the standard receive event and alternate receive event */
	XMC_I2S_CH_EnableEvent(XMC_I2S0_CH1, XMC_I2S_CH_EVENT_STANDARD_RECEIVE | XMC_I2S_CH_EVENT_ALTERNATIVE_RECEIVE);

	/* Start the I2S channel */
	XMC_I2S_CH_Start(XMC_I2S0_CH1);
}

void left_channel_rx_handler(void){

	if(XMC_I2S_CH_GetStatusFlag(XMC_I2S0_CH1) & XMC_I2S_CH_STATUS_FLAG_RECEIVE_INDICATION){			//Left channel

		XMC_I2S_CH_DisableEvent(XMC_I2S0_CH1, XMC_I2S_CH_EVENT_STANDARD_RECEIVE);
		RecDataTemp2 = (uint16_t) XMC_I2S_CH_GetReceivedData(XMC_I2S0_CH1);
		XMC_I2S_CH_ClearStatusFlag(XMC_I2S0_CH1, XMC_I2S_CH_STATUS_FLAG_RECEIVE_INDICATION);
		left_channel_buff[left_channel_index] = RecDataTemp2;
		left_channel_index++;

		if(left_channel_index >= size_of_rx_buff){
			left_channel_index = 0;
			new_ldata_flag = true;
		}
		XMC_I2S_CH_EnableEvent(XMC_I2S0_CH1, XMC_I2S_CH_EVENT_STANDARD_RECEIVE);
	}
}

void right_channel_rx_handler(void){

	if(XMC_I2S_CH_GetStatusFlag(XMC_I2S0_CH1) & XMC_I2S_CH_STATUS_FLAG_ALTERNATIVE_RECEIVE_INDICATION){			//Right channel

		XMC_I2S_CH_DisableEvent(XMC_I2S0_CH1, XMC_I2S_CH_EVENT_ALTERNATIVE_RECEIVE);
		RecDataTemp2 = (uint16_t) XMC_I2S_CH_GetReceivedData(XMC_I2S0_CH1);
		XMC_I2S_CH_ClearStatusFlag(XMC_I2S0_CH1, XMC_I2S_CH_STATUS_FLAG_ALTERNATIVE_RECEIVE_INDICATION);
		right_channel_buff[right_channel_index] = RecDataTemp2;
		right_channel_index++;

		if(right_channel_index >= size_of_rx_buff){
			right_channel_index = 0;
			new_rdata_flag = true;
		}
		XMC_I2S_CH_EnableEvent(XMC_I2S0_CH1, XMC_I2S_CH_EVENT_ALTERNATIVE_RECEIVE);
	}
}

P.S: I am not using RXFIFO (RXFIFO size is '0'). I am right now reading directly from the RBUF. Show Less

I am playing with 06_VADC_Synchronous_Conversions_Queue_Source example code, and I changed it a little bit.
Now it converts only G0_1 and G1_1 using master and slave configuration. I also changed XMC_CCU8_SLICE_SR_ID_2 to be raised when PERIOD_MATCH occurs.
The strange thing is that if I don't call XMC_CCU8_SLICE_SetTimerCompareMatch then only conversion on master VADC kernel occurs. The result register in slave kernel is 0.
If I do call XMC_CCU8_SLICE_SetTimerCompareMatch, then kernels do synchronous conversion and slave result register is not 0. It seems very strange to me, because changing compare value should not have influence on PERIOD_MATCH and for sure not on VADC behaviour.
I am playing with this example because I have big problems with VADC on my bigger project, where similar, unexplainable to me, things happen.

I attach modified code (see line 110)

Please help me to understand that Show Less

Hello everyone,

I got a strange communication issue between a master (XMC 4500) and more than one slave (XMC1201 + port expander card which communicates via SPI).
On my board it's possible to plug in 2 different cards on the same SPI-port (every card gets an chip select and the master toggles between them).

When the master communicates with one slave (MCP23S17 -> port expander card), the waveform of the MISO looks like expected (image below).


The problem starts when the master communicates with both cards -> port expander card and an additional XMC1201 in slave mode (SPI003-app was used).
This looks like the slave is pulling up the MISO-line very strong and the MCP23S17 can't pull the line to ground when it gets the /CS. So the master thinks, due to the wrong voltage level, that the slave sends 0xFF instead of 0x00.



I'm not sure what I can do to prevent this behaviour. In a workaround I could configure the MISO-line to tristate when the end-of-message interrupt occures and reconfigure it at the start of the message (not really smart imho). This could prevent data corruption for other cards.

Thanks in advance for any help !

best regards
Sebastian Show Less

Hello.

Just wanted to check if anyone else is seeing this problem.

We have set up a Gateway node connecting 2 CANnets.
Since the HW Gateway has it quirks http://see https://www.infineonforums.com/threads/5360-Problems-with-FIFO-Gateway-on-XMCs-4400-Multican?, we opted for setting up 4 RX FIFOs and let the irq routines do the data shuffling.

This scheme works almost OK, but we are experiencing MSGLST from a MO in the RXFIFO even though the FIFO is not full.
The CAN_RXOF irq is enabled (and tested OK), but is not asserted in these MSGLST cases.
Fault rate is about 1-2 messages in about 40 millions, so the FIFOs wrapps around numerous times. We also have a FIFO highwater-mark monitor, and it shows that the FIFO is filled with max 2 unread messages at the time MSGLST is set.
FIFO sizes vary from 8 to 20 MOs.
Have also implemented a test command where the RX irq routine can skip n readouts, hence filling the FIFO, and that also works fine. Next irq that reads, empties the FIFO.

We are using the MSIMASK/MSID HW registers to find out which FIFO to read from.

In all the multiCAN examples we have come across, there is no examples on how to empty multiple RXFIFO using the MSIMASK/MSID HW registers.

Hoping someone can chime in on this one.

Here is our irq routine:

    bool receive(CanMessage* msg)
    {
        uint32_t pendingIndex;
        int i;
//        printf("%s:\n", m_owner);
//        printf("MSPND:   %08x %08x\n", CAN->MSPND[1], CAN->MSPND[0]);
//        printf("MSIMASK: %08x %08x\n", m_msimask[1], m_msimask[0]);

        if (m_irqOwner != (uint32_t)(PPB->ICSR & PPB_ICSR_VECTACTIVE_Msk) - 16) {
            Can *can = Can::getInstance();
            can->s_wrongIRQ++;
            return false;
        }

        for (i=0; i<2; i++) {
            CAN->MSIMASK = m_msimask;
            pendingIndex = CAN->MSID;
//            printf("%-15s[%d] %d\n", "pendingIndex", i, pendingIndex);

            if (pendingIndex == CAN_MSI_NO_PENDING) {
                if (i == 1) {
                    return false;
                }
                else {
                    continue;
                }
            }
            CLR_BIT(CAN->MSPND, pendingIndex);
            pendingIndex += 32*i;
            break;
        }
//        printf("%-15s %d\n", "pendingIndex", pendingIndex);
        uint8_t baseIndex = m_messageObjects.front().getNumber();
        XMC_CAN_MO_t* baseMoPtr = m_messageObjects.front().getMoPtr();
        XMC_CAN_FIFO_SetSELMO(baseMoPtr, pendingIndex);
        //printf("%-15s %d\n", "baseIndex", baseIndex);        
        return m_messageObjects[pendingIndex - baseIndex].receive(msg);
    }

    bool receive(CanMessage* msg)
    {
        uint32_t mo_message_lost = (uint32_t)((m_xmcCanMo.can_mo_ptr->MOSTAT) & CAN_MO_MOSTAT_MSGLST_Msk) >> CAN_MO_MOSTAT_MSGLST_Pos;
checkAgain:
        m_xmcCanMo.can_mo_ptr->MOCTR = CAN_MO_MOCTR_RESNEWDAT_Msk | CAN_MO_MOCTR_RESRXPND_Msk; // reset NEWDAT & RXPND

        if ((((m_xmcCanMo.can_mo_ptr->MOAR) & CAN_MO_MOAR_IDE_Msk) >> CAN_MO_MOAR_IDE_Pos) == 1U) { // 29-bit ID
            uint32_t identifier = (m_xmcCanMo.can_mo_ptr->MOAR & CAN_MO_MOAR_ID_Msk);
            newCanMessage(msg, identifier & 0x000000ff);
            msg->size       = (uint8_t)((uint32_t)((m_xmcCanMo.can_mo_ptr->MOFCR) & CAN_MO_MOFCR_DLC_Msk) >> CAN_MO_MOFCR_DLC_Pos);
            msg->identifier = identifier;
            msg->nodeNum    = (identifier & 0x0000ff00) >> 8;
            uint32_t* dataPtr = reinterpret_cast(msg->data);
            if (msg->size > 0) {
                dataPtr[0] = m_xmcCanMo.can_mo_ptr->MODATAL;
            }
            if (msg->size > 4) {
                dataPtr[1] = m_xmcCanMo.can_mo_ptr->MODATAH;
            }
        }

        uint32_t mo_new_data_available = (uint32_t)((m_xmcCanMo.can_mo_ptr->MOSTAT) & CAN_MO_MOSTAT_NEWDAT_Msk) >> CAN_MO_MOSTAT_NEWDAT_Pos;
        uint32_t mo_recepcion_ongoing = (uint32_t)((m_xmcCanMo.can_mo_ptr->MOSTAT) & CAN_MO_MOSTAT_RXUPD_Msk) >> CAN_MO_MOSTAT_RXUPD_Pos;

        if ((mo_new_data_available) || (mo_recepcion_ongoing)) {
            Can::s_checkedAgain++;
            goto checkAgain;
        }

        if (mo_message_lost) {
            m_xmcCanMo.can_mo_ptr->MOCTR = CAN_MO_MOCTR_RESMSGLST_Msk; // reset lost bit
            if (Can::s_gatewayEnabled) {
                if ((m_number>=CAN_RX12_MOSTART) && (m_number<=CAN_RX12_MOEND)) {
                    Can::s_lostCntr1++;
                } else {
                    if ((m_number>=CAN_RX2_MOSTART) && (m_number<=CAN_RX2_MOEND)) {
                        Can::s_lostCntr2++;
                    }
                }
            } else {
                if ((m_number>=CAN_RX_MOSTART) && (m_number<=CAN_RX_MOEND)) {
                    Can::s_lostCntr1++;
                }
            }
            //            panic_printf(PANIC_USER, "CAN MSG LOST, MO%02d, idle %d%%", m_number, getIdlePercent());
            ////            panic_printf(PANIC_USER, "LOST MO%02d %08x %08x", m_number, CAN->MSPND[1], CAN->MSPND[0]);
            ////            printf("\n\nLOST MO%02d %08x %08x\n\n", m_number, CAN->MSPND[1], CAN->MSPND[0]);
            //            return false;
        }


        //        if (mo_recepcion_ongoing) {
        //            panic_printf(PANIC_USER, "CAN MSG RX BUSY, MO%02d", m_number);
        //        }

        return true;
    }

(Also opened a support case: Case:3740999) Show Less

I'm newbie in ARM microcontrollers. But I successfully implement DMX-512 for driving leds (9-ch BCCU, UART etc) and it works fine.
But I have pack of troubles with implementing RDM (remote device management). Maybe anyone have example, how to implement it with XMC MCUs? Show Less