História do conversor Ethernet-CAN

Um dia claro e ensolarado para o trabalho precisava de um conversor de interface CAN para Ethernet de baixo custo. Naturalmente, a pesquisa começou com soluções prontas, mas, como acontece com frequência, no final, decidiu-se desenvolver sua própria amostra. Naturalmente, o entusiasmo do autor não pôde resistir e se limitou a uma funcionalidade tão "truncada". O que aconteceu, como e por quê - sob o corte.



Resumo geral. A foto acima mostra um modelo 3D da placa que desenvolvi usando o CAD Altium Designer. Principais recursos e funcionalidades:

• Ethernet de 10 \ 100 Mb
• Rtc
• MicroSD (FAT12, FAT16, FAT32) 4GB
• RS232 \ RS485
• CAN
• Campainha
• 3 LED do usuário
• GPIO
• EEPROM 32 KB
• FLASH 2 MB
• I2C
• SPI
• UART
• SW \ JTAG
• Serial USB (porta COM)
• Potência: miniUSB 5V \ Externo 9..24V

O custo da placa coletada é de ~ 5000 R. O projeto é de código aberto por natureza, as fontes podem ser encontradas no github . O que resultou no final, além da funcionalidade principal, pode ser considerado uma boa placa de depuração para trabalhar com o microcontrolador STM32.

E agora aos detalhes da criação.

Hardware

O estudo desse problema começou com a busca e avaliação de soluções prontas. Os principais requisitos foram:

1. conversão de quadros CAN2.0B recebidos em pacotes TCP \ IP e vice-versa;
2. baixo custo, como resultado, a implementação de um dispositivo baseado em um microcontrolador.

Os colegas da China têm várias soluções industriais, mas não baratas, então um representante do PIRS CAN-Ethernet Interface Converter da produção doméstica foi entregue em nosso escritório para um teste. De acordo com as capacidades e características descritas, o dispositivo satisfez o modesto T.Z., restava apenas verificar o desempenho na prática, o que eu fiz, armado com o Wireshark e o osciloscópio. Por um motivo desconhecido, ao enviar pacotes para o dispositivo TCP na saída do dispositivo, onde os quadros CAN deveriam aparecer, sequências com níveis físicos de CAN (par diferencial), mas com protocolo lógico da interface UART (com bits de início e parada). Abrindo o gabinete, abrindo a documentação dos microcircuitos e tocando os trilhos da placa, descobri que, de fato, os pinos RX e TX (UART) do microcontrolador estão conectados ao transceptor CAN e a um conector externo. Portanto, não era de esperar nenhum suporte de hardware para o padrão CAN2.0B.

Aqui está o que eu vi na saída CANL do "PIRS CAN-Ethernet" ao enviar dois bytes de dados [ 0xF0 ] e [ 0x0A ] através de TCP \ IP:



A ordem dos bits está de cabeça para baixo, mas você pode lidar com isso programaticamente, mas já é mais difícil fazer algo no nível do aplicativo com os bits de início e parada em cada byte, porque eles são inseridos no hardware.

E aqui está como deve ser o quadro CAN2.0B "verdadeiro" com os mesmos dois bytes de dados:



Como você pode ver no oscilograma, além dos bytes de dados, o quadro contém muitos bits de serviço do protocolo, além de bits de preenchimento, e o mais importante, eles passam continuamente sem nenhum bit de início e parada! (Para aqueles que estão interessados, no spoiler, uma descrição detalhada deste pacote).


Assim, não foi possível resolver o problema de incompatibilidade dos quadros CAN e UART com um método de software e, olhando os resultados intermediários da pesquisa com um olhar decepcionado, decidiu-se desenvolver nosso próprio protótipo do dispositivo necessário.

Devido ao fato de que agora era possível controlar uma ampla variedade de características técnicas do dispositivo, foram adicionados os seguintes requisitos:

3. Capacidade de alimentação de 12 a 24 V em sistemas de transporte;
4. A presença de memória externa para armazenar logs;
5. As dimensões da placa não são mais do que 86x80mm.
6. Faixa de temperatura operacional -40..85 ° C

A conhecida plataforma STM32F407VET6 [2] foi selecionada como o cérebro do novo dispositivo, que possui suporte de hardware para todas as interfaces necessárias e um bom suprimento de memória RAM e FLASH. Tendo polido a Internet, o transceptor DP83848IVV [3] foi escolhido como PHY Ethernet, que possui, na minha opinião, boa documentação e exemplos suficientes de esquemas de conexão e roteamento. Como memória externa não volátil para armazenar logs, escolhi o SPI FLASH 2 MB e o SPI EEPROM para armazenar uma variedade de configurações. Além disso, proteção de energia contra sobretensão, inversão de polaridade foi adicionada. Após N noites e M fins de semana, foram compilados um diagrama de circuito e um traço da placa de circuito impresso do dispositivo da primeira versão. Porque havia espaço suficiente na placa, mas eu não queria deixar as pernas ociosas do MK, além da funcionalidade principal, a placa foi adicionada:

• ferramentas de depuração SW, JTAG;
• Switch 8-DIP;
• micro-USB (USB Serial);
• RS-232;
• UART
• I2C;
• GPIO

