XMOS startKIT:Construindo um XMOS e Raspberry Pi Robot XMP-1

Introdução

O XMOS startKIT da Farnell (ou Newark) é uma plataforma de processador de custo muito baixo (£ 12 incluindo IVA) que funciona bem com o Raspberry Pi. Juntos, é possível construir aplicações de robótica quase sem necessidade de solda.

O XMOS startKIT é uma placa do tamanho de um cartão de crédito com um chip XMOS com vários 'núcleos XMOS' que podem ser programados em C. A tecnologia XMOS permite que as coisas funcionem em paralelo em alta velocidade com baixo jitter. Essas são exatamente as características que podem ser ideais para aplicações de robótica.

Junto com algum código para rodar na placa XMOS startKIT e no Raspberry Pi (RPI), as placas são usadas para construir uma plataforma móvel compacta simples (vou chamá-la de XMP, XMOS Mobile Platform em vez de um robô a partir de agora no espírito XMOS de precedendo tudo com 'X').

Embora o XMP-1 não seja exatamente um robô até que tenha alguns sensores e mais programação, ele pode ser estendido no futuro para experimentos de robótica. O XMP-1 usa hardware padrão de baixo custo e nenhuma ferramenta exótica além de chaves de fenda, alicates e alicates.

Esta postagem cobre a comunicação entre a RPI e a placa XMOS usando uma interface de interface periférica serial (SPI) e como construir o XMP-1 e controlá-lo a partir de um navegador da web.

O vídeo aqui mostra o XMP-1 sendo ensinado uma rota; a primeira tentativa de usá-lo! Ele se beneficiaria de uma interface de usuário melhor. O XMP-1 pode se mover muito rápido, mas eu peguei mais fácil aqui em uma velocidade baixa. À direita está o controle do navegador e na parte inferior está a saída do console, apenas gerando algumas mensagens de keep-alive e de status para ver o que está ocorrendo.

O próximo vídeo abaixo mostra o XMP-1 tentando reproduzir a rota e causando sofrimento e dor ao longo do caminho. Meus servos de rotação contínua de baixo custo (que estão sendo usados ​​para mover as rodas) não eram muito bons e o XMP-1 ainda não tinha sensores.

Um pouco mais de detalhes

Esta postagem é na verdade a parte 2 de alguns experimentos XMOS startKIT. A Parte 1 contém a introdução, terminologia, arquitetura e um guia de introdução rápida com programas de exemplo do XMOS. Se você estiver interessado na tecnologia, pode ser útil seguir a parte 1 primeiro, para que esta parte 2 faça mais sentido. Esta parte 2 tem como objetivo construir uma estrutura simples para comunicações de alta velocidade entre o Raspberry Pi e a placa XMOS startKIT. A estrutura deve ser de propósito geral o suficiente para ser usada em muitos projetos (robótica não era minha intenção). O XMP-1 é realmente apenas um subproduto, no desejo de testar as comunicações da placa Raspberry Pi com a placa XMOS. É registrado aqui, caso seja útil. (Observe, também há uma parte 3 intitulada XMOS startKIT:XMOS e Raspberry Pi Oscilloscope XAE 1000 que reutiliza a capacidade SPI discutida neste post e apresenta como usar o conversor analógico para digital (ADC) que está presente no chip XMOS e como executar gráficos em tempo real em um navegador da web).

Se você está interessado apenas em construir e usar XMP-1, então você pode simplesmente pegar o código na parte inferior da postagem, compilar e armazenar em Flash (conforme descrito na parte 1) na placa XMOS startKIT e no Raspberry Pi, e basta seguir as seções que descrevem a montagem de hardware XMP-1, ignorando todo o outro conteúdo aqui. Se você estiver interessado em controlar qualquer hardware usando o Raspberry Pi e um navegador da web, parte do código aqui pode ser reutilizado. Mas, para obter o máximo da combinação de startKIT de Raspberry Pi e XMOS, as informações restantes aqui podem ser úteis se você for novo no startKIT.

Visão geral da solução - Hardware e software

