Hi Tom,

The simple answer here is: Don't use UARTDRV.

UARTDRV is a very generic piece of SW that is intended to provide a minimum level of functionality across all EFM32/EFR32/EZR32 devices from the original Series 0 Gecko (EFM32G) to the Series 2 xGM210P module you're using.  Consequently, it doesn't handle any kind of implementation specific features a lot of customers need, and it rather limits what you can do with the DMA.

Which is fine... You can do more coding for the USART directly as you need to do it.  Check out our examples here:

https://github.com/SiliconLabs/peripheral_examples/tree/master/series2/usart

Specifically, the asynchronous ones.  If you want to use 9-bit data frames, you'll need to add a line like this:

init.databits = usartDatabits9;

You'll also need to access the data registers like this:

uint16_t myRxData = USART_RxDouble(USART0);

uint16_t myTxData = 0x155;

USART_TxDouble(USART0, myTxData);

That's about it in a very simple sense.  You can check on what API functions are available through emlib here:

https://docs.silabs.com/gecko-platform/latest/emlib/api/efr32xg21/group-usart

The register listing in the xG21 reference manual will help you understand some of the other configuration related things you might want to do, such as using that 9th bit for something like mark/space wake-up.

Regards,

John

Hi Jon,

BGM111 uses the EFR32BG1, as you've noted, so the reference manual you are looking at is correct.

John

Hi Pavlo,

Unless you have to use it, I would highly suggest avoiding 93Cxx type EEPROMs as they are not really SPI-compatible and opting instead for something like an equivalent 25xxx type device, e.g. AT25010B.

But, at least for starters, your code has a fundamental problem in that you are driving the chip select to the EEPROM low when it is actually active high.  I would try fixing that firast.

Regards,

John

Hi Pavlo,

Unless you have to use it, I would highly suggest avoid 93Cxx type EEPROMs as they are not really SPI-compatible and opting instead for something like an equivalent 25xxx type device, e.g. AT25010B.

But, at least for starters, your code has a fundamental problem in that you are driving the chip select to the EEPROM low when it is actually active high.  I would try fixing that firast.

Regards,

John

No, we haven't. Let us know how it goes

In all seriousness, this isn't a sensor we've placed on an 8-bit board, AFAIK, so I don't have any particular guidance for you other than:

https://github.com/BoschSensortec/BME280_driver

I'm more than happy to start with someone else's driver code.  It means that, ideally, the only thing I should have to worry about is the low-level hardware stuff on my end.

Regards,

John

No, we haven't. Let us know how it goes

In all seriousness, this isn't a sensor we've placed on an 8-bit board, AFAIK, so I don't have any particular guidance for you other than:

https://github.com/BoschSensortec/BME280_driver

I'm more than happy to start with someone else's driver code.  It means that, ideally, the only thing I should have to worry about is the low-level hardware stuff on my end.

Regards,

John

Hi Ryan,

If by other processors you mean other ARM Cortex M-series devices, then you will not observe anything different on EFR32/EFM32.

We provide stock GCC in Simplicity Studio just like everyone else does in their free tools, so the behavior of malloc will be identical (which is what I suspect most people would want anyway).

If you need malloc to behave in a particular way, your best bet is to write your own implementation. There are plenty of examples out there given that malloc has been the source of many security holes and everyone and their aunts and uncles have taken to fixing it at some point.

Regards,

John

Hi Ryan,

If by other processors you mean other ARM Cortex M-series devices, then you will not observe anything different on EFR32/EFM32.

We provide stock GCC in Simplicity Studio just like everyone else does in their free tools, so the behavior of malloc will be identical (which is what I suspect most people would want anyway).

If you need malloc to behave in a particular way, your best bet is to write your own implementation. There are plenty of examples out there given that malloc has been the source of many security holes and everyone and their aunts and uncles have taken to fixing it at some point.

Regards,

John

Hi Ryan,

If by other processors you mean other ARM Cortex M-series devices, then you will not observe anything different on EFR32/EFM32.

We provide stock GCC in Simplicity Studio just like everyone else does in their free tools, so the behavior of malloc will be identical (which is what I suspect most people would want anyway).

If you need malloc to behave in a particular way, your best bet is to write your own implementation. There are plenty of examples out there given that malloc has been the source of many security holes and everyone and their aunts and uncles have taken to fixing it at some point.

Regards,

John

Also, see what happens when you try something like "-d cortexm0".  Interestingly, that worked on my STK.

As we are working remotely in my area, I do not have a target to test with a STK placed in debug out mode.

John