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

Mon Feb 15 08:31:31 PST 2016

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
======================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.tia.mat.br/pipermail/hsc-tia.mat.br/attachments/20160215/44d248ac/attachment.html>