Aqui está uma foto do XMP-1 concluído sendo carregado. Para uso externo, usei um dispositivo do tipo ponto de acesso 802.11 (MiFi), executando o navegador em um telefone móvel.

O diagrama abaixo mostra o layout aproximado dos bits e peças, visto da parte traseira do XMP-1. Você pode ver que é bastante básico - o XMP-1 foi apenas um experimento rápido.

O Raspberry Pi (RPI) é usado para controlar todas as atividades da rede. Ele executa um pequeno servidor da web e a maior parte do código é escrita em JavaScript em uma plataforma Node.js. O RPI comunica as velocidades de controle do motor (na verdade, servos de rotação contínua foram usados ​​para XMP-1) por meio de uma interface serial (SPI) para a placa XMOS startKIT. O XMOS startKIT é responsável por alimentar os sinais de modulação por largura de pulso (PWM) para os motores.

O RPI é conectado à rede por meio de um adaptador USB WiFi 802.11.

O diagrama de fiação completo é mostrado aqui. O hardware e a construção são descritos posteriormente.

O diagrama abaixo mostra o software que será implementado no RPI e no startKIT. Parece muito, mas não é e pode ser dividido em pequenas partes que serão descritas mais adiante. Conforme mencionado, todo o código-fonte está no final deste post, então ele pode ser usado sem qualquer modificação, se desejado.

Em resumo, o bloco verde lida com a interação da web e determina a velocidade e a direção dos motores com base na entrada do usuário. O bloco verde fornece uma página da web (index.html) ao usuário que incorpora a interface do usuário. O programa xmos_servo é um pequeno software escrito em C que traduz a velocidade / direção desejada em bytes de dados da interface periférica serial que são enviados para o startKIT. O software startKIT é dividido em três partes que são executadas simultaneamente em núcleos XMOS separados. O spi_process converte os sinais SPI em dados que são armazenados em uma matriz. O código data_handler inspeciona o array para decidir o que fazer (a única conclusão que ele tira hoje é manipular os servos). O processo servo_handler produz um fluxo de pulso para os servos, para que eles possam girar na velocidade desejada. Todos esses blocos são explicados em mais detalhes mais adiante.

Interface Periférica Serial (SPI)

O SPI conta com quatro fios conhecidos como SS, SCLK, MISO e MOSI e uma atribuição de mestre e escravo para os dois dispositivos envolvidos na comunicação. No caso da placa RPI e XMOS, o RPI é o dispositivo mestre e é responsável por gerar o sinal do clock. O RPI transmite dados no fio MOSI e os dados recebidos no fio MISO. Isso significa que a interface SPI pode transferir dados de forma bidirecional ao mesmo tempo. Na prática, se os dados unilaterais forem necessários, o sinal MOSI ou MISO pode ser ignorado, dependendo da direção de interesse.

A captura de tela do osciloscópio aqui (sinais individuais e a decodificação SPI automatizada de um osciloscópio Tektronix MSO2024B) mostra um exemplo de comunicação SPI usando o Raspberry Pi. O SPI pode ser configurado de algumas maneiras; você pode ver neste exemplo que três bytes de dados foram transferidos do mestre (RPI) para o escravo (placa XMOS) e que eram 0x02, 0x00 e 0x10, e nenhum dado ou 0x00, 0x00, 0x00 foram transferidos do escravo do mestre simultaneamente.

O fio SS é um sinal de seleção de chip (baixo ativo). O RPI tem dois pinos em seu conector de 26 vias que podem ser usados ​​para SS; eles são mostrados circulados em azul no diagrama abaixo, marcados como CE0 e CE1. Isso significa que o RPI pode se comunicar com dois dispositivos escravos SPI, se desejado. Neste caso, apenas um dos pinos CE foi usado - eu escolhi CE1.

Servo motores Hobby ontrolling

Os servo motores Hobby geram um movimento com base em um sinal de entrada. Eles geralmente giram menos de uma volta completa. Normalmente, um servo de passatempo irá girar dentro de uma faixa de cerca de 180 graus. O eixo de saída pode ser conectado a (digamos) ligações para fazer as rodas girarem totalmente para a esquerda ou totalmente para a direita (ou qualquer coisa no meio) com base no sinal de entrada.

