STM32F4 e HAL

23

Então, eu tenho experimentado um tempo com o STM32F407 (eu sou novo no ARM) e decidi escrever um aplicativo simples usando as bibliotecas HAL, pois parece que o ST descontinuou as bibliotecas de periféricos padrão. Então, minha pergunta é: qual é o ponto no HAL? StdPeriph não estava fazendo seu trabalho? Por que eles o interromperiam para o HAL? Para mim, parece que o HAL é uma bagunça completa.

A documentação é INCRÍVEL, pelo menos para o StdPeriph, há uma referência completa organizada o suficiente para encontrar facilmente o que você deseja ( http://stm32.kosyak.info/doc/ ). Para o HAL, existe um PDF de baixa qualidade ( http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00105879.pdf ) com estrutura aparentemente aleatória. Ao ler qualquer seção, por exemplo, em relação a um periférico, não consigo entender os requisitos para configurá-lo e personalizá-lo adequadamente. Parece mais notas pessoais de alguém que não quer esquecer coisas do que uma referência.

Sei que posso usar o CubeMX para inicializar o GPIO e configurar periféricos, mas meu objetivo é fazer isso sozinho, para entender melhor a operação deles, e não ter um software que faça tudo por mim. Estou fazendo algo errado? É o novato da ARM em mim que me confunde? Ou a documentação disponível é TÃO ruim?

John
fonte
Algo como o ChibiOS o convém melhor? Eles têm um RTOS, mas também um HAL muito bom que você pode usar sem o RTOS.
IgorEE 31/03
O ST não descontinuou exatamente as bibliotecas de periféricos padrão, mas não lançará novas versões para famílias mais novas. Eles declararam (em algum lugar do fórum, mas não consigo encontrá-lo) que continuariam apoiando o SPL para as famílias para as quais ele foi lançado (incluindo o STM32F4). Como você é novo no ARM, provavelmente é melhor usar o HAL. Eu tenho muitos módulos já escritos usando SPL, então a transição será uma dor e eu tenho adiado. Isso é ruim, pois uma vez que eu decida usar uma nova família, haverá ainda mais código para portar para o HAL #
315 Tut Tut
Este e-book: leanpub.com/mastering-stm32 é uma boa introdução para iniciantes (mas também para profissionais) no mundo do STM32.
Lorenzo Melato

Respostas:

13

Criar suas próprias bibliotecas é bastante simples. Sua documentação de especificação de registro é muito boa, a maioria, senão todos os periféricos, são fáceis de configurar. Acho muito mais doloroso usar suas bibliotecas. mas talvez seja apenas eu. Isso é verdade para st, nxp, ti, atmel, para citar alguns (não tanto para intel e microchip).

Por que eles mudam de biblioteca, pode haver várias razões, um novo chefe assumiu, uma divisão foi fechada e outro assumiu. O marketing queria uma nova imagem para o produto. Como a ElectronS mencionou, poderia ser uma tentativa de se afastar mais do hardware para atrair usuários não dispostos ou capazes de fazer bare metal. Eu iria além e diria que eles provavelmente estão tentando competir com o fenômeno Arduino. O que mbed e todos os demais sempre tentaram fazer e falharam (mesmo antes do Arduino).

De qualquer forma, quanto mais longe o hardware fica, mais inchado e mais lento, portanto, mais você precisa gastar por unidade para rom, ram e mhz. Só para você gastar a mesma quantidade de tempo programando? Apenas fazendo diferente?

Você diz que vem do mundo da PIC, agora eles fizeram um bom trabalho com as ferramentas; seus documentos de chip eram terríveis, alguns dos piores. eles compensaram com bibliotecas e caixas de areia.

No final do dia, tente as várias opções, experimente os produtos concorrentes para ver como suas ferramentas se comparam. Muito disso você pode fazer de graça, apenas para ver se faz sentido e você pode compilar coisas. Talvez até use um simulador de conjunto de instruções. Encontre o que combina com você.

Observe que a opção sem bibliotecas fixas está SEMPRE disponível para você. Você não está limitado a qual cadeia de ferramentas você pode usar, qual sistema operacional host, qual ide, editor, etc. Eles podem ficar com você na programação das partes, se as opções forem extremamente limitadas nesse sentido, passar para outro chip ou fornecedor, se puder.

Para vender um produto com chip como esse, eles precisam fornecer um ambiente de desenvolvimento, seja ele todo deles ou coisas grátis que colaram. E eles tendem a montar uma biblioteca de algum tipo. Ele só precisa parecer bom o suficiente e o piscar do exemplo liderado funciona apenas o suficiente para conseguir que seu gerenciamento ou sua equipe de hardware projete em seus produtos. chega ou não chega. Se quase funcionar, mas não completamente, é uma grande vitória para o fornecedor de chips, pois agora você pagará pelo suporte técnico desse último pouquinho. Portanto, é do interesse deles estar quase lá, mas não completamente.

Os fornecedores de chips precisam apenas ter uma boa aparência para obter a vitória no design. Eles precisam continuar melhorando (mudando) o produto para atrair novos e antigos clientes. Portanto, eles terão que fazer overs, quão distantes e quantas bibliotecas anteriores os continuam a suportar, variam. Portanto, praticamente qualquer biblioteca com a qual você se acostuma desaparecerá eventualmente. Portanto, aprenda a se adaptar (ou não use as coisas deles e escolha o seu, que você pode apoiar indefinidamente). Concedido, idealmente, você só precisa desenvolver o aplicativo uma vez por produto, aperfeiçoar seu firmware (boa sorte se estiver usando bibliotecas de terceiros) e não precisará voltar atrás e encontrar um computador que carregará sua cadeia de ferramentas se você puder encontrar um cópia e lembre-se de como usar essa biblioteca antiga. Lembre-se não apenas de salvar seu código-fonte, mas de todas as ferramentas e documentos deles.

Suas bibliotecas são suportadas apenas em geralmente uma cadeia de ferramentas, em uma talvez duas IDEs e, às vezes, apenas no Windows, e em determinadas versões. Novamente, você não tem nenhuma dessas limitações, definitivamente não para o ARM, se você faz o que quiser. Você sempre pode ler qualquer uma / todas as suas bibliotecas para ver como elas fazem as coisas. Mas isso geralmente é muito assustador, eles não usam os desenvolvedores da equipe A para bibliotecas. Extraí algumas linhas de código para perguntar aos candidatos à entrevista o que há de errado com esse código.

para economizar tempo e esforço, tanto do lado do silício quanto do software, eles costumam reciclar o mesmo ip; portanto, depois de ver como o periférico funciona em um de seus chips, ele geralmente funciona da mesma maneira em muitos outros chips. Sim, os sistemas de clock podem ser complicados com ou sem suas bibliotecas. Grande chance de colocar o chip em tijolos, é aí que a maioria dos meus tijolos em placas / cartões aconteceu. Ajuda a entender como seus chips funcionam, por exemplo, os AVRs, se não todos, podem ser reprogramados enquanto o chip está sendo redefinido; portanto, qualquer código incorreto que atrapalha os pinos necessários para reprogramação ou interrompe a lógica necessária para reprogramação não funciona. importa, você pode reprogramar esses chips. Alguns desses fornecedores (st é um) possuem um gerenciador de inicialização interno que você pode selecionar usando uma cinta (BOOT0, por exemplo, no mundo st),

Um tamanho serve para todos, não para ninguém. Particularmente verdadeiro para software. Portanto, qualquer tentativa de abstrair o hardware apenas o torna lento e inchado. É melhor pegar um chip maior e executar o Linux nele, se é isso que você realmente procura. Muito disso é resultado dos desenvolvedores, que não querem sujar as mãos, então basicamente pedimos isso e eles estão tentando fornecê-lo.

Novamente, não se prenda a st ou a qualquer fornecedor (a menos que seja tarde demais e o gerenciamento e / ou a equipe de hardware o tenha comprometido, observe que os produtos stm32 são agradáveis ​​e fáceis de usar). Compre ao redor. A TI está colocando muitos ovos na cesta do córtex-m4. Você pode executar o mbed em vários desses produtos de braço, bem como nas soluções suportadas pelo fornecedor.

Uma coisa em que você sempre pode confiar é que elas mudam as bibliotecas de tempos em tempos e, eventualmente, param de suportar o que você se acostumou.

old_timer
fonte
Grande argumento sobre o desenvolvimento de suas próprias bibliotecas, quase convencido e eu gostaria de tentar isso, o que você acha que eu precisaria além do manual de referência stm32fxx? devo também ler o manual do núcleo do braço? vou usar o CMSIS? como vou acessar registros e memória? você poderia elaborar mais ou fornecer exemplo de como começar
elétrons
mais algumas coisas em que pensar. toda linha de código adiciona risco. Explique ao seu chefe que você está planejando usar dezenas a centenas de milhares de linhas de código de outra pessoa, sem revisar todas as partes que estiver usando. camadas de código, esp ao abstrair, fazem com que os binários sejam maiores e o desempenho diminua. Então, novamente, explique ao seu chefe que as 10 milhões de unidades de produto vão custar 35 centavos a mais por ou 3,5 milhões de dólares, porque você optou por usar uma biblioteca porque você é preguiçoso.
old_timer
seu chefe pode contratar um exército de pessoas para substituí-lo por esse tipo de dinheiro, revisar todas as linhas de código para que não recebam 10.000 unidades e descubra que precisam destruí-las por um bug de software causado por software arriscado. e use uma parte menor, que custa menos a uma taxa de clock mais lenta, que consome menos energia e dura mais tempo com uma carga de bateria. às vezes vale a pena o esforço. e claro, às vezes não.
old_timer
obrigado por mais pontos que você declarou, mas você poderia responder à minha pergunta sobre a melhor maneira de começar? usando arquivos .h CMSIS e HAL para nomes de registradores e locais de memória?
elétrons
Não existe "melhor", usar essa palavra faz com que seja uma opinião pessoal, não um fato. Basta escolher um e iniciar, ou, como eu poderia, tentar um até atingir um bloqueio na estrada, depois tentar outro e outro, e sair empurrando cada bloqueio de volta para o próximo bloqueio até que um ou todos os rompam.
precisa saber é o seguinte
14

Deixe-me dizer-lhe que muitos de nós compartilham a mesma decepção que você tem com as bibliotecas HAL, elas são realmente pouco e vagamente documentadas e ainda novas contêm muitos bugs.

Então, para responder à sua pergunta, por que a ST optou pelo HAL é simples:

  1. Eles desejam criar uma camada de abstração de hardware que, em inglês simples, significa que o desenvolvimento e o código de software sejam independentes do microcontrolador, portanto, se você escrever um código hoje para o stm32f4 e precisar de alguns anos para migrar para o stm32f7 será fácil e o código será altamente modular.

  2. Isso também permite que mais desenvolvedores, como programadores de software, trabalhem com o microcontrolador sem realmente entender ou entrar em detalhes profundos de como o hardware está realizando uma tarefa. Empresas como ST e TI (iniciando esse caminho agora) estão tentando tornar o desenvolvimento incorporado semelhante ao desenvolvimento de código para PC, no qual você usa drivers de alto nível para desenvolver o código RÁPIDO. A falta de jeito e a falta de otimização em seus drivers e bibliotecas são compensadas pelo alto desempenho dos dispositivos ARM.

  3. Eu acho que o STM32cubeMX é uma ótima ferramenta se você estiver usando bibliotecas HAL, porque o trabalho mais demorado é inicializar periféricos e agora você pode fazê-lo em um tempo muito curto, com interface visual que pode ser facilmente alterada sem afetar o código do usuário (se você escreve seu código no local apropriado) Você pode usar o Stm32cubeMx e, em seguida, revisar o código e tentar entender como e por que eles estão usando cada função. Dessa forma, você está tentando resolver um exercício e ter o manual da solução por perto para correção, o que é ótimo IMO.

  4. O núcleo do ARM é complexo silencioso; portanto, os métodos antigos que usamos no microcontrolador de 8 bits, como manipular registros diretamente (escrevendo C em modo de montagem), não são viáveis, consomem muito tempo e dificultam a manutenção do código devido à arquitetura complexa (verifique a configuração do relógio, por exemplo)

Electrões
fonte
6
Isso tudo é muito compreensível, no entanto, tudo isso se aplica ao StdPeriph também, não é? Quero dizer, ele já é uma biblioteca de abstração de hardware, então qual é o sentido de criar uma nova em vez de melhorar a antiga? Estou genuinamente curioso, sou muito novo no ARM, uso PICs há muitos anos.
John
Ainda mais para as bibliotecas compatíveis com CMSIS
Scott Seidman
11
@ john, tanto quanto eu entendo o HAL é mais abstracta e menos dependente de hardware do que as bibliotecas padrão.
elétrons
12

Eu sei que isso vai ser longo e opinativo, mas como acabamos de lançar (com sucesso) nosso novo produto usando o HAL, acho que vale a pena ser considerado. Além disso, não trabalho para a ST, odiei cada parte do HAL, quase reiniciei o projeto com o StdPeriph, senti a dor - mas agora entendo o porquê.

Primeiro, um pouco de fundo. Desenvolvemos sistemas de telemetria de ultra baixa potência e nosso produto é equipado com um STM32L1. Quando começamos a trabalhar no firmware, tínhamos as opções usuais para dispositivos ST (bare metal): faça tudo manualmente, use as bibliotecas StdPeriph ou vá com o HAL. Os caras do ST nos convenceram a ir com o HAL - assim fizemos. Foi doloroso, tivemos que solucionar bugs no software (a parte I2C nos deixou loucos por um bom tempo) e ainda não gosto da arquitetura geral. Mas funciona.

Quando mudei de desktop para incorporado, um pouco mais de um ano atrás, fiquei impressionado com algo estranho que não conseguia citar nem entender. Com o tempo, consegui entender o que estava - ou melhor, o que está acontecendo: o mundo incorporado está em transição. O silício fica mais barato todos os dias e os MCUs são mais poderosos e versáteis. Cada vez mais dispositivos, independentemente de seu tamanho e necessidade de energia, contam com MCUs genéricos. Mais e mais empresas se juntam ao jogo, trazendo uma horda de novos desenvolvedores com várias origens. A cultura "média" se afasta do tradicional "cara de EE com habilidades de programação em programação" para "cara de SW com conhecimento vago de hardware".

Se isso é bom ou ruim, é irrelevante. Isso simplesmente acontece. Na verdade, isso também aconteceu com o mundo do software, mais de uma vez. O boom da web em 2000 atraiu iniciantes em PHP / MySQL - diga a eles que há registros na CPU, eles responderão "Estou usando Linux, portanto não há registro no meu sistema operacional". Os sistemas operacionais multiusuário anteriores, executados no modo protegido, permitiam que desenvolvedores preguiçosos nunca configurassem um ISR em toda a sua carreira e ficassem bem . Ainda mais cedo, teclados e telas fizeram furadores de cartões e fabricantes de impressoras enlouquecerem.

E sim, as tendências atuais me deixam pessoalmente triste, pois vejo desenvolvedores ignorantes admirados com as últimas tecnologias brilhantes, sendo totalmente incapaz de vinculá-los à história. Quando vejo um jovem me codificando um jogo em Javascript com WebGL em 2015, quero gritar "Não há nada novo! Fiz o mesmo com o C ++ e o 3Dfx SDK em 1995!". O que a história não conta é que o jogo dele é executado no meu celular, enquanto o meu precisava de um PC para jogadores (e um instalador, e eu não conseguia enviar atualizações pela Web). A verdade é que ele poderia desenvolver o jogo em um mês, onde eu fiz o mesmo em seis ou doze.

Obviamente, nem a ST, a TI, a Intel ou quem fabrica chips quer perder a virada. E eles estão certos. O HAL é a resposta da ST e, na verdade, é bastante sólido, não apenas do lado comercial ou de marketing, mas também do lado da engenharia. A razão pela qual é som está no nome:

Camada de abstração de hardware

Se qualquer outra coisa, é isso que você deve se lembrar. O HAL é um esforço para se afastar do hardware. É uma boa engenharia, pois permite dissociar a funcionalidade dos detalhes. Camadas é o que permite desenvolver programas complexos - uma abstração em cima da outra, até o hardware. Abstração é realmente a ferramenta mais poderosa que temos para gerenciar a complexidade . Duvido muito que alguém neste planeta possa programar um navegador da Web em assembly para uma CPU específica.

A mudança cultural é realmente difícil de digerir, mas como eu tenho que considerar que não é necessário ter lido a Arte da Programação de Computadores de Knuth para desenvolver aplicativos da Web, o mundo da EE deve admitir que há recém-chegados que podem (e irão!) Desenvolver código incorporado sem ter lido o manual de referência do caralho .

A boa notícia é que novos jogadores não significam menos trabalho para jogadores mais velhos - pelo contrário, IMHO. Para quem eles vão ligar quando as coisas "não funcionam?". Se você possui RTFM (ao contrário deles) e se sabe o que cada bit desse registro de configuração obscuro faz, você tem uma vantagem.

Entre suas leituras e experimentos, basta ir com o HAL. Novo MCU? Sem problemas. Nova linha MCU? Também não há problema (codifiquei um teste em um STM32F4 Nucleo em apenas um dia com o CubeMX e depois simplesmente o transportei para o nosso dispositivo ... parecia certo ). Zombando para testes de unidade? Sem problemas. A lista continua, porque a abstração é boa.

Obviamente, o HAL em si não é 100% OK. Sua documentação é péssima (mas você tem RT F HRM, não é?), Existem bugs, a ST acabou de lançar uma versão beta para nós (parece bastante padrão hoje em dia) e seu apoio público é uma piada. Mas não liberar o HAL teria sido ainda pior.


fonte
Eu vejo de onde você está vindo. Pelo que entendi, as coisas (infelizmente) seguem o caminho do Arduino, tentando esconder o máximo da realidade do programador para atrair mais pessoas de software de alto nível para a programação de hardware, e essa é a razão por trás de bibliotecas como HAL. Vendo, no entanto, quão mal documentado é e uma bagunça completa também, acho que não conseguirão fazê-lo tão cedo.
João
@ John: HAL não esconde nenhuma "realidade". Tudo está lá para você ajustar. Todas as peças são opcionais - por exemplo, você pode querer usar apenas as macros para acessar os registros, ou apenas um driver específico (por exemplo, I2C) ou tudo, incluindo ISRs e configuração do relógio. Sua escolha. No entanto, concordo que a documentação seja muito ruim. (Eu disse a ST e eles prometeram que eles estavam trabalhando nisso BTW)
Estamos repetindo o mesmo com novas ferramentas. Como as novas ferramentas prometem facilitar e agilizar o trabalho, são econômicos. Mas ainda estamos fazendo o mesmo, porque os seres humanos ainda são os mesmos, não importa se foram 2095 ou 1995. A escolha que nos resta é se seguirmos as novas ferramentas ou permanecermos com nossas já conhecidas ferramentas.
Jony