ASM51

Pessoal, estou lendo um livro sobre RTOS.
No capítulo que estou, está sendo esmiuçada a criação de tarefas e o uso de stack e heap.
Quando crio uma tarefa, automaticamente é setado alguns espaços na memória heap.
Estes espaços setados para cada tarefa se dividem em 2, - 1 para salvar o contexto na saída de execução e outro chamado stack.

Estou muito confuso, já pulei em vários pontos e não consegui elucidar.

No Keil, heap size é a quantidade de memória ram em bytes que quero fornecer para (funções) tipo sprintf, por exemplo.

O stack não tem um uso para bare metal, pois, eu já setei na época zero, 20K, etc., e nunca surtiu nenhum efeito.

Para sistemas operativos, o stack tem qual utilidade?
Consigo precisar qual o tamanho de stack aproximado?

O que pude imaginar pelo enunciado do tópico, é que no RTOS existe uma parte da memória que vai ser utilizado apenas pelos stacks, além de funções ansi c como malloc, sprintf. Esta região de memória vai ser setada no heap.
Se eu setar como exemplo, para um uC com 90K de ram, 50K de heap. Os outros 40K de ram são utilizados da forma que eu quiser, e o sistema operativo nunca vai tocar fora da região que especifiquei.

Como um exemplo pratico e simples.

Defino um heap de 50K partindo do endereço 0 da ram.
Do endereço 50K e 1 até o final, eu poderia usar como um buffer para aplicação, como buffer para display, audio etc.

Estou coerente no modo de pensar ou estou aprendendo ao contrário?

Obrigado a todos!

Como você adverte, a resposta é sobre o que eu entendi do seu post e não do que você talvez quis dizer com

No Keil, heap size é a quantidade de memória ram em bytes que quero fornecer para (funções) tipo sprintf, por exemplo.

O stack não tem um uso para bare metal, pois, eu já setei na época zero, 20K, etc., e nunca surtiu nenhum efeito.

Para sistemas operativos, o stack tem qual utilidade?

pois parece "pegadinha do Fabim"

Dê uma lida no capítulo 2 do livro do FreeRTOS

https://www.freertos.org/wp-content/upl ... _Guide.pdf

a figura 5 na página 30 é bem ilustrativa.

heap -> espaço utilizado para alocação dinâmica. malloc, calloc, sprintf e printf dependendo da lib, algumas não usam alocação dinâmica.

stack -> espaço reservado para variáveis locais e o próprio stack do sistema.

O Freertos é um comedor de memória RAM, tem que tomar cuidado com o que aloca também na hora que reserva espaço na criação da tarefa.

Depois... com o tempo você vai ter outro problema: semáforos para controlar o acesso ao hardware, mas, deixa pra hora certa

PAMV - Rapais, se fosse piadinha, eu estaria feliz viu!
Rodrigo_Pa, muito obrigado!

Mas reli novamente as 8 paginas do manual FREErtos, e assisti dois vídeos.
O pessoal é muito bom em explicar, mas considerando-se que a pessoa que está lendo ou assistindo caso fosse, já sabe o que é o stack, heap, etc.
Por exemplo, como sei o quanto de stack vou definir para uma determinada tarefa?
Pude observar que o TCB é padrão na quantidade de memória, mas o stack é definido na evocação da tarefa.
Cada tarefa utiliza TCB+STACK, no caso, se entendi, qualquer variável local, ou constantes setadas em RAM, ficam nesta STACK que eu defini manualmente.
Caso esta tarefa utilize, por exemplo, sprintf. Considero que o espaço de memória é fora do stack que criei, alocando no restante que sobra, no HEAP. Assim como o Rodrigo elucidou...

Seria isso mesmo?

Tipo, tenho 96KB de ram.

Defino então de endereço 0 a 50K como heap.
O SO por si mesmo, as tarefas (caso não utilizem endereçamento por ponteiros fora da região, utilizando apenas alocação dinamica);
Irão utilizar apenas os 50K ficando 46K perdidos, por assim dizer, ou podendo ser utilizados como se fosse EXTRA OS...

É isso mesmo?

Muito obrigado pela atenção!!

Esses "46K" perdidos podem ser usados para variáveis estáticas por exemplo, em baremetal, você define as regiões de RAM utilizada para cada tipo de "coisa".

Pelo que eu vi, você falou que vai usar LPC176x , se for isso mesmo, num vai conseguir usar os 96K pois os espaços de memória não são lineares, você vai ter que alterar o linker para indicar qual região usar para cada coisa.

Rodrigo_P_A escreveu:Esses "46K" perdidos podem ser usados para variáveis estáticas por exemplo, em baremetal, você define as regiões de RAM utilizada para cada tipo de "coisa".

