Embedded Systems - Shape The World com TIVA TM4C123

[LuísR.A.]

Por acaso já pensei mexer nesse Psoc mas tava a pensar usar o IDE grafico. Mas sinceramente é preciso é ter calma. Agora ando a experimentar os STM32.

Senso eu se quiser uso o TivaWare para programar só com macros tambem! De forma a facilitar. É o que faço quando quero usar só registos.
Mas lembro-me de um vez que tive de desbloquear o micro com uma ferramenta, apagar tudo na flash... tava la algo mal. Com o TivaWare isso nunca me aconteceu

[StarRider]

Calma eu não vou ao cumulo de escrever algo assim:
(APB2PERIPH_BASE + 0x2400) |= 0xFFEC01AD;

Seria mais algo no género: *((uint32_t *) (APB2PERIPH_BASE + 0x2400)) |= 0xFFEC01AD

Abraços,
PA

[senso]

Woosh 

[LuísR.A.]

Calma eu não vou ao cumulo de escrever algo assim:
(APB2PERIPH_BASE + 0x2400) |= 0xFFEC01AD;

Seria mais algo no género: *((uint32_t *) (APB2PERIPH_BASE + 0x2400)) |= 0xFFEC01AD

Abraços,
PA

Precisa de levar um casting antes de ser usado como endereço? 

[Electropepper]

Eu sou da mesma opinião que o senso, demasiada biblioteca ás vezes torna tudo mais confuso e ambiguo, por vezes mais dificil de debugar tambem.

[StarRider]

A única vantagem que advém do uso de libs para aceder aos periféricos é que possibilita a portabilidade entre
MCUs da mesma família e do mesmo fabricante ... e claro que evita quem as usa tenha um conhecimento
mais profundo.

Por norma as Libs fornecidas pelos fabricantes (STM, NXP, TI, etc) têm um overhead estupidamente alto, os
tais assert's ás toneladas nas funções, o aumento dramático do código (e existem limitações de flash em
algumas situações), o próprio overhead da chamada da função e da pré-definição e preenchimento de
estruturas e variáveis antes da chamada à função da Lib, etc, etc.

Existem situações criticas em que simplesmente o recurso a função destas Libs é incomportável, como por
exemplo o uso dentro de rotinas que sirvam interrupções, e em situações em que existem timmings apertados.

Pessoalmente prefiro usar os registos, ou seja, as macros de definição dos mesmos que são fornecidas nos
includes específicos para para MCU, e neste caso a portabilidade apesar de não ser a 100% é muito aceitável.

Por exemplo, inicializar o Timer 1 seria  algo no género:
TIM2->CR1 = (TIM_CounterMode_Up | TIM_CKD_DIV1);
TIM1->ARR = 20;

É compatível com toda a gama da ST, é um acesso directo ao registo e é executado em +-3 ciclos do clock
por linha sem necessidade de passar parâmetros no stack, é simples de entender e de alterar, mas implica
saber o que é o registo ARR e CR1 a as mnemónicas. O equivalente a isto usando a Std Lib da ST seria algo
no género:
TIM_TimeBaseInitTypeDef     TIM_TimeBaseStructure;
TIM_TimeBaseStructure.TIM_Period = 0x0008;
TIM_TimeBaseStructure.TIM_Prescaler = 0x0000;;
TIM_TimeBaseStructure.TIM_ClockDivision = TIM_CKD_DIV1;
TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up;
TIM_TimeBaseStructure.TIM_RepetitionCounter = 0x0000;
TIM_TimeBaseInit(TIM1, &TIM_TimeBaseStructure);

E dentro da função "TIM_TimeBaseInit" vamos ter mais uma 20 linhas de código e uns 6 asserts

Atenção que não estou a desaconselhar o uso das Libs, somente a partilhar a ideia de que o uso destas pode
ter algumas (por vezes grandes) desvantagens em termos de performance e compactação do código.

Abraços,
PA

[StarRider]

Calma eu não vou ao cumulo de escrever algo assim:
(APB2PERIPH_BASE + 0x2400) |= 0xFFEC01AD;

Seria mais algo no género: *((uint32_t *) (APB2PERIPH_BASE + 0x2400)) |= 0xFFEC01AD

Abraços,
PA

Precisa de levar um casting antes de ser usado como endereço?

Boas Luís,

Sim, segue este raciocínio::

Code Select Expand

#define APB2PERIPH_BASE    ((uint32_t)0x40010000)
uint32_t addr = (APB2PERIPH_BASE + 0x2400);  //"addr" é um int e contem o valor 0x40012400
uint32_t * pointer = addr;  // "pointer" é um ponteiro para um uint32_t que está no endereco 0x40012400
uint32_t valor = *pointer; // deferenciar o "pointer",  "valor" contem o valor da zona de memoria localizada no
endereço 0x40012400


Abraços,
PA