Grandes problemas de configuração para dispositivos pequenos

Parte 1. Letra

O mundo moderno é inconcebível sem um grande número de assistentes eletrônicos e elétricos. A partir de computadores e smartphones, terminando com um simples interruptor de luz na cozinha e disjuntor de proteção de entrada. De uma forma ou de outra, você precisa interagir com todos os dispositivos. Com um pouco mais de frequência, por exemplo, um smartphone, do qual algumas pessoas não saem do controle, com outras com menos frequência, o mesmo dispositivo automático de proteção de entrada para um apartamento, cuja existência alguns nem sequer sabem.

Quanto aos dispositivos da primeira categoria, tudo é simples lá. A interface, de fato, é gráfica e é determinada por designers e programadores. E com os dispositivos do segundo, em termos de interação, não de importância, o plano é muito mais complicado. Nós os tomamos como garantidos, o mesmo interruptor de luz ou para a mãe, quando eles fazem seu trabalho, como uma máquina de entrada que trabalhou sobrecarregada.

Para dispositivos muito simples, a interface é primitiva. Botão ou interruptor, vários botões para o termostato, por exemplo. As características são definidas pelo fabricante e não são alteradas pelo consumidor. Corrente de disparo 10A, 16A, 25A ... Mudando para 6A 230V ... Mas quando o dispositivo é um pouco mais complicado, tudo fica muito ruim.

Um pouco distraído, vou falar sobre minha falha apenas por causa da interface de hardware. Havia uma tarefa de balanceamento de carga para uma casa particular. De fato - um relé de tempo programável multicanal. Eu fiz um protótipo literalmente à noite, entreguei ao cliente, o cliente, um colega de casa, ficou satisfeito, decidi tentar estabelecer uma produção em pequena escala, organizar uma pequena startup eletrônica em uma aldeia, pois o problema da falta de capacidade de entrada é relevante para o setor privado. Um problema de design permaneceu - a configuração do dispositivo. No protótipo, os intervalos foram simplesmente compactados no firmware, se 200 instruções do montador pudessem ser chamadas assim. Algumas vezes eu tive que ajustar as configurações, isso foi feito simplesmente montando um novo firmware e atualizando por meio do programador. É claro que, para um dispositivo serial, mesmo em pequena escala, esse método não é adequado.

Aqui me deparei com todos os "encantos" do desenvolvimento de uma interface de usuário de hardware ... Métodos simples, como escrever 16 opções de configurações e definir a chave deslizante, não davam a flexibilidade necessária, tornar qualquer interface séria para a comunicação com um PC ou smartphone é uma complicação injustificada, um aumento no preço. Além disso, surge imediatamente a necessidade de desenvolver um aplicativo simples, mas multiplataforma (Win / Linux / Android / iOs). Mas isso não é o principal. De fato, o usuário configurará o dispositivo uma vez durante a instalação e, idealmente, não o recuperará mais.

Em contraste com o protótipo, um indicador LED de 4 bits, botões e LEDs apareceram no painel frontal do dispositivo. Também foram adicionadas funcionalidades, características de atrasos na ativação da carga após uma queda de energia, modos adicionais para alimentação de uma linha de transmissão de energia ou gerador de reserva, mantendo a temperatura de congelamento ...

E aqui está o layout em massa deste monstro de Frankenstein

(Controla contatores, dentro de circuitos de comutação de bobinas de baixa corrente)

Desde que a funcionalidade de apenas um relé programável estivesse presente, não era difícil com as configurações; a interface de hardware criada compensava. Mas, em algum momento, as instruções de configuração começaram a exceder o tamanho do código do firmware. Ideia inicial: o usuário digitaliza o código QR no painel de instrumentos, vai para a página com a instrução - falhou. Resta criar um dispositivo muito simples ou procurar outro método de comunicação com o dispositivo. Os compradores em potencial (testadores corajosos) por muito tempo entenderam a configuração de acordo com as instruções.

O mais triste é que tenho protótipos de vários dispositivos que já foram configurados e vivem suas vidas em um painel elétrico. Configuração - uma dúzia de outros bytes. Resta encontrar uma interface adequada.

O que temos hoje? Comparação dos métodos de configuração "clássicos":

• A escolha de configurações prontas. PRÓS: Implementado facilmente software e hardware. Melhorias de hardware adicionais são mínimas. O usuário não precisa ter equipamento especial, instruções suficientes. CONTRAS: Não há flexibilidade, nem intuitivamente, são necessárias instruções.
  
