Taking a look at STM32G0 series

[dannyf]

got my arduino clone up and running on this thing. haven't thoroughly tested it yet.

not bad for a sub-$1 chip.

[dannyf]

I'd likely try HSI

all i did is to solder the chip to the board. no other components at all.

the HSI is spec'd within 1%. I would expect it to be accurate to <0.2%. more than enough to run uart at 38.4K.

[dannyf]

one tip: you will need to set the RTCAPBEN bit in the RTC_APB register to get the RTC working. Not needed on the F0/F1 chips.

it took me a while to figure it out

[dannyf]

LSI is fairly accurate as well: of the two I tested, they ran about about 32.1K - 32.2Khz, vs. 32.0K spec.

[ag123]

I'd need to catch up on this. on a different note, i've got a 'brainy' idea about 'io extender'
chips like PCA9535 cost a 'little fortune' on AliX
https://www.nxp.com/products/interfaces ... 5_PCA9535C
https://www.ti.com/product/PCA9535
https://www.aliexpress.com/item/1005002619625688.html
if need be stm32g0 can be used in multiples (e.g. pairs) can literally do *multi-processing*, and they can still exchange data e.g. over uart etc.
that goes much further than simply an "io extender" while it doesn't cost that much more.
I'd guess a reason is that chips like PCA9535 are likely microcontrollers in themselves, hence the higher costs. and partly, that those are not made in the same volumes as like microcontrollers, e.g. like 10 - 100s of wafers 10s to 100s of thousands of chips.

[dannyf]

You just need to write a slave and a master. For non framed transmission (uart and spi) it is fairly simple.

You can also write a set of routines to simulate logic gates.

[dannyf]

they ran about about 32.1K - 32.2Khz, vs. 32.0K spec.

with a calibrated LSI driving the RTC, I gained < 1s over 3 hours, or better than 100ppm.

The LSI frequency does fluctuate so there is a level of 'entropy' here.

[dannyf]

It'd take a little time to figure out what can be mapped at any one time on the shared and dedicated paxx pins

if you find it helpful, this is how I deal with such problems:
1. I often use a set of macros to determine where a pin is mapped -> in the code, if such a macro exists, I would execute it.

for example, here is how I map uart2 pins:

Code: Select all

#define U2TX2PIN()					U2TX2PA2()			//u2tx to pa2, pa14
//#define U2RX2PIN()					U2RX2PA3()		//u2rx to pa3, pa15

in this case, uart2 tx pin is mapped to PA2 (or PA14 if you so desire, on a G030), and uart2 rx is not used. My uart2 initialization code has a piece like this:

Code: Select all

#if defined(U2TX2PIN)
	U2TX2PIN();							//activate tx pin
#endif

#if defined(U2RX2PIN)
	U2RX2PIN();							//activate rx pin
#endif

2. the above only indicates if how a logic pin (U2TX for example) is mapped to a physical pin. the actual mapping is done separately:

Code: Select all

//u2tx/rx pins
#define U2TX2PA2()					pinAFIO(PA2, AFIO1)	//U2TX to PA2, AF1
#define U2RX2PA3()					pinAFIO(PA3, AFIO1)	//U2RX to PA3, AF1
#define U2TX2PA14()					pinAFIO(PA13,AFIO1)	//U2TX to PA14,AF1
#define U2RX2PA15()					pinAFIO(PA15,AFIO1)	//U2RX to PA15,AF1

