heinbali01 wrote on Thursday, October 17, 2019:
Hello Galen, thanks for this detailed feedback. I have reserved time to have a look at it and change the driver where useful.
I have several patches for you that I think will improve the code.
Most of them are stm32-related, but one or two fix warnings in the TCP code.
Is it okay to create a new bug and attach all of them there? Here is a
brief list of the changes you may be interested in.
You can just attach them in this post, so we keep it al together.
FYI, my code is still HAL free. I created my own version of the
following functions in order to get it working.
Actually, it would be nicer to use
Which is a HAL call-back function, and should be provided by the application developer ( often found in
Regarding the HAL delay functions, I noticed that HAL delay is being used to
workaround the “Successive write operations to the same register might not be
fully taken into account” errata.
You totally right about this. I left it because ( as far as I know ) the delay is only needed during initialisation.
In other drivers, usually, a peripheral register is set and than read back.
Regarding the ipconfigRAND32 function, I am using rand() from newlib for
this, but I don’t see a good place to call srand() to set the seed.
It is indeed very important to call
srand() with a random value. And if you ST part has a RNG module, that would even be better.
I used the following code in my ST-projects:
void HAL_RNG_MspInit(RNG_HandleTypeDef *hrng)
/* Enable RNG clock source */
RCC->AHB2ENR |= RCC_AHB2ENR_RNGEN;
/* RNG Peripheral enable */
RNG->CR |= RNG_CR_RNGEN;
uint32_t ulRandom32( )
xResult = HAL_RNG_GenerateRandomNumber( &hrng, &ulReturn );
if( xResult != HAL_OK )
ulReturn = 0uL;