[LHC] [GaroaHC] Re: Malloc no Arduino, é uma idéia ruim ?

[Alejandro Mesias]

Devo trocar tudo por vetores. Estou desenvolvendo um produto que tem
teclado + LCD + MicroSD.

Os dados que leio estão no MicroSD, processo os dados e gero um Menu. Esse
menu é todo alocado com Malloc, é basicamente uma lista de array de char.
Vou ver de substituir por uma lista bidimensional, o tamanho dos intens vai
ser igual mas, acredito que fique mais fácil de manter a lista e limpar da
memória. A lista não vai ter um tamanho fixo, apenas largura fixa.

Vai dar um belo trabalho, mas como tenho alguns comportamentos estranhos no
código, espero reduzir.

Ps: Comportamento estranho: se eu não imprimo uma variável ela some,
variável que não tem nada a ver com essa lista que falei.

Em 15 de fevereiro de 2016 11:48, DQ <dqsoft.blogspot at gmail.com> escreveu:

> Uma outra estratégia comum (apesar de perigosa) é o famoso byte aux[100]
> - uma buffer auxiliar que é usado como área temporária em vários lugares.
> Tomando o cuidado para que duas rotinas não usem esta área auxiliar ao
> mesmo tempo e que ela tenha tamanho suficiente para a maior necessidade,
> isto pode substituir a declaração de vários buffer de uso específico que
> ocupariam mais memória.
>
> (Obs: tenho a impressão que esta discussão já rolou antes por aqui).
>
> DQ
>
>
> On Monday, February 15, 2016 at 11:44:53 AM UTC-2, DQ wrote:
>>
>> Recomendo uma leitura da documentação da biblioteca C do avr-gcc:
>> http://www.nongnu.org/avr-libc/
>>
>> Basicamente malloc utiliza a estratégia "best-fit" para alocar blocos
>> dentro da área entre as varáveis estáticas e a pilha. O problema de
>> fragmentação surge quando alocações e liberações ocorrem de forma
>> desordenada. Quando um bloco é liberado o free tenta juntar com os blocos
>> livres adjacentes mas o máximo que pode ser alocado é o maior bloco livre.
>>
>> Por exemplo, vamos supor que você tenha 4K e aloque três blocos (nesta
>> ordem): A (1K), B(2K) e C(1K). Se você liberar A e C, você fica com dois
>> blocos livres de 1K; apesar da memória livre total ser 2K o máximo que você
>> consegue alocar é 1K.
>>
>> Se você alocar alguns blocos no início e nunca liberá-los, não há
>> fragmentação. Se você alocar vários blocos e depois liberá-los, sem nenhuma
>> outra alocação no meio, também não tem problema. Por exemplo, vamos supor
>> que  sua rotina de menu aloca vários blocos, espere o operador fazer uma
>> seleção, libere os blocos e depois execute o que foi selecionado. Não vai
>> ter problema.
>>
>> DQ
>>
>> On Monday, February 15, 2016 at 8:59:13 AM UTC-2, Mesias wrote:
>>>
>>> Estava lendo alguns posts e discussões sobre fazer malloc no Arduino (ou
>>> em sistemas embarcados).
>>>
>>> Parece que ele vai bagunçado a memória com o tempo, por não reutilizar
>>> bem as memórias que ele liberou.
>>>
>>> O processo que tenho é simples, leio alguns dados, reservo a memória
>>> para mostrar um menu e depois limpo ela antes de executar funções, sempre
>>> limpo em seguida. Mas estou na duvida se deveria partir para alocação
>>> estática.
>>>
>>> --
>>> ======================================
>>> Alejandro Mesias André Nebra Perez
>>> Java/Python/Js/Something else Developer
>>> Twitter: @meszias
>>> Linux User #442506
>>> Campinas - SP - Brasil - South America
>>> ======================================
>>>
>> --
> -... . . -..- -.-. . .-.. .-.. . -. - - --- . .- -.-. .... --- - .... . .-.
> Regras da Lista: https://garoa.net.br/wiki/Lista:LeiaAntesDeClicarNoSend
> Para mais informações sobre o Garoa Hacker Clube acesse
> https://garoa.net.br
> Maiores opções sobre o Google Groups, visite:
> https://groups.google.com/group/hackerspacesp
> .--. .- .-. .- -- .- .. ... .. -. ..-. --- .-. -- .- . ... .- -.-. . ...
> ... . --- .-- .. -.- ..
> Epoch 0 <=> Fundação: 1298244863 s ~ 2.408064*10^52 tP (tempos de Planck)
>



-- 
======================================
Alejandro Mesias André Nebra Perez
Java/Python/Js/Something else Developer
Twitter: @meszias
Linux User #442506
Campinas - SP - Brasil - South America
======================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.tia.mat.br/pipermail/hsc-tia.mat.br/attachments/20160215/1e2c6080/attachment.html>