cristianowa / elua4stellarislauchpad Goto Github PK

Para utilizar o OpenOCD com o gdb foi necessário adicionar a flag "-g".
Essa flag deve ser opcional na compilação.

Port eLua 'pd' (platform data) module.

Adapt lm4f_pio.c file and update gpio include files.

Devemos clonar o elua para esse repositório.

Port eLua 'i2c' module.

As written in elua4stellarisLauchpad/src/platform/lm4f/IMPORTANT.TXT, the following files are project specific:

./conf.lua
./conf.py
./flash_conf.h
./lm4f.ld
./lm4f_pio.c
./platform.c
./platform_conf.h
./platform_int.c
./stacks.h
./startup_gcc.c (this a modified stellarisware file)
./type.h

Some of these files have many TODOs (for example, implement CAN, SPI, PWN, etc.) and stub functions for for features. The problem is: we don't know if these resources even exist in the EK-LM4F120XL board.

The task of this issue can be split in the following steps:

1. Make a list of features supported by the board (CAN, SPI, hibernation, floating point instructions, thumb2* instructions, etc.). See the docs of the board and of the microcontroller in the folder "docs_stellaris". Post here the result of the research.

2. For each feature supported by the board, open an issue in github to implement (and test) the feature. Important: comment on the created issue that the feature must be implemented using as much "#ifdef FOR_THIS_BOARD" or/and "#ifdef FOR_THIS_MICROCONTROLLER" as possible. In the future, the code of lm4f may be shared with similar microcontrollers and boards.

3. Make a list of features present in the project specific files (these features have TODOs, stub functions and defines in the files). For example, SPI has stub functions and TODOs in file "project.c" and has an define (NUM_SPI) in "platform_conf.h" (more code and comments of SPI may exist in other files of the project). Post here the result of the research.

4. For each feature present in the project specific files, see if this feature is present in the list of features supported by the board (this list was created in step 1). If the feature exist in the files but don't exist in the board, delete the code and TODOs of this feature in the files, delete or adjust the defines of this feature in the files (for example, if SPI doesn't exist in the board, set NUM_SPI to zero) and delete the issues related to this feature in github.

The task of this issue is essential to the project. It's also important to avoid spending too much time in this task (do not plunge too deeply in the microcontroller datasheet). Just see the documentation of the board, maybe take a look at the microcontroller datasheet and do the task. All necessary docs are in "docs_stellaris" folder. There isn't much code to be seen in the project specific files either. See "Project Status" in the wiki of github to learn what is already implemented in the board at present moment.

This issue can be done by more than one developer: step 1 is independent of the others; step 2 depends on step 1; step 3 is independent of the others; step 4 depends on steps 1 and 3. I could have split this task in more issues, but I prefer to maintain all in one issue to concentrate the information of the whole task.

* I believe that the Cortex-M4 may use thumb2 instructions, but it's using thumb instruction at this moment.

Testar a configuração da stellarisware e e programar para lauchpad stellaris com o GCC para todos.

Vou passar para o joão. Ele passa para outro até fecharmos a issue.

Floating point suport is added in the example " uart echo" of the stellaris ware.
" stellarisware/boards/ek-lm4f120xl/uart_echo/startup_gcc.c" line 286 👍

HWREG(NVIC_CPAC) = ((HWREG(NVIC_CPAC) &
~(NVIC_CPAC_CP10_M | NVIC_CPAC_CP11_M)) |
NVIC_CPAC_CP10_FULL | NVIC_CPAC_CP11_FULL);

We shall also found a way to test if lua is using properly this feature.

We need better debugs capabiblites. So it is wise to make OPENOCD work with the Stellaris Lauchpad and with Elua.

Those posts maybe be useful 👍

http://hackaday.com/2012/11/19/how-to-build-openocd-with-stellaris-launchpad-support/

http://hackaday.com/2012/10/21/debugging-the-stellaris-with-openocd/

With that done, I suggest that we update the wiki and configure.sh script.

The adc module must be ported.
The document: docs_stellaris/ti_manuals/LM4F120H5QR_Microcontroller/applicattion_notes/Using_the_Stellaris_uC_Analog-to-Digital_Converter_spma028.pdf
should help with the task.

Port eLua 'net' module.

The GPIO module must be tested using all possible combinations.
(See pag 611 of Datasheet to unterstand better)

• Input / Output
• Interruption.
• Edge and level sense.
• Pull-up and Pull-Down resistors
• Open-drain

Check max. current for the pad being used.

UIP is not needed in the stellaris lauchpad but could be useful when others lm4fxxxx processor came with integrated ethernet. It could be useful if using a external ethernet controller either.

The Cortex M4 has a CAN interface according to the datasheet.

Since it has only one port. The test can be done against other against the cortex M3.

Devemos ver se o stellarisware é usado no elua ou se a configuração é feita toda na mão.

A new release of elua is available.
We must merge the changes in the current master.

Adicionar entradas e modificar o arquivo src/platform/lm4f/conf.py para a nova plataforma.

Deve-se modificar o script de compilação do elua para possuir uma nova placa target. O melhor é procurar as referências a placa LM3S6569 pois ela também é da familia stellaris.

The spi module must be test.
First thing to do is find a way to test SPI , maybe using a shift register and a few leds., and implement a demo application without elua to validate implementation.

Accordingly to elua docs ( http://www.eluaproject.net/doc/master/en_refman_gen_spi.html )
only master mode is supported.

The follwing funcitons must be implemeted in plataform.c 👍
spis_init, platform_spi_setup and platform_spi_select.

Those functions are called by the elua spi module.

Port eLua 'bit' module.

The PWM on Lm4 is done using timers since there is no PWM units.

This tutorial shall help :

http://codeandlife.com/2012/10/30/stellaris-launchpad-pwm-tutorial/

In progress.

Since arms processors supports both arm and thumb operation modes, we shall try both mode. Just a quick rembember :

Thumb mode is a smaller set, witch gives a smaller program memory footprint and has a small decoding machine ( less power ), but it also has limited access to registers.

Arm mode ( normal ) is bigger and uses all the processor can give, thus, spending more power.

The mode can be toogle through a instruction, so code can be splited in thumb and normal, but the processor must accept that.

Now the elua is being compiling with -mthumb. witch makes the processor use only thumb instructions. We shall test both with a cpu-intensive benchmark ( some taylor series maybe do the job ) and choose the best cost-benefit relation. We shall also seek for a way to compile with both instructions.

O readme esta igual ao elua, precisamos colocar algo coerente sem quebrar a licença original.

We have to check if all files imported are OK and if the defines are pointing to the processor in use.

One of the compilation errors are about the UART pins. Study it and correct the todo in the code.

Port eLua 'cpu' module.

Somente documentação. Conforme no manual http://www.ti.com/lit/ds/symlink/lm4f120h5qr.pdf, pag 89, todas operação de memória do LM4F120 é litle endian.

O elua já compila para o Cortex M3. Tenho uma placa com cortex M3 que posso testar a validade do build. Só tenho que configurar a cadeia de compilação para o M3 também, acredito não ser muito diferente do Cortex M4.

Feito isso, deve-se criar as entradas no elua para um projeto dummy para Cortex M4 e compilar um primeiro projeto, criando um tutorial e/ou um script para as próximas compilações.