A idéia era que, se necessário, a placa estivesse pronta para expandir a funcionalidade instalando componentes adicionais. Além disso, os assentos sobressalentes não afetam o custo de produção. Por um lado, infelizmente, por isso, não foi possível encaixar tudo, então a placa acabou sendo 86x80mm bilateral, min. largura da trilha 0,25 mm, diâmetro mínimo do furo 0,6 mm.


A primeira versão do design de PCB

Mais tarde, duas amostras de teste foram encomendadas e montadas com um conjunto completo de periféricos para pesquisa. Para economizar dinheiro, a prancha foi feita sem máscara e, portanto, possui uma cor tão incomum.



Com a ajuda do STM32CubeMX, esbocei um firmware de teste com um teste de operacionalidade dos principais módulos periféricos do dispositivo e, como primeira aproximação, tudo funcionou, exceto para iniciar o MC a partir de um quartzo externo de 8 MHz. Aconteceu que, devido ao meu erro na elaboração da especificação, os capacitores de carga incorretos foram soldados. Mas isso não impediu o STM32F407 de trabalhar com um gerador RC interno. Quando consegui executar ping no meu dispositivo, não houve alegria restritiva. Demorei mais tempo com o rastreamento PHY Ethernet. Então, no navegador, vi minha página http de teste e me acalmei com o teste.

A produção das primeiras amostras dos painéis foi encomendada em Zelenograd. E, apesar do custo de “com” a máscara e “sem” ser quase duas vezes diferente, não recomendo fazer isso nem no estágio de protótipo, porque, como regra, é nesse estágio que os erros de rastreamento aparecem e algo acontece solda. Mas ficar bêbado nas pistas "despojadas" é extremamente desagradável, economize dinheiro, mas quase sem nervosismo. Sim, e adivinhando se houve uma pequena pausa em algum lugar ou se o traço está incorreto - um prazer. Devido à minha inexperiência, soldando um ressonador de quartzo e capacitores de carga, matei uma amostra.

Naquela época, no trabalho, nas caixas havia um pedaço de ferro capaz de resolver a tarefa de conversão no projeto atual, mas, além do grande tamanho e custo, tendo escrito o firmware, encontrei problemas relacionados ao tamanho da RAM e à funcionalidade truncada da pilha TCP \ IP MK LPC2368. Portanto, o desejo de tornar seu dispositivo apenas se intensificou.
Tendo estudado cuidadosamente as deficiências da primeira versão, eu, sem pensar duas vezes, passei para a segunda. E, novamente, eu queria adicionar um "backlog para o futuro", incorporando os seguintes componentes no fator de forma anterior:

• Suporte RTC com bateria;
• RS-485;
• micro-SD;
• campainha tweeter;
• a capacidade de alimentar a partir do USB;
• SPI para conector externo;
• 5V e 3.3V de energia para um conector externo.

Entre outras coisas, a proteção de energia atual e os diodos TVS nos conectores do usuário foram adicionados.

O resultado é um tipo de placa de desenvolvimento com a capacidade de conectar módulos externos. Dessa vez, pedi uma placa na China. A assembléia foi realizada conosco.




A segunda versão do quadro

Na segunda versão, descobri a modelagem 3D no Altium Designer, que ajudou muito a evitar erros no posicionamento relativo dos componentes nos dois lados (verificou-se que a Internet já está cheia de modelos prontos de componentes SMD [4] ). Assim, todos os erros da primeira versão foram corrigidos, as inovações mostraram sua eficiência, o que me deixou muito feliz.

Firmware

A descrição do código está além do escopo desta parte, no entanto, gostaria de dizer algumas palavras sobre o componente de software. No meu dispositivo, decidi usar a pilha FreeRTOS + LwIP. Há um número suficiente de artigos sobre eles, por exemplo, [5] e [6] , portanto não deve ser difícil vinculá-los ao seu projeto. Em resumo, o LwIP é uma pilha TCP \ IP para sistemas embarcados, caracterizada pelo baixo consumo de RAM e uma API conveniente (existe até um shell de soquete BCD). Eu usei a API netconn. Por meio do FreeRTOS, todo o trabalho da pilha TCP \ IP é colocado em um fluxo separado do aplicativo. Além do trabalho principal (conectar um servidor TCP externo ao barramento CAN), um servidor da Web separado está girando em um fluxo independente para acessar as configurações do dispositivo. Essa interface da Web destina-se a monitorar e definir as configurações do dispositivo - definindo diferentes modos de operação, velocidades de transmissão, endereços etc. Ainda não sei se será possível fazer uma atualização de firmware através dele.

Conclusão

Esse foi o meu primeiro (e espero que não seja o último) projeto de hardware com tanta complexidade e, apesar dos erros cometidos, a segunda versão do conselho, eu acho, pode ser considerada bem-sucedida. Em cada iteração, havia muitas dúvidas, mas, no entanto, mais uma vez estou convencido de que, se você não tentar, nada certamente resultará.

Fontes utilizadas

1. Wikipedia / Controller_Area_Network
2. Folha de dados do STM32F407VET6
3. Folha de dados DP83848
4. modelos 3D
5. Introdução ao FreeRTOS
6. Introdução ao LwIP