MicroPython

[Guri]

Tenho comigo que nós programadores, deveria-mos fazer como os macacos o fazem.

Só pular do galho que esta, para outro galho, com o rabo preso no galho que esta saltando . Assim o risco de o macaco cair na chão é muito menor, quase 0.

[tcpipchip]

sim, está bem mais estável o 1.13

Deixaram primeiro para fazer a questao de Certificates...

Acredito que agora partirão para BLE...

Pq conseguiram acertar WIFI e BLE juntos no SDK ESP-IDF 4.X

[mrgadotti]

Tenho comigo que nós programadores, deveria-mos fazer como os macacos o fazem.

Só pular do galho que esta, para outro galho, com o rabo preso no galho que esta saltando . Assim o risco de o macaco cair na chão é muito menor, quase 0.

Tem empresa de dev que já enche o refeitório de bananas

[mrgadotti]

sim, está bem mais estável o 1.13

Deixaram primeiro para fazer a questao de Certificates...

Acredito que agora partirão para BLE...

Pq conseguiram acertar WIFI e BLE juntos no SDK ESP-IDF 4.X

Chegasse a verificar como está o consumo de memória? Já tive problemas com um modem Telit que rodava Python, até o nome das variáveis chegava a consumir memória. Mas isso era um modem antigo e Python 1.5...

[tcpipchip]

nem vi Gadotti...

[xultz]

Eu penso que não existe solução que resolve todos os problemas, e muitas pessoas ficam procurando essa solução, enquanto outras têm certeza que já encontraram. Para cada parafuso tem uma ferramenta certa, e com tecnologia é a mesma coisa.
Saindo dos microcontroladores é assustador a quantidade de linguagens de programação, e muitas linguagens ainda oferecem uma série de frameworks diferentes, e sempre acaba surgindo a pergunta: prá quê tanto? A questão é que a grande maioria dessas ferramentas foram criadas para resolver um determinado tipo de problema. Por exemplo, faz sentido escrever uma aplicação web que o backend é todo feito em C e o frontend todo em vanilla JS? Se o programador for bom, certamente o desempenho da aplicação vai ser sensacional, mas até ficar pronto, o produto já ficou obsoleto, já apareceram pelo menos 5 concorrentes chineses diferentes, o time to market foi pro ralo e o produto não consegue pagar nem o gasto em desenvolvimento, quem dirá dar lucro.
Então, da mesma maneira que se uma pessoa chega e pergunta "vou fazer um produto eletrônico, devo usar um PIC ou um ST?" a resposta é um solene "depende", perguntar se um firmware deve ser feito em C ou MicroPython também "depende". Da mesma maneira que usar ou não FreeRTOS "depende". Ou migrar para Linux embarcado também "depende".
Entender o problema e escolher a melhor solução para o problema é o que separa o bom profissional do velho chato e teimoso que eu sou.

[tcpipchip]

no exemplo do linux, grande parte dos problemas resolvemos com o BASH e ncurses

[mrgadotti]

Já tive colega de empresa que dizia que tudo que fosse diferente de ASM, C/C++ era uma porcaria, mas tudo vai do tempo, disponibilidade de recursos e facilidade. Hoje não vale mais a pena programar um MCU em ASM, não digo de acontecer o mesmo com C/C++. Já trabalhei num Gateway com mais processamento e o pessoal fez uma salada de linguagens de programação, ficou bom pois era um Atom com 4GB RAM, para tal aplicação era mais prático NodeJS, para outra Python e assim por diante e ganharam time to market. Mas não podemos fazer isso num ARM capado sem recursos.

[sync]

Já tive problemas com um modem Telit que rodava Python, até o nome das variáveis chegava a consumir memória. Mas isso era um modem antigo e Python 1.5...

Colega:
Python rodando como um processo do linux é uma situação bem diferente do micropython/lua/forth instalado em um MCU.
Alguém publicou estes valores em um forum para memória RAM livre em várias placas

Código: Selecionar todos

