Duração Horas Eeprom Atmega328

[vtrx]

Li bastante sobre a duração da Eeprom interna do Atmega,o datasheet dizendo que seria e média 100.000 Gravações/Apagamento,mas qual a duração média somente leitura?

[F4b10]

@vtrx Memoria flash só se degrada na escrita, leituras são praticamente ilimitadas.

[aphawk]

@vtrx ,

 

A limitação é de escrita. Leitura não tem esse problema.

Mas olha, mesmo essa limitação de escrita pode ser totalmente insignificante, existe uma técnica que usa o dobro de bytes para aumentar por no mínimo 256 vezes essa limitação, e o quádruplo de bytes para aumentar 64k vezes a limitação de escrita , e assim sucessivamente ….

 

Só não existe jeito para a nossa Política ….

 

Paulo

[vtrx]

Bom isso.

Sei de uma técnica que é ler e verificar se o byte é diferente antes de gravar,outra eu não sei.

Pena que resolvi trabalhar com AVR tarde...é uma arquitetura muito eficaz,só não consegui substituto,em termos de tamanho e porta,para o 18F4550,o próximo seria o ATmega32U4,mas tem 25 IO e o 18F4550 30.

[.if]

3 horas atrás, aphawk disse:

existe uma técnica

A que uso é 100% criação própria... p.i. que compartilho: consiste em algo como gravar apenas onde tem 0xff e ler onde não tem. Ao findar o bloco preestabelecido, apaga tudo e recomeça. Técnica especialmente interessante pra família st32xxx que fdpmente não tem eeprom interna. Tem que gravar na área de programa mesmo. No [meu] caso há gravação apenas no momento desliga quando um comparador sente a queda e um capacitor eletrolítico mantém a energia tempo mais que suficiente para a gravação.

 

3 horas atrás, aphawk disse:

jeito para a nossa Política ….

Só Jesus na causa...

[aphawk]

2 horas atrás, vtrx disse:

 

Pena que resolvi trabalhar com AVR tarde...é uma arquitetura muito eficaz,só não consegui substituto,em termos de tamanho e porta,para o 18F4550,o próximo seria o ATmega32U4,mas tem 25 IO e o 18F4550 30.

Tem o Atmega644 e o Atmega1284 para esses casos.

 

Na Europa está ficando popular o AVR128DB48 e o AVR128DB64, compatíveis em código com os AVRs antigos, tem I/O de sobra, roda a 24 MHz. Tem gerador de forma de onda, e muitos recursos novos que eu ainda estou tentando entender ( incorporaram muitos recursos dos Pics novos ), tem até 3 Amp Ops dentro que podem ser interligados via programação, e o custo é baixo.

 

O Bascom que eu uso começou a suportar essa família, tem um membro que acho muito interessante que é o AVR128DB28, que tem 28 pinos e existe em DIP, com 128K de flash e 8K de RAM, I/O multivoltagem programável, enfim muita coisa para brincar …

 

Paulo

[vtrx]

59 minutos atrás, aphawk disse:

Tem o Atmega644 e o Atmega1284 para esses casos

Faltou o suporte USB!

[aphawk]

3 horas atrás, vtrx disse:

Faltou o suporte USB!

Para usos normais , em baixa velocidade , você pode usar o famoso V-USB , roda muito bem, já usei num Atmega328 e foi tranquilo.

 

https://www.obdev.at/products/vusb/index.html

 

Claro que vai te obrigar a usar um cristal acima de 12 MHz…. mas é uma solução barata !

 

Paulo

[.if]

Já falei mas vou falar de novo... Melhor queimar a etapa do usb. Vou direto  da serial pro wireless (bluetooth) sem passar pelo usb pra fazer um mc conversar com o pc. Velocidade? "ando devagar porque já tive pressa..." tocando em frente Almir Sater

[aphawk]

@.if ,

 

Concordo com você mais uma vez ….

 

Hoje em dia vejo a comunicação com o celular ser muito mais importante do que a com um PC …. E tem algumas coisas bem legais :

 

https://www.gui-o.com/

 

Esse cara fez essa interface, funciona perfeito nos celulares Android, roda também nos ESP,  escreveu um módulo para usar também no Bascom, já ví 6 exemplos de uso bem legais, pena que meu celular é um IPhone … mas acho que mostra o futuro de nossos projetos .

 