Pelo que eu vi, você falou que vai usar LPC176x , se for isso mesmo, num vai conseguir usar os 96K pois os espaços de memória não são lineares, você vai ter que alterar o linker para indicar qual região usar para cada coisa.

Ah ta, não não.
É que a 10 anos tenho afinidade com ARM7 e CM3, e ultimamente venho utilizando outras coisas...
Na verdade, vou utilizar um 1788 que tem uma memória externa de 16 bits com 32MB.
Esta memoria atualmente é utilizada só para servir para o dma do display TFT de 7".

Nossa, finalmente entendi!!

Vlw Rodrigo, muitíssimo obrigado!!

fabim escreveu:

Rodrigo_P_A escreveu:Esses "46K" perdidos podem ser usados para variáveis estáticas por exemplo, em baremetal, você define as regiões de RAM utilizada para cada tipo de "coisa".

Pelo que eu vi, você falou que vai usar LPC176x , se for isso mesmo, num vai conseguir usar os 96K pois os espaços de memória não são lineares, você vai ter que alterar o linker para indicar qual região usar para cada coisa.

Ah ta, não não.
É que a 10 anos tenho afinidade com ARM7 e CM3, e ultimamente venho utilizando outras coisas...
Na verdade, vou utilizar um 1788 que tem uma memória externa de 16 bits com 32MB.
Esta memoria atualmente é utilizada só para servir para o dma do display TFT de 7".

Nossa, finalmente entendi!!

Vlw Rodrigo, muitíssimo obrigado!!

aí fica mais fácil, de qquer forma terá que configurar o linker para alocar nessa área aí de RAM, com tudo isso de RAM nem precisa esquentar, aloca um espaço bom pra heap e stack e seja feliz

Fabim

Ainda acho que é pegadinha sua.

O stack é usado quando você desvia a execução do programa chamando uma função, por exemplo, ele pode armazenar parâmetros para uso no outro local de execução e armazena o endereço de retorno e outros registradores de acordo com a necessidade.

Em "bare metal" obviamente existe stack, você deve lembrar das instruções push/pull do 6502, p.ex.

PHA .... push accumulator
PHP .... push processor status (SR)
PLA .... pull accumulator
PLP .... pull processor status (SR)

ou as push/pop do Z80, e cia.

Alguns MCU menos sofisticados tem stack fixo como os da microchip e você não tem como alterar o tamanho ou o que vai nele, o datasheet deixa isso explícito em cada caso.

Em "sistemas operativos" o uso é idêntico mas os detalhes disso ficam invisíveis.

No caso do FreeRTOS, ele permite reservar um espaço para o(a) stack de cada task.
O tamanho do stack depende do quanto a task vai recorrer a ele durante a execução, se você estourar o espaço o programa pode sobreescrever o stack ou abortar com uma mensagem de erro dependendo da implementação.

O heap é o "monte" de onde se cata pedaços de memória para usar no programa; se não me falha a memória o Pascal usava gerenciamento de memória baseado em heap/stack e pelo que vejo o Delphi (que eu nunca usei) ainda usa

https://www.thoughtco.com/understanding ... hi-1058464

@pamv, olha agora me deu um nó mesmo.
O contexto é salvo em TCB para tarefa out e tarefa in, ao menos é oque é explicado no manual do FREErtos.
O que eu consigo entender é:

void vMainStackTeste(void){
uint8 A, B, C; //<<< estas variáveis são criadas dentro do stack que eu defini para esta tarefa, ex: 1000 palavras;
for(;;){
A=0;B=0;C = 0;
A = 1;
B = 2;
C = A * B;
}
}

Lá no heap vai ser criado 2 campos para esta task:
TCB = Xbytes + STACK = 4000 bytes;

Quando a tarefa vai sair, ela salva tudo no TCB, e quando vai retomar ela pega o que esta no TCB e seta os registradores do CM3, ele retorna terminando a última instrução que ele estava terminando.

Agora, pelo que você falou, este stack é igual à pilha do pic, para chamadas de interrupção?

Me deu um nó agora!

OBS.: infelizmente sempre adore bare metal, mas nos últimos tempos com IOT e bibliotecas gráficas que simplificam a vida, estou aprendendo do zero como funciona um SO.

Obrigado!

fabim escreveu:@pamv, olha agora me deu um nó mesmo.

Agora, pelo que você falou, este stack é igual à pilha do pic, para chamadas de interrupção?

Fabim

Uma pilha/stack é uma estrutura de dados "last in/first out", lembra?
Como ela é implementada depende da arquitetura, lembra, né?

