Pico SDK, raspberry pi pico 2040, and semantic of the "Break"

 Belong to C++ standard of 1999, and at least since here we can define to following fact:

1. Use break everywhere is suspect full near an avoidance in a clear definition of what is executed and what's not .
2. Uses of Goto is greatly discouraged since you can either achieve a coding paradox using recurrent call of a function, implicating Goto , simply make the logic analyzer inside the compiler to not clearly define where it should go. We have evolve over but with my latest Hazard-3 RISCV compiler for rp2350 does not stand more than half hour running the ssd1306_i2c example it's abnormal. 

Screen Pico SDK for producing example on my new RP2350 WaveShare board, to froze at the first try of an ssd1306 looping a message, to show white raspberry moving to the right and erasing through a center line diagonal to be draw over the text in a clockwise way. Even over the evening I get doubt about the Pico SDK itself to not support the replacement of the break/goto code inserted inside ssd1306_i2c found in general Pico-Sdk example, or included in VScode. It went normal on the morning, I mean it finally understand or do some cmake stuff appealing to recognize I was doing something normal with something existing... It's weird, but that evening I was unable to let the code repeat and to loop the ssd1306_i2c description of the ssd1306 pixel draw on it. 

Over the morning when it went normal:

- realize the substitution of the break into the function Drawline ( static void DrawLine ), do have to remove the break and substitute it with a boolean approach.  

Up to my eyes it give advantage.

- inside the while statement is formed from boolean static and upon a conditional reality it uses the break to leave and the while and quit the function.

see in initial code sample:

static void DrawLine(uint8_t *buf, int x0, int y0, int x1, int y1, bool on) 
{
  int dx =  abs(x1-x0);
  int sx = x0 &lt x1 ? 1 : -1;
  int dy = -abs(y1-y0);
  int sy = y0 &lt y1 ? 1 : -1;
  int err = dx+dy;
  int e2;

  while (true) 
  {
    SetPixel(buf, x0, y0, on);
    if (x0 == x1 && y0 == y1)
        break;
    e2 = 2*err;

    if (e2 >= dy) 
    {
      err += dy;
      x0 += sx;
    }
    if (e2 <= dx) 
    {
      err += dx;
      y0 += sy;
    }
  }
}

 Over this alternative: 

static void DrawLine(uint8_t *buf, int x0, int y0, int x1, int y1, bool on)
{
  int dx =  abs(x1-x0);
  int sx = x0 &lt ltx1 ? 1 : -1;
  int dy = -abs(y1-y0);
  int sy = y0 &lt y1 ? 1 : -1;
  int err = dx+dy;
  int e2;
  bool bContinueLoop=true;

  while ( bContinueLoop ) 
  {

    SetPixel(buf, x0, y0, on);
    
    if (x0 == x1 && y0 == y1)
    {
      bContinueLoop=false;
    }
    
    if ( bContinueLoop )
    {
      e2 = 2*err;

      if (e2 >= dy) 
      {
        err += dy;
        x0 += sx;
      }
      if (e2 <= dx) 
      {
        err += dx;
        y0 += sy;
      }
    }
  }
}

And up to compiler view once it's compiled for rp2040 here some strange in the story:

maxiste@XeonSrv2650:~/github/rp2040/i2c$ wc -c ssd1306_i2c_v1/build/ssd1306_i2c.uf2 ssd1306_i2c/build/ssd1306_i2c.uf2 
31232 ssd1306_i2c_v1/build/ssd1306_i2c.uf2
31232 ssd1306_i2c/build/ssd1306_i2c.uf2
62464 total
maxiste@XeonSrv2650:~/github/rp2040/i2c$ sha1sum ssd1306_i2c_v1/build/ssd1306_i2c.uf2 ssd1306_i2c/build/ssd1306_i2c.uf2 
1a8d36a0aa2d224b398c8bf7a46e8ed54fb3f251  ssd1306_i2c_v1/build/ssd1306_i2c.uf2
51a6936ec71217b9645cb1026ae8388ff650b30d  ssd1306_i2c/build/ssd1306_i2c.uf2
maxiste@XeonSrv2650:~/github/rp2040/i2c$  

 Belong to sha1sum they are different but belong to size it give the same answer turning a break from a while with coding the boolean inside the while having a variable in boolean type assigned to "True", to loop over and over, and then upon  "x0 == x1 && y0 == y1" the boolean variable is set to false. Thus require to brace the rest of the operation with usually braked with a if This is True to allow the code to be executed. But this little change to skip in problem to directly brake out does not cost in byte at the compilation time.

So it's the comment of the day. Because having to reduce the goto restart into a similar before :restart we can get a sort of setup() like function like Arduino code owning a setup which is unique and a main which naturally loop. But actually solution over rp2350 compiled for pico2 with RISVC compiler allowing encrypted boot and couple of strange solution to be performed by pico2, does froze after 30 minutes of run while actually pico-w rp2040 does run it for day either the break/goto version and the version without break. 

 As some say there is ultimately one kind of break which is right to use. Related to switch semantic using break to stop a sequence from inside a switch. Yes it's not forbidden to pass to a switch choice and fall into the other bottom switch label if you did not supply any break between them. As some suggest the break work semantic inside a switch is different of the concurrent break inside a while or for, I am getting rid of them.

Other suspect full things inside the code.  

restart:

  area.start_col = 0;
  area.end_col = IMG_WIDTH - 1;

  calc_render_area_buflen(&area);

  uint8_t offset = 5 + IMG_WIDTH; // 5px padding

  for (int i = 0; i < 3; i++) 
  {
    render(raspberry26x32, &area);
    area.start_col += offset;
    area.end_col += offset;
  }

  SSD1306_scroll(true);
  sleep_ms(5000);
  SSD1306_scroll(false);

  char *text[] = 
      {
        "A long time ago",
        "  on an OLED ",
        "   display",
        " far far away",
        "Lived a small",
        "red raspberry",
        "by the name of",
        "    PICO"
      }; 

 As this extract from the int( main ) does own a loop initiated with the label ":restart" is more the char *text[] that is re-initialized every turn the goto do the jump to the label and I don't know is every variable are really re-initialized, but this case suggest to move the variable *text out of the loop because it's not yet changed here and still loop. It's not mention either if the rp2350 or rp2040 write down to the ssd1306 the remaining "Lived a small red raspberry by name of PICO", but no one can really see it. It stop at "far far away", so if there is memory related between the pico and the ssd1306. We are not seeing it and might be another bogus write down into memory that require to be handled. Like doing a upper scroll text to see the rest and prevent to write down all the draw pixel into a void region because the lcd is 128x32 height high and deal with 64 pixel in height to allow seeing everything. Or someone being all the 56 coders from Pico did not see the problems or it's all C-RUST things they did not craft out a good way to allow things to work.