Erasing 32k eeprom with loading bar, cpu load high

[smitchel]

here's the working code

void fc_i2c_erase_all2()
{ int i, j; int progression = 0;
       short int addrH, addrL;
       char affiche[10], affiche2[10], affiche3[10], affiche4[10];
       for (i = 1; i <= 16; i++)		      //
       { for (j = 0; j < 2048; j++)                   //
        { addrH = progression / 256;                  //
          addrL = progression % 256;                  //
          ShortToHex(addrH, affiche);
          Lcd_Out(1,1,affiche);      	              // hex address hi
          ShortToHex(addrL, affiche2);
          Lcd_Out(1,3,affiche2);                      // hex address lo
          IntToStr(progression, affiche3);
          Lcd_Out(1,5,affiche3);                      // decimal address
          IntToStr(progression/327,affiche4);         // percentage
          Lcd_Out(1,10,affiche4);
          fc_i2c_write(addrH, addrL, 0x00);	      //
          progression++;			      //
        }					      //
        Lcd_Chr(2, i, 0xFF);		              // bargraph char
       }
       Delay_ms(222222500); 					    //
}

 

[Mike - K8LH]

The "/" and "%" operations may be using a lot of cycles in your compiler. I wonder if this would be any better?

BTW, what compiler are you using?

void fc_i2c_erase_all2()
{ int i, j; int progression = 0;
  short int addrH = 0; short int addrL = 0;
  char affiche[10], affiche2[10], affiche3[10], affiche4[10];
  for (i = 1; i <= 16; i++)		      //
  { for (j = 0; j < 2048; j++)                   //
   { ShortToHex(addrH, affiche);
     Lcd_Out(1,1,affiche);      	              // hex address hi
     ShortToHex(addrL, affiche2);
     Lcd_Out(1,3,affiche2);                      // hex address lo
     IntToStr(progression, affiche3);
     Lcd_Out(1,5,affiche3);                      // decimal address
     IntToStr(progression/327,affiche4);         // percentage
     Lcd_Out(1,10,affiche4);
     fc_i2c_write(addrH, addrL, 0x00);	      //
     progression++;			      //
     if(addrL == 255) addrH++;           //
     addrl++;                              //
   }					      //
   Lcd_Chr(2, i, 0xFF);		              // bargraph char
  }
  Delay_ms(222222500); 					    //
}

 

[smitchel]

This one doesn't work, the low address loops from 00 to FF without the high address incrementing. I use mikroC compiler.

 

[smitchel]

I found a solution to what you gave me, I changed the initial value of addrH so it starts with 0 when check agains't the if condition change to 0 instead of 255 and it works this time, I have all my addresses erased. As for the time, it takes about the same time, around 8.20 minutes. Maybe I'll stick with your version of the code with / and % it seems cleaner.

Here's the working code with the changes I made.

void fc_i2c_erase_all3()
{ int i, j; int progression = 0;
 [B] short int addrH = 0xFF[/B]; short int addrL = 0;
  char affiche[10], affiche2[10], affiche3[10], affiche4[10];
  for (i = 1; i <= 16; i++)		      //
  { for (j = 0; j < 2048; j++)                   //
   { ShortToHex(addrH, affiche);
     Lcd_Out(1,1,affiche);      	              // hex address hi
     ShortToHex(addrL, affiche2);
     Lcd_Out(1,3,affiche2);                      // hex address lo
     IntToStr(progression, affiche3);
     Lcd_Out(1,5,affiche3);                      // decimal address
     IntToStr(progression/327,affiche4);         // percentage
     Lcd_Out(1,10,affiche4);
     fc_i2c_write(addrH, addrL, 0x00);	      //
     progression++;			      //
   [B]  if(addrL == 0) addrH++; [/B]          //
     addrL++;                              //
   }					      //
   Lcd_Chr(2, i, 0xFF);		              // bargraph char
  }
  Delay_ms(222222500); 					    //
}

 

[Mike - K8LH]

This one doesn't work, the low address loops from 00 to FF without the high address incrementing. I use mikroC compiler.