How much RAM (heap size ?) is available for the user in MicroPython running on :
- Pyboard v1.1 (99 KB < 192KB), MicroPython v1.8.6 (updated in 21/11/2016);
- Pyboard Lite v1.0 (84 KB < 128KB), MicroPython v1.8.6 (updated in 21/11/2016);
- Pyboard D SF2W (175 KB < ?KB) and SF2W (470 KB < ?KB), MicroPython 1.10 (updated in 09/02/2019);
- WiPy 1.0 (51 KB < 256 KB), firmware 1.3.0 MicroPython v1.8.2-103 (updated in 02/11/2016);
- ESP8266 (28.6 KB < 96 KB), MicroPython v1.8.6-7 (updated in 12/11/2016);
- BBC Micro:bit (8.4 KB < 16 KB), MicroPython v1.7-9 (used by the BBC Micro:bit online Python editor) (updated in 02/11/2016);
- LoPy (77 KB < 416 KB), firmware v0.9.6.b1 (updated in 27/11/2016);
- WiPy 2.0 (77 KB < 416 KB), firmware v0.9.6.b1 (updated in 27/11/2016);
- Espruino Pico (53 KB < 9 6KB), MicroPython v1.8.4 (updated in 02/11/2016);
- Teensy 3.1 (50 KB < 64 KB), MicroPython v1.8.6 dev-build from dhylands in 20/11/2016 (updated in 21/11/2016);
- Teensy 3.5 (166 KB < 192 KB), MicroPython v1.8.6 dev-build from dhylands in 20/11/2016 (updated in 21/11/2016);
- Teensy 3.6 (229 KB < 256 KB), MicroPython v1.8.6 dev-build from dhylands in 20/11/2016 (updated in 21/11/2016);


[tcpipchip]

me chamou a atenção duas vezes, também programastes FORTH ?

[sync]

me chamou a atenção duas vezes, também programastes FORTH ?

Colega:

Eu reencontrei Forth quando procurava ferramentas para o longan nano e alguém citou/sugeriu o Mecrisp:


Mecrisp - A family of optimising native code Forth implementations for MSP430, ARM Cortex M, RISC-V RV32IM(C), MIPS M4K and FPGAs.

https://sourceforge.net/projects/mecrisp/

[tcpipchip]

legal, eu também utilizei muito forth...mas...para PC.

O meu professor de Controle me deu um livro e mandou eu implementar alguns algoritmos valendo nota

Tambem implementei um lab para ensino de forth a distancia!

[sync]

Caro:

A quantidade de projetos ativos de FORTH para mcu em existência me surpreendeu:

amforth: Interpreter for AVR ATmega

FlashForth: a standalone Forth system for the Microchip PIC 18, 24, 30, 33 and the Atmel Atmega series of microcontrollers

PicoForth - compiler for PIC12 / PIC16

Pic18Forth - a Forth implementation for PIC18Fxx2 microcontrollers

[mrgadotti]

Depois de alguns meses utilizando MicroPython para um produto final, pude chegar nas seguintes conclusões:

- O produto funcionou muito bem, porém foi muita dor de cabeça para coisas que seriam simples de resolver em C/C++
- Fica muito limitado em recurso de hardware/processamento, a mesma aplicação que poderia ser feita com um STM32F103 exige um STM32F401...
- Não é tão simples sair trocando de MCU
- As configurações de Timer do STM32 são limitadas no MicroPython
- Em um ESP8266 tive graves problemas de tempo de execução real time
- Tive um bug que somente acontecia em tempo de execução e perdi algum tempo pra identificar, sendo que se fosse compilado teria encontrado de primeira
- Algumas coisas do Python para Win/Linux não funcionam bem no Micropython ou simplesmente não funcionam
- Uma das vantagens é poder utilizar o interpretador e sair fazendo testes
- Tive problema do MicroPython apagar o script que estava salvo e tive de regravar novamente o software
- Qualquer operação matemática mais complexa dava gargalo de processamento que não acontecia programando em C

Conclusão: Não usaria novamente MicroPython em um produto final (por enquanto), ainda há um longo caminho para evoluir em algo realmente confiável e fico com receio de dar mais dor de cabeça futuramente. Como era um produto que exigia um firmware sem muita complexidade, foi possível utilizar e foi válido como experiência. Para comunidade Maker, algumas coisas podem parecer promissoras, mas o mesmo não acontece em um produto.

O mesmo não se aplica para Win/Linux, o Python está num patamar muito grande de estabilidade e uma comunidade enorme. Já trabalhei com aplicações enormes em Linux utilizando Python, e quando bem programado funciona muito bem.

[tcpipchip]

bom dia
Sim redondo!

Mas sem previsao para usar em LOW ENERGY