O diagrama abaixo mostra o interior de um servo hobby típico (obtido deste site). À esquerda (em azul) está um motor DC convencional. É bastante desacelerado, e o eixo final pode ser visto à direita conectado a um braço azul que poderia ser conectado a um mecanismo de direção por roda, por exemplo. Embaixo do eixo final estará um potenciômetro, que fornece feedback sobre a posição exata do eixo final. Um servo de passatempo é, portanto, um sistema de loop fechado e pode se autocorrigir se o braço for acidentalmente afastado da posição desejada.

Os servos Hobby normalmente têm três conexões; 0V, 5V e sinal. O fio do sinal é uma entrada digital para o servo e requer um sinal PWM. O tamanho da largura de pulso determina o ângulo para o qual o eixo se moverá. O sinal PWM precisa ser repetido a cada 20 ms e uma largura de pulso de 1,5 ms irá resultar no eixo se movendo para uma posição centralizada. Uma largura de 1 ms irá mover o servo totalmente em uma direção, e uma largura de 2 ms irá mover o servo totalmente na outra direção (mais abaixo haverá alguns traços do osciloscópio de controle do servo).

Existe um tipo de servo modificado conhecido como servo de "rotação contínua". É um servo modificado onde o potenciômetro é removido junto com quaisquer batentes finais, e o circuito é persuadido a pensar que o servo ainda está na posição centralizada. O envio de PWM com uma largura de pulso diferente de 1,5 ms fará o mecanismo girar no sentido horário ou anti-horário a uma velocidade que depende da largura do pulso. O XMP-1 usa dois servos hobby de rotação contínua, um para cada roda. Eles não são uma forma ideal de obter movimento controlado (o XMP-2 usará motores escovados DC), uma vez que estão sendo usados ​​para uma finalidade diferente da intenção original para servos de hobby, mas têm a vantagem de poderem ser controlados por um dispositivo digital sinal lógico e eles não requerem nenhum circuito H-bridge externo.

Os fios do servo Hobby podem ser codificados por cores de forma diferente dependendo do fabricante. Normalmente o fio central é vermelho e vai para + 5V. O fio preto ou marrom é 0V. O fio branco ou amarelo é a entrada do sinal PWM.

Iniciando o desenvolvimento - Conectando as placas

Para desenvolver o software, o RPI e o startKIT foram conectados usando um cabo plano e um conjunto de conector IDC - eles podem ser montados usando um torno ou comprados prontos. Para uma versão montada automaticamente, vale a pena comprar um conector IDC extra para usar como um conector de depuração no centro do cabo, para facilitar a vida ao sondar sinais com um multímetro ou osciloscópio.

Implementando SPI (spi_process) no XMOS startKIT

O uso do ambiente de desenvolvimento XMOS (xTIMEcomposer) foi abordado na parte 1. As capturas de tela abaixo mostram a versão do Windows do xTIMEcomposer, mas a versão do Linux parece idêntica (e possivelmente a versão do Mac também pode ser semelhante).

Neste ponto, você pode clicar com o botão direito do mouse em SPI Slave Function Library no xSOFTip lab e importar a biblioteca para o espaço de trabalho. Não sou especialista em xTIMEcomposer, então provavelmente estou usando errado aqui, mas o código-fonte e o arquivo de cabeçalho para a biblioteca apareceram em uma pasta separada no Project Explorer (mostrado em um círculo em azul abaixo):

Os arquivos deveriam estar na pasta spi-test (para que apareçam conforme mostrado em um círculo verde acima) para que eu copiasse manualmente os arquivos spi_slave.h e spi_slave.xc da pasta module_spi_slave / src para o spi-test pasta / src usando o Windows Explorer.

O software usa o conceito de portas para controlar a saída ou ler a entrada. Há um mapeamento entre essas portas lógicas e o mapeamento físico para o pino no chip. Os mapeamentos podem ser alterados em certas combinações (consulte a figura 3 no documento PDF Introdução às portas XS1).