Como você sabe bem melhor que eu, a pilha do PIC 16f877, por exemplo, tem 8 'níveis' de 13bits e ela existe separada da memória ram, quando a instrução CALL é executada ou ocrre uma interrupção, o valor do program counter (PC) [e salvo no stack, quando as instruções RET* são executadas o PC é restaurado ao valor salvo no stack e a execução continua do ponto inicial.
Num processador mais sofisticado como o Z80 e o 6502 a stack reside no mapa de memória, pode ser acessada diretamente e existem instruções para salvar mais coisas além do PC. Alguns processadores de 8 bits daqueles anos eram mais sofisticados ainda para facilitar os sistemas operativos e possuiam um "user stack pointer" e um "system stack pointer".

No caso do FreeRTOS essas stack/pilhas estão implementada em software e cada tarefa tem a sua própria pilha/stack para poder realizar o seu trabalho.
O quanto se reserva de espaço para a stack de uma tarefa depende da complexidade do que ela realiza.

Ok, então a pilha serve não somente para variáveis locais, mas também como pilha análogamente a pilha de interrupção do pic, do exemplo.
Agora pensando melhor, como cada procedimento que sobe é como se fosse um programa rodando numa micro arquitetura. Dentro dele existem calls, gotos, etc. Então faz-se necessário a pilha local!

Muito obrigado pela paciência!

Ps: O fabim está com 40 anos, 18 de casado, filho de 12, cabeça mais branca que a do MoRal.
Eu não faço mais pegadinhas há anos!! A idade ensina!

Fabim nao manda mais ninguem a M.

fabim escreveu:Ok, então a pilha serve não somente para variáveis locais, mas também como pilha análogamente a pilha de interrupção do pic, do exemplo.

Você falou tanto nisso que eu procurei saber se existe algum PIC com stack exclusivo pra interrupção, pelo menos o pic16 e pic18 não tem, o pic18 "inova" aumentando pra 31 "níveis" e incluindo mais flexibilidade nela. Mas é um stack de interrupt e de call como no pic16

RETURN ADDRESS STACK
The return address stack allows any combination of up to 31 program calls and interrupts to occur. The PC is pushed onto the stack when a CALL or RCALL instruction is executed or an interrupt is Acknowledged. The PC value is pulled off the stack on a RETURN, RETLW or a RETFIE instruction.

Olhei rapidamente o pic24 (nunca usei), ele é mais elaborado mas também compartilha o stack entre interrupts e software. Faz sentido.

Por que eu estou falando isso? Porque no FreeRTOS o stack de cada task é exclusivamente de software e o kernel é que atende interrupções e possui um stack para software e interrupções.

Agora pensando melhor, como cada procedimento que sobe é como se fosse um programa rodando numa micro arquitetura. Dentro dele existem calls, gotos, etc. Então faz-se necessário a pilha local!

Isso mesmo, e o tamanho do stack você define em função da complexidade da taks quanto ao uso de funções/subrotinas

A grosso modo: Nos compiladores C o código gerado tem um "ambiente". Essa estrutura possuí o cstack e o heap.
O que o freeRTOS faz é "alocar" um "cstack" para cada task.
Assim, quando o scheduler coloca uma tarefa pra rodar todo o seu contexto está preservado.
Já o heap, esse continua sendo um só.
(Esse resumo seria para o primeiro SLIDE de um PPT sobre o meu curso de freeRTOS)

É Aquino e onde está o curso?
Olhe, sinceramente, estou começando gradualmente entender o conceito geral!

Em um pic, por exemplo:
Moveu mult para registrador de multiplicação via hardware 1
Moveu mult para registrador de multiplicação via hardware 2
Ele vai setar o bit de multi para pegar o resultado, e antes disso acontece uma interrupção.
O código só libera o desvio após ler o resultado, e isso é via hardware!!!

Existem condições em que o acesso do hardware não pode ser interrompido, por não ser possível fazer o swapf nos registradores (salvar contexto sem alterar o sfr lógico) etc.

No ARM que estou utilizando linha LPC17xx, também existem vários, se não dizer muitos acessos, que só são interrompidos depois de finalizados.

Creio que a forma que todos colocaram, concatenando as informações, ficou bem claro para mim agora.

Mas no livro, o escritor citou
/*

There is no easy way to determine the stack space required by a task. It is possible to calculate, but most users will simply assign what they think is a reasonable value, then use the features provided by FreeRTOS to ensure that the space allocated is indeed adequate

*/

Então fui assistir uns vídeos no Youtube, e um deles tratava exatamente disso.
O cara criou uma forma dinâmica via serial de subir um script e usar o stack passado como padrametro, ao ser dado um comando ele inidicalizava o script.
Ele começou com 10 words, dava erro, 20...30....50....150....300....500 não deu mais nenhum erro de estouro. Então ele sugeriu colocar sempre uns 10% a mais, 550 words.

Enfim, Muito obrigado a todos pela paciência e boa vontade!!

Que a força esteja contigo!