I guess I'm not following you here. The code using "== 255" does increment the hi byte correctly when the lo byte goes from 0xFF to 0x00 (overflow). So hex addresses would be displayed as 0000, 0001, 0002,... 00FE, 00FF, 0100, 0101...

 

[Mike - K8LH]

Another question for you, please? You say it takes 8+ minutes to cycle through all 32768 addresses. Is this in your ISIS simulation or on real hardware? If in ISIS, is that simulated processing time for the PIC target?

As for an 80 line bargraph, I've attached a pseudo code example (you'd be responsible for making changes needed for your compiler). I assume you know how to create five custom characters and how to load them into LCD CGRAM, or that you can figure it out.

Dividing 2048 (bytes) by 5 (vertical lines) you get 409.6 but since we want to avoid floating point you can use j*10 divided by 4096 and you'll end up with an index for custom characters 0..4 with vertical bars at these intervals;

custom char 0 ->    0.. 409  (1 bar)
custom char 1 ->  410.. 819  (2 bars)
custom char 2 ->  820..1228  (3 bars)
custom char 3 -> 1229..1638  (4 bars)
custom char 4 -> 1639..2047  (5 bars)

     char addrl = 0;                    //
     char addrh = 0;                    //
     char graph;                        //
     for(char i = 0; i < 16; i++)       //
     { for(int j = 0; j < 2048; j++)    //
       { graph = j*10/4096;             // 0..4
         lcd_chr(2,i+1,graph);          // |, ||, |||, ||||, or |||||
         if(addrl++ == 255) addrh++;    //
       }                                //
     }                                  //

You don't really need to print the same bar graph character over and over again and with 50 usecs or so of overhead for each LCD write, it might be worth the cost of a couple microseconds to add a few instructions that allow you to avoid the unnecessary LCD writes.

Regards, Mike

 

[smitchel]

So, for the loops, the problem was that, for some reason the if condition did work when checked against addrL== 255, I don't know why it does that, but it does, so since the if condition was never true, addrH never incremented. Checking it against addrL== 0 did work, but because of the condition, the addrH was changed to one the first time, leaving a range of address untouched. Which is why gave it an initial value of 0xFF so after the first loop it gets the 0xFF value.

For the 8 minutes, it's all in ISIS, I use a pic 16f877 and 20Mhz clock.Though my project is intented to work on real hardware I didn't try it yet, but I know that there might be some differences with the simulation, and hopefully the times will be better.

Thank you for the 80 line bargraph, I know how to make custom characters and I'll try to make it work on my compiler.

I have to thank you for the tremendous help you gave me, the time and effort you put into solving my problem and I'm very grateful for it.
Thank you very much.

 

[Mr RB]

I think a 'few seconds' was perhaps a bit of an exaggeration?.

But if a page write of 64 bytes takes 5mS, then it's only 512x5mS to write it all.

The last one I did was using 24LC512 which allows page writes of 128 bytes, so is twice as quick, but then it is twice the total storage size.

The datasheet defines 5mS as "maximum" and in reality it is more like 2-3mS.

Full-chip erase code should be constructed like this;

loop
send an entire page of 64 erased bytes (then write starts)
every 2kb written (every 32 pages) display one more block on LCD (happens during write, no time cost)
if 512 pages not finished yet, inc address 64 bytes and goto loop

The LCD is handled during the 2mS write time and from memory the EEPROM even accepts the next page data while write is occuring so total time is something like 512 * 2mS or 1 second, so the OP might should find it easy enough to de the total chip erase in "a few seconds".

 

[Mike - K8LH]

Thanks... That sounds like a very reasonable and intuitive explanation and procedure.

 

[ghostman11]

the loading on the cpu is proteus!!! if you have a real license drop them a email and they give you the optimization settings for the simulator ive had to have them do this a few time for me. trust me rarely does proteus bare any resemblance to real life running! also it dosnt matter if you have a quad core or i7 or whatever as proteus cant use multi threading or multi cores, and if your using say ver 7.8 or below then.........time to buy a license