pico, srand() rand.c

[momefilo]

Hallo, im new on Hardwareprogramming and i have a problem with the srand funcion on a raspberrypi pico.
When i debug with gdb this error comes: "srand (seed=18) at ../../../../../../../newlib/libc/stdlib/rand.c:67", "/newlib/libc/stdlib/rand.c: Datei oder Verzeichnis nicht gefunden", on my line : srand(++salz);
in this code

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "pico/stdlib.h"
#include "hardware/spi.h"
#include "hardware/gpio.h"
#include "hardware/flash.h"
uint16_t salz=3;
void game_end(){
       srand(++_salz);  // rand.c is allways missing
      int r = rand();
	_figure = _figures[(r*3/11)%FIGURE_COUNT];
      ...
}

The programm do not run after this error. But when i change to "_figure = _figures[(r/10)%FIGURE_COUNT]" the programm runs normal with pseudo random generated numbers after the same error in "srand(++salz)" whit gdb-multiarch debugging.
it confused me, runs with "_figure = _figures[(r/10)%FIGURE_COUNT];" but not with " _figure = _figures[(r*3/11)%FIGURE_COUNT];"

Is the missing rand.c a problem of the pico-sdk or of the developing maschine-OS?

the developing maschine is:
Raspberry Pi 3 Model B Rev 1.2
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"

Please excuse my bad english, and thanks for awnsers

[dsyleixa123]

srand() is meant to be used just once at the start of the program for the very first arbitrary initializing of rand() in order to seed the PRNG with varying start values from runtime to runtime - and NOT FOR REPETITIVE calls before either single rand() call, e.g.,
srand( 18 ); // not an assignment/equation! Passing constants will generate identical rand series then
alternatively:
srand( analogRead(A0) ); // open analog A0 pin
or sth like
srand ( time(NULL) );

rand() then always generates a new random number one after another and ALWAYS returns an int number in the range between 0 and RAND_MAX (>= 32767)
(so just to say, I actually doubt that r/10 or r*3/11 would make that better in any way, especially with regard to possible value overflow in the latter....)

In your case perhaps
_figure = _figures[(r*3/11)%FIGURE_COUNT];
also might be an issue then, e.g. by a array size overflow.

So 1st of all, for debugging, after
int r = rand(); // instead I would suggest unsigned int, BTW....
I would advice to print out

r
(r/10)%FIGURE_COUNT
(r*3/11)%FIGURE_COUNT

to check if the array bounds of _figures[] are not exceeded (e.g., when (r*3/11)%FIGURE_COUNT perhaps might have become negative).

[momefilo]

..
alternatively:
srand( analogRead(A0) ); // open analog A0 pin
or sth like
srand ( time(NULL) );
..
I would advice to print out

r
(r/10)%FIGURE_COUNT
(r*3/11)%FIGURE_COUNT

to check if the array bounds of _figures[] are not exceeded (e.g., when (r*3/11)%FIGURE_COUNT perhaps might have become negative).

Thanks for Anwser and the good Idea to take the analog IN for generate random Numbers.
I have look'd for the Results of "(r*3/11)%FIGURE_COUNT" and "(r/10)%FIGURE_COUNT". the results of "r*3/11%FIGURE_COUNT" was allways greater then FIGURE_COUNT and r/10 allways smaller. I think now too that this problem comes form "overflows in uint16_t", but the Hardware is now not available for me and and the reproductions of the problem with _fIgures area and call "srand(++salz)" and the %-operation in a loop do not produces outputs greater then the %FIGURE_COUNT on an "unconnectet" pico.

The missing rand.c debug-message comes only when i step in the rand() function all so in the reproducion-programm too. When i step over in gdb the function shows no problems.

thanks dsyleixa123 for Awnser and a lot for the good idea whit the analog IN
p.s. The (r/10)%FIGURES_COUNT runs perfect as tetris in the Hands of neighbors young son

[dsyleixa123]

hi momefilo,
glad to read that (r/10)%FIGURES_COUNT runs for you!
As stated, I think that simply
unsigned int r = rand();
_figure = _figures[ r % FIGURE_COUNT ];
will work perfectly too, and presumably the PRNs will even be better evenly-distributed!

[momefilo]

Die Idee mit dem analog IN als seed für srand() ist gut. Bei dem Tetris hab ich letzen Endes das seed in gameOver inkrementiert und im flash gespeichert, sonst hätte sich die Folge der Blöcke wiederholt. Das Schreiben des flash in einer Schleife soll nicht gut sein hab ich irgendwo gelesen. Aber mir fällt nix besseres ein

[davidcoton]

Die Idee mit dem analog IN als seed für srand() ist gut. Bei dem Tetris hab ich letzen Endes das seed in gameOver inkrementiert und im flash gespeichert, sonst hätte sich die Folge der Blöcke wiederholt. Das Schreiben des flash in einer Schleife soll nicht gut sein hab ich irgendwo gelesen. Aber mir fällt nix besseres ein

For the non-German speakers amongst us, Google Translate says

The idea of using the analog IN as a seed for srand() is a good one. For the Tetris I incremented the seed in gameOver and saved it in flash, otherwise the sequence of blocks would have been repeated. Writing the flash in a loop is not supposed to be good I read somewhere. But I can't think of anything better

[kilograham]

Note the upcoming SDK 1.5.0 release has a new pico_rand library which is intended to provide a better random number generation, and uses various entropy sources both for seeding, and per generation.