obviously, which of the pins is activated will depend on how the U2TXPIN() macro is mapped (to PA2 or PA14, in this case.

3. The actual mapping is done by the pinAFIO() routine.

Code: Select all

//configure pin for AFIO
void pinAFIO(PIN_TypeDef pin, AFIO_TypeDef AFIOn) {
	uint32_t pos;
	GPIO_TypeDef *gpio;

	gpio=GPIO_PinDef[pin].gpio;
	//mask=GPIO_PinDef[pin].mask;
	pos = pinPos(GPIO_PinDef[pin].mask);
	gpio->MODER = (gpio->MODER &~(/*0b11*/0x03<<(2* pos))) | (/*0b10*/0x02<<(2* pos));
	gpio->OTYPER &=~(1<< pos);
	gpio->OSPEEDR = (gpio->OSPEEDR &~(/*0b11*/0x03<<(2* pos))) | (/*0b01*/0x01<<(2* pos));
	if (pos<8) gpio->AFR[0] = (gpio->AFR[0] &~(0x0f<<(4*( pos%8)))) | ((AFIOn-AFIO0)<<(4*( pos%8)));
	else gpio->AFR[1] = (gpio->AFR[1] &~(0x0f<<(4*( pos%8)))) | ((AFIOn-AFIO0)<<(4*( pos%8)));
}

it effectively resets a pin and activates AFIO.

4. it is all anchored to a table, GPIO_PinDef[], defined as:

Code: Select all

const PIN2GPIO GPIO_PinDef[]={
#if defined(GPIOA)
	{GPIOA, 1<<0},						//STM32duino Pin  0 = RP0/PB0/CHIP PIN4
	{GPIOA, 1<<1},						//STM32duino Pin  1 = RP1/PB1/CHIP PIN5
	{GPIOA, 1<<2},						//STM32duino Pin  2 = RP2/PB2/CHIP PIN6
	{GPIOA, 1<<3},						//STM32duino Pin  3 = RP3/PB3/CHIP PIN7
	{GPIOA, 1<<4},						//STM32duino Pin  4 = RP4/PB4/CHIP PIN11
	{GPIOA, 1<<5},						//STM32duino Pin  5 = RP5/PB5/CHIP PIN14
	{GPIOA, 1<<6},						//STM32duino Pin  6 = RP6/PB6/CHIP PIN15
	{GPIOA, 1<<7},						//STM32duino Pin  7 = RP7/PB7/CHIP PIN16
	{GPIOA, 1<<8},						//STM32duino Pin  8 = RP8/PB8/CHIP PIN17
	{GPIOA, 1<<9},						//STM32duino Pin  9 = RP9/PB9/CHIP PIN18
	{GPIOA, 1<<10},						//STM32duino Pin 10 = RP10/PB10/CHIP PIN21
	{GPIOA, 1<<11},						//STM32duino Pin 11 = RP11/PB11/CHIP PIN22
	{GPIOA, 1<<12},						//STM32duino Pin 12 = RP12/PB12/CHIP PIN23
	{GPIOA, 1<<13},						//STM32duino Pin 13 = RP13/PB13/CHIP PIN24
	{GPIOA, 1<<14},						//STM32duino Pin 14 = RP14/PB14/CHIP PIN25
	{GPIOA, 1<<15},						//STM32duino Pin 15 = RP15/PB15/CHIP PIN26
#endif
...

This table defines all pins on available GPIO -> thus the test for the existence of a GPIOx port.

It relies on a pre-defined type: PIN2GPIO

6. PIN2GPIO is defined as such:

Code: Select all

//map pin number to GPIOx
typedef struct {
	GPIO_TypeDef *gpio;					//gpio for a pin
	uint16_t mask;						//pin mask - 16-bit port
} PIN2GPIO;
	

and each of the pins is defined as an enum (typedef'd as well)

So when you tie all this together, you can essentially change where U2TXPIN() is mapped, at compile time (or run time, if you prefer).

code once, use multiple times.

[dannyf]

I got an old STM32F100 chip.

HSI @ 8.053Mhz, vs. 8Mhz spec. Trimed to 8.005Mhz.
LSI @ 39,921Hz, vs. 40Khz.

Not bad but not great either.

[ag123]

i've been sticking mostly with the 'pill boards' as that has been what is 'easily' available.
i'd probably need to learn to solder my own socs, hence starting with g030f6 tssop20 which seemed 'quite manageable'
after getting the hang of this, maybe i'd try the bigger socs e.g. tssop48 etc (i.e. the stm32f103c8 package and many more), there are also QFN packages where the leads don't protrude (e.g. stm32f401ccu)