Paulo

[vtrx]

No meu caso iria substituir o microcontrolador de uma interface que faço a anos por um AVR,mas a interface utiliza comunicação USB fullSpeed e as 30 IO,e neste caso o PIC ainda sai mais em conta.

Aproveitando o assunto,alguém sabe me dizer o que acontece se eu tiver vários módulos Bluetooth (HC) conectado a varias interfaces iguais com a mesma senha e ID e eu conectar uma delas é possível ou todas vão responder?

[Sérgio Lembo]

22 horas atrás, aphawk disse:

existe uma técnica que usa o dobro de bytes para aumentar por no mínimo 256 vezes essa limitação, e o quádruplo de bytes para aumentar 64k vezes a limitação de escrita , e assim sucessivamente ….

Estou interessado nisso. Por favor, descreva.

[.if]

Em 28/12/2021 às 01:27, Sérgio Lembo disse:

interessado nisso. Por favor, descreva.

... também não associei o rosto à pessoa. O máximo que minha teoria se aproxima é algo como um byte é o dado propriamente dito e outro é algo como um contador ou indexador pra ele... neste caso ele deve ser gravado em posições crescentes da memória semelhante à minha (minha mesmo... bem agora não é mais) técnica...

Em 27/12/2021 às 17:01, vtrx disse:

as 30 IO,e neste caso o PIC ainda sai mais em conta.

Um avr ou st + 4 74hc595 (clique) não seriam bons candidatos off topic?

Ah.. IO .. precisa do I e do O. Há técnica off topic que torna o hc595 como I. Só vale a pena descrever caso alguém tenha interesse...

 

 Usando meus superpoderes de edição kk..

9 horas atrás, aphawk disse:

dúvida se esse truque do programa funciona caso o valor a ser gravado seja FF

De fato o caso do dado 0xff como útil é uma questão perturbadora. Preferi não debruçar sobre ela e facilitei minha vida considerando 0xff como área vaga. No meu caso não preciso do 0xff.

Aliás sua técnica não tem quase nada de diferente da minha que é essencialmente uma gravação em anel.

O resumo pra eternizar a gravação na eeprom:

Gravar...

-no maior intervalo possível &

-apenas se for diferente do anterior &

-apenas quando desliga &

-em anel

 

22 horas atrás, vtrx disse:

continuaria em não substituir o PIC por um AVR 'diretamente'.

Achei que era projeto novo. De fato é bem raríssima a possibilidade de substituição 1:1 no hw a não ser nos não raros casos de falsificações o que incorre em risco real de incompatibilidade do sw (exp. própria)

 

 

9 horas atrás, aphawk disse:

não sou mais membro VIP não consigo editar um post depois de algumas horas

Ah.. se for uma coisa muito cabeluda basta pedir pro moderador geralmente o Brunão @BCP e penso que ele terá o maior prazer em corrigir/editar pra você. .. ou melhor, pra nós . Clique no 'denunciar' e explique o motivo... faço isso com frequencia com meus (meus) posts kk

[vtrx]

2 horas atrás, .if disse:

... também não associei o rosto à pessoa. O máximo que minha teoria se aproxima é algo como um byte é o dado propriamente dito e outro é algo como um contador ou indexador pra ele... neste caso ele deve ser gravado em posições crescentes da memória semelhante à minha (minha mesmo... bem agora não é mais) técnica...

Um avr ou st + 4 74hc595 (clique) não seriam bons candidatos off topic?

Ah.. IO .. precisa do I e do O. Há técnica off topic que torna o hc595 como I. Só vale a pena descrever caso alguém tenha interesse...

O problema de usar um ST é o tamanho dos Pads,a pcb é montada manualmente para economizar,ja pensei em usar o 74HC,mas continuaria em não substituir o PIC por um AVR 'diretamente'.

[aphawk]

20 horas atrás, Sérgio Lembo disse:

Estou interessado nisso. Por favor, descreva.

 

Eu tomei conhecimento no site do Bascom, como o código é em Basic vou postar aqui o conteúdo do post.

