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

Alejandro Mesias ale.mesias at gmail.com
Mon Feb 15 08:34:41 PST 2016


@DQ
>
> alocações e liberações ocorrem de forma desordenada


Diria que faço de forma bem ordenada. O que estou preocupado que aquele
código para ver a memória livre do arduino "freeMemory()" ou algo do tipo
pode estar mentindo prá mim se estiver fragmentado.

Em 15 de fevereiro de 2016 14:31, Alejandro Mesias <ale.mesias at gmail.com>
escreveu:

> Beleza. Mas e o "new" que instanciamos objetos. Tem o mesmo problema do
> malloc ?
>
> Em 15 de fevereiro de 2016 12:47, Renato Toi <renato.toi at gmail.com>
> escreveu:
>
>> Alejandro,
>> Vai dar um pouco de trabalho, mas se vc não fizer eu agarantcho que a
>> chance é muito grande de vc se arrepender no futuro.
>> Acho muito provável que exista código pronto para gerir filas do tipo
>> LIFO/FIFO, que parece ser o seu caso.
>> -RT
>>
>> On 15 de fev de 2016, at 12:21, Alejandro Mesias <ale.mesias at gmail.com>
>> wrote:
>>
>> 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
>> ======================================
>> _______________________________________________
>> Lista do LHC <http://lhc.net.br>
>> HSC at listas.tia.mat.br
>> http://listas.tia.mat.br/listinfo.cgi/hsc-tia.mat.br
>>
>>
>>
>> _______________________________________________
>> Lista do LHC <http://lhc.net.br>
>> HSC at listas.tia.mat.br
>> http://listas.tia.mat.br/listinfo.cgi/hsc-tia.mat.br
>>
>>
>
>
> --
> ======================================
> Alejandro Mesias André Nebra Perez
> Java/Python/Js/Something else Developer
> Twitter: @meszias
> Linux User #442506
> Campinas - SP - Brasil - South America
> ======================================
>



-- 
======================================
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/acbb048d/attachment.html>


More information about the HSC mailing list