As portas de entrada / saída em dispositivos XMOS podem ter largura de 1, 4, 8, 16 ou 32 bits. Ao projetar com a peça, você pode desejar alocar certas funções para portas de 1 bit, ou outras funções para portas de multibits e, portanto, a figura 3 será muito útil para determinar quais portas e pinos usar.



Com o código escravo SPI agora no filder spi-test / src, esse código foi ligeiramente modificado. O código da biblioteca pressupõe que as portas que estão sendo usadas para a interface SPI são todas portas de 1 bit, enquanto o pino SS Raspberry Pi SPI (CE1) está conectado a uma porta de 32 bits na placa XMOS. A Figura 8 do documento PDF startKIT Hardware Manual é mostrada abaixo. No centro, em verde, você pode ver o cabeçalho de 2 × 13 vias que se conecta entre a placa XMOS e o Raspberry Pi. À esquerda e à direita em azul estão os nomes dos pinos físicos no chip (X0D0 ,, X0D11, etc). Os valores destacados pelos pinos são os números das portas lógicas. P1A, P1D e assim por diante são portas de bit único. P32A1 é o primeiro dígito binário de uma porta de 32 bits

Muitas mudanças foram feitas na biblioteca SPI e todo o código está anexado ao post, então apenas alguns trechos de código serão descritos aqui, não há necessidade de copiar / colar, o código completo anexado no final deste post pode ser usado.

A interface SPI no dispositivo XMOS é inicializada conforme mostrado aqui. Isso é explicado mais adiante.
+ expandir a visualização da fonte simples

1. void spi_slave_init (spi_slave_interface &spi_if)
2. {
5. int clk_start;
6. set_clock_on (spi_if.blk);
7. configure_clock_src (spi_if.blk, spi_if.sclk);
8. configure_in_port (spi_if.mosi, spi_if.blk);
9. configure_out_port (spi_if.miso, spi_if.blk, 0);
10. start_clock (spi_if.blk);
17. retornar;
18. }

Conforme mencionado na postagem da Parte 1, o I / O pode ser sincronizado dentro e fora do dispositivo XMOS em momentos precisos. No código acima, a função set_clock_on (definida no arquivo de cabeçalho XMOS xs1.h) é usada para ativar um dos mecanismos de clock embutidos no chip XMOS. O diagrama abaixo (do documento Introdução às portas XS1) mostra esse mecanismo em amarelo. A função configure_clock_src é usada para selecionar um relógio externo (mostrado em azul no diagrama). Ele será conectado ao pino SCLK no Raspberry Pi. As funções configure_in_port e configure_out_port são usadas para vincular portas ao mecanismo de clock. Os sinais MOSI e MISO (mostrados em verde abaixo) são configurados para serem vinculados ao mecanismo de relógio.

A forma como os dados seriais são tratados em dispositivos XMOS é realmente legal. O código aqui é explicado mais abaixo. Primeiro, uma estrutura é usada para conter detalhes sobre as portas que devem ser usadas como interface SPI.
+ expandir a visualização da fonte simples

1. typedef struct spi_slave_interface
2. {
3. relógio preto;
4. na porta ss;
5. na porta com buffer:8 mosi;
6. saída da porta com buffer:8 miso;
7. na porta sclk;
8. } spi_slave_interface;

As linhas interessantes acima são aquelas que se referem às variáveis ​​de porta mosi e miso. Eles foram declarados como porta do tipo:8. Se as variáveis ​​forem atribuídas a endereços de porta de 1 bit, o dispositivo XMOS irá desserializar automaticamente o fluxo de bits de 1 fio em valores de 8 bits.

Isso torna o resto do código SPI muito simples. Aqui está o código que gerencia a entrada de dados SPI do Raspberry Pi:
+ expandir a visualização da fonte simples

