Migra o template para CPP

[Eduardo-Barreto]

Com o recente movimento de migração dos códigos da equipe para C++ e a criação das libs, acho que faz total sentido migrarmos esse template aqui também, tanto para facilitar a criação de novos projetos quanto para os testes da lib mesmo

O que foi feito?

• Mudanças no CMakeLists.txt pra compilar em C++ (bem trivial)
• Migração do MCU, main e testes para C++
• Adição do Uncrustify como formatador padrão do vscode (não diretamente do escopo da PR, mas vi e não entendi pq nao tava antes)

[Eduardo-Barreto]

Ah, só uma coisa, existe uma branch antiga de migração, mas fui orientado na gaiola de simplesmente abrir outra (desculpa xin)

[n-honda2]

Acho q tá td check, vc falou q compilou certinho então sucesso

[Bruno1406]

Para além dos comentários q eu fiz, fiquei preocupado se nn faltou isso aqui no cmake

Nn manjo nada dessas opções de linker nn, mas foi só com elas que eu consegui buildar a lib de IMU.

[Bruno1406]

Isso aqui é só um comentário. Nn sei se vejo muito sentido nisso aqui ser uma classe nn. Se a ideia for encapsulamento, "mcu" poderia ser um namespace. Por outro lado, eu entendo que está seguindo um padrão e piriri pororó.

[Eduardo-Barreto]

po foi 100% pelo padrão

a ideia era manter como nas futuras libs, mcu ser uma classe no namespace hal

[Erick-DAS]

Só deixei uma pergunta sobre padrões ali no CMake, mas fora isso parece tudo check

[LucasHaug]

O uncrustify deixa essa chave aqui mesmo? Estranho ahushuashuashu

[Eduardo-Barreto]

aisduhas de fato estranho, mas o make format nao mudou isso aí

[LucasHaug]

Então, não sei sobre deixar esse namespace hal aqui, acho que pode deixar mais simples pro template. Não é porque existem namespaces que a gente tem que colocar vários, tem que saber dosar. Mas assim batata também.

[Eduardo-Barreto]

ah, na minha cabeça fazia sentido (principalmente considerando as libs), só botei pq nao vi pq nao botar sinceramente

[pedroazeredo04]

Acho que eu gosto de um namespace hal, ele ajuda a segmentar o que é baixo do que é alto. Se algo tem escrito hal:: antes, a gente sabe que é uma abstração de algo bem baixo nível, coisa de função da ST.

[LucasHaug]

Tenho alguns mixed feeling sobre deixar isso como classe no template. Tipo não é porque suporta classe que a gente tem que usar classe em tudo. O sleep e o init até fazem sentindo estarem numa classe assim, tanto que eles já tinham o prefixo do mcu_, mas aí o led toggle deixa meio estranho. Como não tem muito também onde colocar, batata também ahushuauahas.

Esse e o comentário do namespace são meio batatas, é só pra pensarem quando tiverem as coisas de usar com moderação as features da linguagem.

[Eduardo-Barreto]

o sleep e o init foram por esse motivo q vc citou, o led_toggle eu imaginei que se referia ao led da placa asudhasiudh no caso da bluepill é o C13, mas no código estar o A5 deixa mais esquisito mesmo asduihasiu

[pedroazeredo04]

Também tenho mixed feelings mas acho que tem que ficar como classe sim. Na minha opinião, numa alternativa sem classe, ficaria meeeio estranho de acessar, ficaria algo do tipo hal::sleep(50), daí ainda mais com RTOS, é um sleep do HAL? É um Sleep do RTOS? Sei lá asdhuadhuasd acho que hal::mcu::sleep(50) é mais bonito. Posteriormente poderíamos ter um hal::rtos::sleep(50) ou sei lá hal::rtos::publish(mensagem), enfim, daí vai, mas é tudo hal né

[pedroazeredo04]

Cara eu boto fé, achei bem legal do jeito que tá, com namespace pras coisinhas do HAL e tals.

Idealmente, essa abstração das funções do HAL viriam de uma lib?

[pedroazeredo04]

Acho que eu gosto de um namespace hal, ele ajuda a segmentar o que é baixo do que é alto. Se algo tem escrito hal:: antes, a gente sabe que é uma abstração de algo bem baixo nível, coisa de função da ST.

[pedroazeredo04]

Também tenho mixed feelings mas acho que tem que ficar como classe sim. Na minha opinião, numa alternativa sem classe, ficaria meeeio estranho de acessar, ficaria algo do tipo hal::sleep(50), daí ainda mais com RTOS, é um sleep do HAL? É um Sleep do RTOS? Sei lá asdhuadhuasd acho que hal::mcu::sleep(50) é mais bonito. Posteriormente poderíamos ter um hal::rtos::sleep(50) ou sei lá hal::rtos::publish(mensagem), enfim, daí vai, mas é tudo hal né

[Eduardo-Barreto]

@pedroazeredo04: Idealmente, essa abstração das funções do HAL viriam de uma lib?

não sei se entendi o que vc quis dizer, é sobre as HAL_* dentro das funções no mcu? se sim, fiquei meio confuso de como fazer isso sem obrigar quem for usar o template de usar nossas libs (tudo bem que seria só mudar esse arquivo mas sei la asudhausdh) e coloquei direto as funções do hal, mas é mutável pra deixar com a lib se for o caso, como o led_toggle usar a gpio, apesar de ficar meio alubaubdsalub sobre isso kkkkkkkk na minha cabeça tudo bem a galera que ta no namespace hal usar o hal da st mas entendo o ponto

[Eduardo-Barreto]

Revendo aqui, removi o led_toggle do mcu pq realmente não faz muito sentido auihashdauis mas acho que de resto ta tudo check

[LucasHaug]

Não revisei de novo agora, mas antes de dar merge de qualquer coisa, acho que seria bom fazer umas releases e atualizações. Primeiro diria pra finalizar a PR #37 e aí fazer uma release da main com a versão final do projeto com Makefile e depois fazer merge da main na develop com as coisas novas, aí diria pra fazer merge da develop na main com as coisas de CMakeLists e aí fazer outra release. Aí acho que dá pra ver de mergear essa PR na develop, só pra gente ter os estágios das coisas diferentes salvos em releases e as coisas não se misturarem de uma vez e a PR da develop pra main virar um monstro.

[Eduardo-Barreto]

Top top @LucasHaug, a ideia era mergear as coisas atuais pra develop e depois mandar pra main mesmo, mas não tinha pensado no release, vou fazer aqui

sobre essa outra PR, ia comentar AGORA aqui na gaiola pra fechar ela, inclusive vi esse seu comentário aqui pq vim de lá kkkkk