• Uma sequência de cliques com feedback por meio de uma exibição simples (semelhante à configuração de um relógio eletrônico comum). PRÓS: É facilmente implementado de forma programática, o usuário não precisa ter equipamentos especiais, instruções suficientes. CONTRAS: Não intuitivamente, é difícil configurar um grande número de parâmetros, a incapacidade de clonar as configurações, o que é essencial para as empresas instaladoras.
  
• Configuração usando uma interface com fio padrão. PRÓS: Intuitivamente, se o aplicativo for bem escrito, clonagem fácil de configurações, implementação relativamente simples, talvez melhorias de hardware não muito caras, a capacidade de atualizar o firmware. CONTRAS: O usuário deve ter equipamentos, pelo menos um computador ou laptop com uma porta USB, um conversor de interface, se o dispositivo fornecer algo diferente de USB ou Ethernet. A necessidade de desenvolver um aplicativo.
  
• WiFi + WEB - tiro de um canhão em pardais e terry ardurinshchina. Mas a ideia não é ruim. PRÓS: semelhante a uma conexão com fio, não há necessidade de desenvolver um aplicativo de plataforma cruzada, fornecendo a interface WEB embutida do configurador; basta que o usuário tenha qualquer dispositivo com suporte a WiFi e um navegador. O acesso à rede global nem é necessário. Talvez esse design seja mais barato que os botões / indicadores de hardware, o caso também é simplificado. CONTRAS: Tecnicamente, uma solução extremamente feia que transfere o produto para uma classe de dispositivos completamente diferente. A confiabilidade é reduzida, devido à complexidade do firmware e ao aumento da sensibilidade ao EMF.
  

Resumo que uma das soluções mais bonitas do ponto de vista do usuário é a última. Mas também é um dos mais terríveis do ponto de vista de um engenheiro. Eu quase parei com isso, mas ...
Curvatura técnica assombrada. Para escrever alguns bytes na EEPROM, cercar um jardim com uma pilha de protocolos tão extensa é irracional. Mas parece que eu encontrei uma solução para o meu problema, eis as características deste método:

Prós:

• O aumento no preço do componente de hardware é comparável à decisão de "escolher entre configurações prontas", 10 a 15. Rublos. E a capacidade de recusar botões, indicadores, etc. extras oferece um preço mais barato.
  
• A implementação de software não é um problema.
  
• Não requer o desenvolvimento de um aplicativo especial. Se desejado, o aplicativo pode ser fornecido.
  
• A intuitividade depende da qualidade do desenvolvimento do configurador ou aplicativo WEB.
  
• Isolação galvânica com o dispositivo.
  

Contras:

• Baixa taxa de transferência de dados em comparação com uma interface com fio ou rádio.
  
• É necessário contato físico com o dispositivo.
  
• Você precisa de pelo menos um acesso à rede.
  

Além disso, esse método de transmissão de informações é muito comum por natureza. Esta é uma onda sonora.

Agora, talvez todo mundo tenha smartphones. Sem smartphone - qualquer dispositivo para reproduzir som, mesmo um toca-fitas, é adequado. Como vejo essa interface em ação:

1. O usuário instala o dispositivo de acordo com as instruções.
   
2. A configuração necessária do dispositivo é criada, os modos e configurações necessários são registrados.
   
3. O usuário coloca o dispositivo no modo de configuração, por exemplo, por uma sequência especial de pressionar uma tecla, o dispositivo exibe um estado pronto, por exemplo, piscando um LED com uma frequência de 5 Hz.
   
4. No configurador, o ícone "parâmetros de transferência" é clicado, após o qual a sequência de som codificada começa a tocar (e quem os carregou das fitas nos anos 90?).
   
5. O usuário espera que os dados sejam carregados no dispositivo (por exemplo, o LED acende constantemente) e clica no ícone "parar a transmissão".
   

Tudo, novos parâmetros são transferidos para o dispositivo. Você acha que esse método de configuração será conveniente o suficiente?

Em vez de um posfácio

Eu especificamente não toquei na parte técnica da implementação. Cada caso pode ser individual, a abordagem é uma ideia geral. Se o artigo despertar interesse, publicarei a segunda parte. Prático. Enquanto o spoiler: a idéia foi bem-sucedida, o modelo na versão de 8 bits PIC16 + "student" do compilador C sem otimização, incluindo manual, o firmware se encaixa silenciosamente na memória (cerca de 1 KB) e no desempenho. A operação matemática mais difícil é a adição de sint8_t e sint16_t. De acordo com cálculos preliminares, o núcleo do configurador de som, reescrito no Assembler, caberá em menos de 512 quilos e o PIC16F819 deve ter desempenho de 2MIPS.

Tudo de bom
Konstantin.