"AVR eeprom cell can be safe cleared 100k times. So you must consider mem some of the important values in the time.
Life of the eeprom can be extended if you use more cells of the eeprom.
It is simple if you use two cells then cycles for write is double, when you can use four cells then it can be written four times more than one cell.....NO..simply you can write one cell 100k times only but when they used together and one by one ->back to first then you have 100k times x cells you declare to be used.

I attach code that shows how 100k times can be extended to 1M times of Eeprom writing/reading. This 1M is because factor of 10. You can change that."

 

Segue o código :

 

$regfile = "xm128a3udef.dat"                                'FLASH-128KB,SRAM-8KB,EEP-2KB,7xTIMER,4xDMA,7xUSART,3xSPI,2xTWI,USB
$crystal = 32000000                                         '32MHz
$hwstack = 128                                              'FLASH 10K TIMES
$swstack = 128                                              'EEPROM 100K TIMES
$framesize = 512

Config Submode = New

Const My100k_times = 10
Dim Mem_cell(my100k_times) As Eram Word




Function Read_mem() As Word
 Local Fn As Word , Helpw As Word

 Helpw = &HFFFF

  For Fn = 1 To My100k_times
   If Mem_cell(fn) <> &HFFFF Then                           'one by one check if you find FFFF
    Helpw = Mem_cell(fn)                                    'remember values that differ from FFFF
   Else                                                     'if FFFF is found then previous is our value
    Read_mem = Helpw
     Exit Function
   End If
  Next

End Function

Sub Clear_ee_buff()
'this sub will do eeprom carry, format eeprom for next use
 Local Fn As Word

   Fn = My100k_times
   Do
    Mem_cell(fn) = &HFFFF
     Decr Fn
   Loop Until Fn = 0
End Sub

Sub Remember(byref Mem_it As Word)
  Local Fn As Word

 Fn = 1
 While Fn < My100k_times

  If Mem_cell(fn) = &HFFFF Then                             'found FFFF, write memory
   Mem_cell(fn) = Mem_it
    Exit Sub
  End If

  Incr Fn
 Wend                                                       'do this till FFFF found

 Call Clear_ee_buff()                                       'we dont Exit so memory must be full
  Mem_cell(1) = Mem_it

End Sub

'--------[ END SUB`s ]----------


'--[ DEMO STARTS NOW ]----------

Dim N As Byte , My_word As Word


'this routine shows that last value can be saved and readed back

For N = 1 To 150

 Call Remember(n)
  My_word = Read_mem()
  'print it if you like

Next
 

Agora que li com mais atenção, a expansão de gravações aumenta linearmente conforme aumenta o numero de bytes alocados. O programa criou um vetor de 10 posições na memória EEprom, e vai usando uma de cada vez, passando sozinho para a próxima.... e por aí em diante, até usar a ultima e volta para a primeira. Como no caso o tamanho alocado foi de 10 vezes ( daí o tamanho do vetor ), pode-se gravar 1.000.000 de vezes com segurança.

 

Eu me equivoquei no post anterior sobre como funcionava esse truque .... e o interessante é que como não sou mais membro VIP não consigo editar um post depois de algumas horas ..... parece que a administração não se preocupa mais com possíveis erros escritos, assim os erros irão se perpetuar.

 

Peço desculpas caso alguém leia o post anterior e tente fazer alguma coisa semelhante ao que eu descreví nele kkkk !

 

Só estou em dúvida se esse truque do programa funciona caso o valor a ser gravado seja FFFF ...... para qualquer outro valor sei que funciona. O autor é um dos caras que mais contribui com projetos interessantes e conhece bem a fundo o Bascom, acredito que ele não deixaria passar esse possível erro.

 

Ainda não precisei usar essa técnica, mas é bom sempre ter esse truque na manga ....

 

Paulo

 

 

[Sérgio Lembo]

Se a memória apagada = FF ou um par = FFFF, o ato de apagá-la faz dela um ponteiro numa estrutura circular e também um valor proibido. Faz algum tempo estive olhando para algumas memórias eprom de alta ciclagem com poucos bytes, até 258. Encontrei da ST com 4.2mega ciclos e as de ferro, um pouco mais caras, com quantidade quase infinita de ciclos, dez elevado a um número estúpido. Na de ferro, se o valor fosse alterado 3 x por segundo, esta ainda aguentaria 100 anos.