1. void spi_slave_in_buffer (spi_slave_interface &spi_if, unsigned char buffer [], int num_bytes)
2. {
3. dados internos não assinados;
4. sem sinal int vlen =0;
7. clearbuf (spi_if.miso);
8. clearbuf (spi_if.mosi);
11. para (int i =0; i
12. {
13. spi_if.mosi:> dados;
14. dados =dados <<24;
15. buffer [i] =bitrev (dados);
16. if (i ==2)
17. {
18. vlen =(((unsigned int) buffer [1]) <<8) | (int sem sinal) buffer [2];
19. if (vlen ==0)
20. pausa;
21. }
22. if (i> =vlen + 2)
23. {
24. pausa;
25. }
26. }
27. }

No código acima, você pode ver que existe um loop for e dentro do loop a linha spi_if.mosi:> data; é usado para ler 8 bits de informação na linha MOSI na variável chamada dados.

As próximas duas linhas são usadas para inverter os bits dentro do byte e, em seguida, os dados são armazenados em uma matriz de buffer.

As próximas linhas precisam de alguma explicação; eles estão relacionados ao protocolo desejado. A intenção era criar algum código de uso geral que pudesse ser usado para muitas coisas, não apenas para XMP-1. Se o Raspberry Pi enviar dados para a placa XMOS startKIT, a placa XMOS precisará saber quantos bytes de dados esperar. Isso poderia ser codificado, mas seria inflexível.

Foi decidido usar um protocolo muito simples de "tag (ou tipo), comprimento, valor" (TLV). O primeiro byte que o Raspberry Pi deve transmitir é uma etiqueta ou identificador no intervalo 0-255 (ou seja, um byte). Cabe ao usuário decidir o que os valores representam. Por exemplo, um valor de 1 pode significar “definir a velocidade do motor” e um valor de 2 pode significar “definir a intensidade do brilho do farol”. Os segundos dois bytes são um valor de 16 bits que indica quantos bytes de valor (ou seja, dados) devem se seguir. Decidi limitar isso a 4kbyte (4096 bytes), o que deve atender a muitos casos de uso, mas o valor real pode ser alterado ajustando uma definição BUFLEN no código.

Portanto, o número mínimo de bytes enviados na interface SPI são três (tag e um comprimento de 0x0000) e o máximo é 4099 que é uma tag e um comprimento de 0x1000 (isto é 4096 em hexadecimal) e 4096 bytes de dados.

O protocolo foi ligeiramente refinado, de modo que um número de etiqueta ímpar significa que o Raspberry Pi espera uma resposta na seguinte comunicação SPI que ele inicia após o fluxo TLV atual ser concluído, e um número de etiqueta par significa que o Raspberry Pi não espera resposta costas.

Este é um protocolo muito básico, mas deve atender a muitos requisitos usuais. Também é explicado na tabela abaixo, onde o número azul é o índice de bytes SPI no buffer de recebimento de 4099 bytes.

Voltando ao trecho de código anterior, pode-se ver que as próximas linhas verificam o conteúdo do buffer [1] e do buffer [2] em tempo real enquanto os dados SPI estão sendo recebidos. O conteúdo deve ter o comprimento conforme visto no diagrama acima (consulte o índice de buffer azul). Assim que o código determinar o comprimento do restante, ele aceitará exatamente esse número de bytes de dados e, em seguida, a rotina será encerrada.

Isso cobre a entrada SPI para a placa XMOS na linha MOSI. A saída SPI do dispositivo XMOS na linha MISO opera de maneira semelhante, verificando o comprimento simultaneamente na linha MOSI novamente em tempo real, para que a função possa sair assim que o número de bytes solicitado for transferido.

Comunicação entre processos

Agora que o SPI foi descoberto e um protocolo foi implementado para trocar dados de comprimento variável em qualquer direção de até 4096 bytes, alguma consideração foi dada ao corpo principal do programa. Ficou claro que um núcleo XMOS seria dedicado a lidar com a tarefa SPI, mas o resto do código pode precisar residir em um ou mais escores XMO adicionais.

Na parte 1, foi descrito como as tarefas são executadas em paralelo em diferentes núcleos XMOS e como as tarefas podem se comunicar umas com as outras empurrando valores para os canais. Existe outra forma de comunicação entre os núcleos e usa o conceito de “transações por meio de interfaces” em vez de canais. É mais flexível porque você pode enviar várias variáveis ​​de diferentes tipos de um núcleo XMOS para outro. Os tipos de transação são definidos como um protótipo de função C. Tudo isso fica muito mais claro ao olharmos para um exemplo.

Por exemplo, se um aplicativo tinha uma tarefa que controlava uma tela, então uma tarefa de envio pode querer ligar ou desligar a tela, ou pode querer plotar um pixel. A definição da interface para a comunicação entre os dois núcleos XMOS pode ser parecida com esta:
+ expandir a visualização da fonte simples

1. exibição do programa de interface
2. {
3. sem luz de fundo (estado interno, cor interna); // tipo de transação 1
4. gráfico vazio (int x, int y, int color); // tipo de transação 2
5. };

A comunicação da interface é unidirecional, portanto, se a tela quiser enviar informações como (digamos) o estado da tela sensível ao toque, outra interface precisará ser usada na outra direção. A partir disso, fica claro que as interfaces têm uma extremidade cliente e servidor. O diagrama aqui mostra dois núcleos XMOS (em roxo), duas interfaces (em cinza) e a primeira interface (chamada program_display) permite que dois tipos diferentes de transações ocorram (em azul) na interface program_display.

A grande vantagem de usar interfaces e tipos de transação é que, assim como os protótipos de função C, você pode ter valores de retorno e pode passar referências a variáveis, de modo que, embora a comunicação seja sempre iniciada pelo cliente final da interface, a transferência de dados pode ocorrer nos dois sentidos. Outro recurso muito interessante não mostrado no diagrama é a capacidade do servidor enviar uma "notificação" ao cliente. Isso pode ser um sinal para o cliente emitir uma transação da maneira usual, talvez para recuperar alguns dados. Este recurso será usado no código XMP-1. Portanto, mais informações sobre como exatamente codificar as interfaces e enviar dados e notificações serão explicadas mais abaixo.

Projetando a arquitetura IPC para lidar com o conteúdo SPI

O tratamento da interface SPI já foi descrito. Agora, o conteúdo das mensagens SPI precisa ser apresentado a uma tarefa de maneira útil para o processamento subsequente. Munido do conhecimento sobre interfaces e transações, foi possível começar a alocar funcionalidade para separar núcleos XMOS e projetar a comunicação entre processos para chegar a uma estrutura de propósito geral que permitiria o envio de conteúdo de mensagem útil do RPI para o XMOS placa e vice-versa, e ser processada.

O diagrama aqui mostra o que foi desenvolvido (um diagrama semelhante ao anterior, exceto que agora há uma seqüência de tempo de cima para baixo).

Quando o Raspberry Pi deseja enviar uma mensagem para a placa XMOS, o RPI construirá a mensagem no formato TLV descrito anteriormente. A informação é então cronometrada no fio de sinal MOSI (mostrado em verde no topo do diagrama acima). Simultaneamente, o dispositivo XMOS precisa enviar algo de volta, mas como ainda não há informações para enviar de volta, a linha MISO pode conter lixo ou todos os valores zero conforme mostrado em rosa. A função spi_process coletará a mensagem em um buffer (uma matriz de caracteres não assinados) e, em seguida, iniciará uma transação para um núcleo XMOS data_handler separado. O data_handler é responsável por processar o conteúdo da mensagem e, opcionalmente, enviar informações de volta ao núcleo spi_process XMOS, de modo que qualquer troca de SPI subsequente possa enviar dados úteis de volta ao Raspberry Pi em vez de valores de lixo.

Os dados podem ser enviados entre spi_process e data_handler fazendo uma cópia do buffer. No entanto, em vez disso, é possível apenas passar um ponteiro para a memória buffer. Uma maneira de fazer isso é ‘mover’ o controle do ponteiro e dos locais de memória do buffer de spi_process para data_handler. Depois que data_handler é concluído com a inspeção de mensagem, ele pode mover o controle de volta para spi_process usando a variável de retorno que é possível usar em transações. É por isso que o diagrama acima tem uma transação chamada array_data com um parâmetro definido como um ponteiro móvel e um valor de retorno definido também como um ponteiro móvel. Dessa forma, apenas um núcleo XMOS tem acesso à memória buffer por vez.

Estas são as interfaces que são usadas:
+ expandir a visualização da fonte simples

1. interface para_rpi
2. {
3. código vazio (unsigned char c);
4. };
7. interface from_rpi
8. {
9. unsigned char * movable array_data (unsigned char * movable bufp);
10. };

O código spi_handler aloca espaço para um buffer e, em seguida, passa o controle do buffer para o código data_handler usando a linha buf =c.array_data (move (buf)) mostrada no código aqui:
+ expandir a visualização da fonte simples

1. vazio
2. spi_process (interface to_rpi server s, interface from_rpi client c)
3. {
4. armazenamento de caracteres não assinados [4099];
5. unsigned char * movable buf =storage;
6. …
7. buf =c.array_data (mover (buf));
8. …
9. selecione
10. {
11. case s.code (unsigned char c):
12. if (c ==ENVIAR)
13. {
14. spi_slave_out_buffer (spi_sif, buf, 4099);
15. }
16. pausa;
17. }
18. }

O código data_handler obtém o controle do buffer e, em seguida, se desejar que qualquer resposta seja enviada ao RPI em uma transação SPI subsequente, o buffer é preenchido com uma resposta. Finalmente, o controle do buffer é passado de volta para o processo spi_handler.
+ expandir a visualização da fonte simples

1. vazio
2. data_handler (interface para cliente c_rpi, interface do servidor_rpi)
3. {
4. selecione
5. {
6. case s.array_data (unsigned char * movable vp) -> unsigned char * movable vq:
7. // vq contém os dados do SPI. Podemos fazer o que quisermos com ele aqui.
8. // Qualquer resposta é construída aqui também:
9. vq [0] =0x22; // tag
10. vq [1] =0x00; // comprimento
11. vq [2] =0x00; // comprimento
12. vq =mover (vp); // passe o controle do ponteiro de volta para spi_process
13. tosend =1;
14. pausa;
15. }
16. se (enviar)
17. {
18. c.code (ENVIAR); // envie um código para spi_process para que saiba que há dados para enviar ao RPI
19. }
20. }

Anteriormente, foi mencionado que se um valor ímpar de tag fosse enviado pelo RPI, isso seria uma indicação de que o RPI esperava uma mensagem de resposta da placa XMOS startKIT na troca de SPI subsequente. This is implemented by both the spi_process and data_handler making a note that a return message is expected if the first byte received is an odd value. Once data_handler has finished constructing the return message in the buffer memory it moves the buffer pointer back to the spi_process XMOS core and also sends a code transaction which could contain a message such as “ready to send”. The spi_process XMOS core is now ready for any subsequent SPI exchange. If the data_process doesn’t want to send any message back to the Raspberry Pi (for example if the tag was even valued) then the code transaction is not sent (or a different code could be sent such as “not ready to send”).

In the graphic diagram earlier you can see that the subsequent SPI exchange did transmit data back to the Raspberry Pi on the MISO wire.

To summarize, the spi_process and data_process present a fairly general-purpose capability to exchange data bidirectionally between the RPI and XMOS board.

Implementing PWM (servo_handler) on the startKIT

To test out the general purpose architecture, it was decided to use it to control many devices. The devices ended up being hobby servos because they require very little electrical interfacing effort – no H-bridge or transistor driver is needed – and the servo input wire can be directly connected to an XMOS output pin. I didn’t have many servos, so although the code implements 8 servo control, only two were used for XMP-1.

The code could be modified to provide DC motor control too (with a suitable external H-bridge circuit).

It was decided to use a single XMOS core to handle the eight servos. The diagram below shows the total of three XMOS processes used in the solution. The new addition is the servo_handler task which is shown on the right. This task has an array that stores the current servo values. As soon as the task starts up, the values are initialized to a centered value (or standstill for a continuous rotation servo) and then every microsecond the task wakes up to check if the servo PWM signal needs adjustment.  If it does then the servo port output is toggled. After 20msec the process repeats.



For more detail:XMOS startKIT Building an XMOS and Raspberry Pi Robot XMP-1