CENTRO PAULA SOUZA FACULDADE DE TECNOLOGIA …fatecsantoandre.edu.br/arquivos/TCC470.pdf · CENTRO PAULA SOUZA FACULDADE DE TECNOLOGIA DE SANTO ANDRÉ Tecnologia em Eletrônica Automotiva

CENTRO PAULA SOUZA FACULDADE DE TECNOLOGIA

FATEC SANTO ANDRÉ

Tecnologia em Eletrônica Automotiva

FERNANDA WIGNER

Controle de ECM utilizando PIC24 e Free RTOS

Santo André – São Paulo 2016

CENTRO PAULA SOUZA FACULDADE DE TECNOLOGIA

DE SANTO ANDRÉ

Tecnologia em Eletrônica Automotiva

FERNANDA WIGNER

Controle de ECM utilizando PIC24 e Free RTOS

Monografia apresentada ao Curso de Tecnologia em Eletrônica Automotiva da FATEC Santo André, como requisito parcial para conclusão do curso em Tecnologia em Eletrônica Automotiva. Orientador: Prof. Msc. Murilo Zanini de Carvalho.

Santo André – São Paulo 2016

Wigner, Fernanda Controle de ECM utilizando PIC 24 e FreeRTOS / Fernanda Wigner – Santo André, 2016. nº folhas: 102 il.54

Trabalho de conclusão de curso – Fatec Santo André, Curso de Eletrônica Automotiva, 2016.

Orientador: Murilo Zanini de Carvalho.

1. Free RTOS. 2. Injeção eletrônica. 3. RTOS.

AGRADECIMENTOS

Gostaria de agradecer à todos os professores, colegas e funcionários da instituição FATEC Santo André pela ajuda, apoio e confiança, em especial ao meu mestre orientador Murilo Zanini de Carvalho e à comunidade open source interessada no assunto.

“Toda grande caminhada começa com um simples passo.” Buda

RESUMO Este trabalho de conclusão de curso propõe a construção de um protótipo que simula o funcionamento básico de uma ECM (Engine Control Module - Módulo de Controle do Motor), agregando à um microcontrolador PIC 24, alguns elementos básicos para o funcionamento de uma injeção eletrônica, como por exemplo, um sensor de TPS (Throttle Position Sensor – Sensor de Posição da Borboleta), sensor que mede a demanda de aceleração pelo motorista e um sinal de saída que aciona o bico injetor de combustível, além de outros elementos complementares, já o software de gerenciamento embarcado no protótipo é escrito com conceitos de RTOS (Real Time Operating System – Sistema Operacional de Tempo Real), utilizando o FreeRTOS. O protótipo proposto possui um caráter experimental, pois ao final do trabalho foi realizada uma análise do desempenho deste conjunto perante outro protótipo, também básico que já fora utilizado ao longo deste curso de tecnologia para outros projetos. O hardware já utilizado no curso possui um PIC18 e software do tipo firmware on bare metal. Esta análise verificou o comportamento dos pulsos de injeção gerados entre o primeiro e segundo hardware via osciloscópio, verificou também o tempo de execução de cada um dos algoritmos nos respectivos sistemas embarcados e apresentou seus resultados em forma de tabelas comparativas. Palavras chaves: FreeRTOS. Injeção Eletrônica. RTOS.

ABSTRACT

This work proposes the constructing a prototype simulating a ECU basic operation, adding to a PIC microcontroller 24, some basic elements for the operation of an electronic injection, as a TPS sensor (sensor which measures the demand for acceleration by the driver) and output signal to the nozzle fuel, and other complementary elements, also the management software embedded in the prototype and written with concepts of RTOS, Real Time Operating System using the FreeRTOS. It has an experimental character, because at the end there will be a performance analysis of this set towards other hardware prototype, also basic, and already used by this technology course for others projects that use PIC 18 and a bare metal firmware. This analysis will verify the behavior of the injection pulses between the first and second set by oscilloscope. Keywords: FreeRTOS. electronic injection, RTOS.

LISTA DE ILUSTRAÇÕES

Figura 1 - Pesquisa sobre o mercado de trabalho brasileiro de

desenvolvimento de sistemas embarcados 2015, quanto ao microcontrolador

utilizado. Fonte: adaptado de www.embarcados.com.br, 2015. .......................... 22

Figura 2 - Pesquisa sobre o mercado de trabalho brasileiro de

desenvolvimento de sistemas embarcados 2015, quanto ao sistema

operacional utilizado. Fonte: adaptado de www.embarcados.com.br, 2015. ..... 23

Figura 3 - Diagrama de blocos do envio dos sinais de TPS, PIP e Temperatura

para o Kit PIC 18 e Kit PIC 24 e medição dos sinais de injeção. Fonte:

elaborado pela autora. ............................................................................................ 25

Figura 4 - Sistema mecânico de injeção de combustível K-Jetronic da Bosh,

1973. Fonte: extraído do livro Motores de Combustão Interna Vol.1, Brunetti,

2012. ......................................................................................................................... 27

Figura 5 - Distribuidor de combustível, regulador de pressão primário e o

sensor de massa de ar do sistema K-Jetronic system. Fonte: adaptado da

instrução técnica do sistema K-Jetronic da Bosh, 1974...................................... 28

Figura 6 - Esquema funcional de um sistema analógico de injeção eletrônica.

Fonte: extraído do manual técnico da injeção Le-Jetronic da Bosh, 1995. ....... 30

Figura 7 - Sensor de palheta de fluxo e de temperatura do ar. Fonte: extraído

do livro Motores de Combustão Interna Vol.1, Brunetti, 2012. ............................ 31

Figura 8 – Interior da ECM analógica do sistema Le-Jetronic da Bosh. Fonte:

adaptado da internet, http://produto.mercadolivre.com.br/MLB-710858107-

modulo-de-injeco-bosch-kadet-gsi-le-jetronic-reparaco-_JM, acesso em

01/12/2016. ............................................................................................................... 32

Figura 9 - Esquema funcional de um sistema digital de injeção eletrônica.

Fonte: Manual Técnico da Injeção LH-Jetronic da Bosh ..................................... 33

Figura 10 - Funcionamento do sensor MAF. Fonte: adaptado de MTE Thomson,

1995. ......................................................................................................................... 34

Figura 11 - Esquema funcional do microcontrolador Siemens 80535. Fonte:

adaptado do datasheet, 1995. ............................................................................... 35

Figura 12 – ECM digital da Bosh que equipa os motores do veículo S40 da

Volvo. Fonte: adaptado da internet,

http://forums.swedespeed.com/showthread.php?215698-ECU-Hacking!, acesso

em 01/12/2016 .......................................................................................................... 36

Figura 13 – O TPS detecta posição da borboleta fechada – 0V. Fonte: adaptado

de MTE Thomson, 2014........................................................................................... 37

Figura 14 - O TPS detecta posição da borboleta aberta – 5V. Fonte: adaptado

de MTE Thomson, 2014........................................................................................... 37

Figura 15 – Camadas de software localização do firmware. Fonte: adaptado de

http://slideplayer.com.br/slide/2264943/ ................................................................ 40

Figura 16 - Camadas de software do Kit PIC 24. Fonte: elaborado pela autora. 40

Figura 17 – Restrição temporal mais tolerante. Fonte: elaborado pela autora. . 41

Figura 18 – Restrição temporal mais rígida. Fonte: elaborado pela autora. ...... 41

Figura 19 - Dinâmica de funcionamento das tarefas em um sistema

multitasking. Fonte: adaptado de

www.freertos.org/implementation/a00004.html .................................................... 42

Figura 20 - Técnica de programação chamada de super-loop. Fonte: Sergio

Prado, treinamento de FreeRTOS, 2015. .............................................................. 43

Figura 21 - Desvantagem do Super-Loop. Fonte: Sergio Prado, treinamento de

FreeRTOS, 2015. ...................................................................................................... 44

Figura 22 - Camadas de software do Kit PIC 24. Fonte: elaborado pela autora. 45

Figura 23 – Diferença entre Soft e Hard Real Time. Fonte: elaborado pela

autora. ...................................................................................................................... 46

Figura 24 - Típico gerenciamento da stack (pilha) pelo TCB. Fonte: adaptado do

livro Real-Time Systems Design and Analysis, 2012. .......................................... 47

Figura 25 - Transições de estados válidos das tasks no FreeRTOS. Fonte:

http://www.freertos.org/RTOS-task-states.html, acesso em 01/10/2016. ........... 48

Figura 26 – Escalonamento pre-emptive sem time slice. Fonte: Fonte: adaptado

de http://www.embeddedlinux.org.cn/rtconforembsys/5107final/LiB0024.html,

acesso em 01/12/2016. ............................................................................................ 50

Figura 27 - Escalonamento pre-emptive. Fonte: adaptado de

http://www.embeddedlinux.org.cn/rtconforembsys/5107final/LiB0024.html,

acesso em 01/12/2016. ............................................................................................ 50

Figura 28 - Escalonamento cooperativo. Fonte: elaborado pela autora............. 51

Figura 29 – Arquitetura em camadas de um sistema embarcado em tempo real.

Fonte: extraído do livro Real Time Software Design For Embedded Systems,

Gomaa 2016. ............................................................................................................ 52

Figura 30 - Sistema de tempo real embarcado. Fonte: livro Real Time Software

Design For Embedded Systems, 2016. .................................................................. 53

Figura 31 – Adaptação do PIC 24 em placa adaptadora. Fonte: elaborado pela

autora. ...................................................................................................................... 61

Figura 32 - Hardware Kit PIC 24 finalizado em primeiro teste de funcionamento

com aplicação demonstrativa para PIC 24 em FreeRTOS. Fonte: elaborado pela

autora. ...................................................................................................................... 67

Figura 33 - Fonte de 5V utilizando LM7805 para alimentação dos circuitos

geradores de sinais. Fonte: adaptado do datasheet do CI LM7805 da Texas. ... 68

Figura 34 - Circuito gerador do sinal do TPS. Fonte: elaborado pela autora. .... 69

Figura 35 - Circuito gerador do sinal de temperatura. Fonte: adaptado do

datasheet do LM35 da Texas, 2016. ....................................................................... 70

Figura 36 - Circuito gerador do sinal de PIP. Fonte: adaptado do datasheet do

CI 555 da Texas, 2015 . ........................................................................................... 71

Figura 37 – Gerador de sinais completo. TPS, Temperatura e PIP. Fonte:

elaborado pela autora. ............................................................................................ 72

Figura 38 – Fonte de 6V utilizando o LM317 para alimentação do circuito

condicionador dos sinais analógicos. Fonte: extraído do datasheet do CI

LM317 da Texas, 2015. ............................................................................................ 73

Figura 39 - Circuito condicionador do sinal do TPS. Fonte: adaptado do circuito

da ECU do Gol, Prof. Edson, 2014. ........................................................................ 74

Figura 40 - Circuito condicionador do sinal de temperatura. Fonte: adaptado do

circuito da ECU do Gol, Prof. Edson, 2014. .......................................................... 75

Figura 41 – Circuito condicionador do sinal do PIP. Fonte: adaptado do circuito

da ECU para o Gol, Prof. Edson, 2014. .................................................................. 76

Figura 42 – ............................................................................................................... 77

Figura 43 – Hardware finalizado ainda sem softwares finais. Fonte: elaborado

pela autora. .............................................................................................................. 78

Figura 44 – Estrutura de arquivos do FreeRTOS do projeto demo para

PIC24FJ128GA110, carregados. Fonte: adaptado de MPLAB X IDE v.3.20. ....... 80

Figura 45 – Arquivos do kernel que não necessitam de modificação. Fonte:

extraído do ambiente de desenvolvimento do MPLAB X IDE v.3.20. .................. 81

Figura 52 - Arquivos criados especificamente para a aplicação. Fonte: extraído

do ambiente de desenvolvimento do MPLAB X IDE v.3.20.Erro! Indicador não

definido.

Figura 51 - ....................................................................... Erro! Indicador não definido.

Figura 46 – Queue criada e sem elementos. Fonte: Using The FreeRTOS Real

Time Kernel: A Pratical Guide PIC32, 2010. ................. Erro! Indicador não definido.

Figura 47 – Envio de elemento para queue. Fonte: Using The FreeRTOS Real


Figura 48 - Envio de elemento para queue. Fonte: Using The FreeRTOS Real


Figura 49 – Recebimento de elemento via queue. Fonte: Using The FreeRTOS

Real Time Kernel: A Pratical Guide PIC32, 2010. ......... Erro! Indicador não definido.

Figura 50 – Reposicionamento de elemento na queue. Fonte: Using The

FreeRTOS Real Time Kernel: A Pratical Guide PIC32, 2010.Erro! Indicador não

definido.

Figura 53 – adaptado de http://www.freertos.org/a00110.htmlErro! Indicador não

definido.

LISTA DE TABELAS

Tabela 1 – Comparação entre PICs - recursos básicos e tensão de alimentação

.................................................................................................................................. 56

Tabela 2 - Definição das funções dos pinos ......................................................... 58

LISTA DE ABREVIATURAS

A/C Ar/Combustível;

A/D Analógico/Digital;

API Application Programming Interface - Interface de Programação

de Aplicação;

ARM Advanced Risc Machine – Tipo de arquitetura de processador

de 32 bits;

CAN Controller Area Network – Tipo de protocolo de comunicação

serial;

ºC Graus Celsius;

CI Circuito Integrado;

CO Monóxido de carbono;

CO2 Dióxido de Carbono;

CONAMA Conselho Nacional do Meio Ambiente;

CPU Central Processing Unit – Unidade Central de Processamento;

ECM Engine Control Module (Módulo de Controle do Motor);

EFI Electronic Fuel Injection – Injeção Eletrônica de Combustível;

Firmware On Bare Metal Expressão que significa ser programado direto no metal, sem

sistema operacional de base;

FreeRTOS Sistema Operacional de tempo Real de código aberto utilizado

no projeto;

GND Ground – Terra. Potencial de zero Volt em circuitos elétricos e

eletrônicos;

HC Hidrocarboneto(s);

Hz Hertz;

kB Quilobytes;

kHz Quilohertz;

LCD Liquid Crystal Display – Display de Cristal Liquido;

LED Light Emitting Diode – Diodo Emissor de Luz;

MAF Mass Air Flow – Fluxo de Massa de Ar;

MCI Motor de Combustão Interna;

PIC 24/18 Interface de Controle Programável;

PIP Profile Ignition Pickup – Perfil de Captação de Ignição

PLL Phase-Locked Loop;

MHz Megahertz;

Ms Milisegundo(s);

mV Milivolt(s);

NOx Óxido(s) Nitroso(s);

O2 Oxigênio;

RPM Rotações Por Minuto;

RTOS Real Time Operating System – Sistema Operacional de Tempo

Real;

RusEFI Projeto open source de injeção eletrônica de combustível;

TPS Throttle Position Sensor - Sensor de Posição da Borboleta;

TQFP Thin Quad Flat Package - Encapsulamento Quadrado Plano;

µC Microcontrolador;

µs Microsegundo(s);

USART Universal Synchronous Asynchronous Receiver Transmitter –

Tipo de protocolo de comunicação serial;

USB Universal Serial Bus;

V Volts;

Sumário

1 INTRODUÇÃO ....................................................................................................... 20

1.1 Motivação ......................................................................................................... 21

1.2 Objetivos .......................................................................................................... 24

1.3 Organização do Trabalho ................................................................................. 25

2 BREVE HISTÓRICO DOS SISTEMAS DE INJEÇÃO DE COMBUSTÍVEL EM UM

MCI ............................................................................................................................ 26

2.1 Sistema mecânico de injeção de combustível ................................................. 26

2.2 Classificações dos sistemas de injeção eletrônica........................................... 29

2.2.1 Sistema de injeção de combustível eletrônico analógico ........................... 29

2.2.2 Sistema de injeção de combustível eletrônico digital ................................. 33

3 SISTEMA OPERACIONAL, FIRMWARE, SISTEMA DE TEMPO REAL E

SISTEMA OPERACIONAL DE TEMPO REAL ......................................................... 38

3.1 Sistema Operacional (SO) ............................................................................... 38

3.2 Firmware on bare metal ................................................................................... 39

3.3 Sistema de Tempo Real ................................................................................... 41

3.4 Sistema Operacional de Tempo Real (RTOS) ................................................. 44

3.4.2 O escalonador de tarefas de um RTOS ..................................................... 49

3.4.3 RTOS para embarcados ............................................................................ 52

4 METODOLOGIA .................................................................................................... 55

4.1 Projeto do hardware Kit PIC 24 ........................................................................ 55

4.1.1 Análise e escolha do µC ............................................................................ 55

4.1.3 Definição das funções dos pinos ............................................................... 57

4.1.4 Acomodação do PIC utilizando placa adaptadora ..................................... 60

4.1.5 Requisitos mínimos para funcionamento do µC ........................................ 61

4.1.5.1 Fonte de Alimentação de 3.3.V ............................................................... 61

4.1.5.2 Capacitores de desacoplamento, tensão do núcleo do µC e MCRL ....... 62

4.1.5.3 Oscilador externo .................................................................................... 63

4.1.5.4 LCD 16x2 ................................................................................................ 65

4.1.5.5 LEDS e botão.......................................................................................... 65

4.1.5.6 Resultado da montagem do Kit PIC 24 e teste inicial ............................. 66

4.1.6 Projeto do gerador de sinais para o Kit PIC 24 e Kit PIC 18 ...................... 67

4.1.6.1 Fonte de 5V ............................................................................................ 68

4.1.6.2 TPS ......................................................................................................... 68

4.1.6.3 Temperatura ........................................................................................... 69

4.1.6.4 PIP .......................................................................................................... 70

4.1.6.5 Resultado da montagem do gerador de sinais ....................................... 71

4.1.7 Projeto do condicionador de sinais para o Kit PIC 24 e Kit PIC 18 ............ 72

4.1.7.1 Fonte de 6V ............................................................................................ 72

4.1.7.2 Condicionador do circuito do TPS ........................................................... 73

4.1.7.3 Condicionador do circuito da temperatura .............................................. 74

4.1.7.4 Condicionador do circuito do PIP ............................................................ 75

4.1.8 Resultado da montagem do condicionador de sinais................................. 77

4.1.9 Resultado do hardware completo .............................................................. 77

4.2 Modelagem do software de injeção eletrônica em FreeRTOS para o Kit PIC 24

............................................................................................................................... 79

4.2.1 Estrutura básica do FreeRTOS .................................................................. 80

4.2.2 Grupo de arquivos que formam o kernel .................................................... 81

4.2.3 Configurando heap de memória ................................................................ 82

4.2.4 Grupo de arquivos que formam a aplicação de EFI ................................... 83

4.2.5 A criação de tasks ...................................................................................... 84

4.2.6 Utilizando as queues .................................................................................. 85

4.2.7 Semáforos ................................................................................................. 87

4.2.8 Customização do FreeRTOS ..................................................................... 88

4.2.9 Configuração dos periféricos ..................................................................... 90

5 GRAVAÇÃO FINAL DOS SOFTWARES E ANÁLISE DE RESULTADOS ........... 91

6 CONCLUSÃO ...................................................................................................... 100

7 PROPOSTAS FUTURAS ..................................................................................... 101

8 REFERÊNCIAS .................................................................................................... 102

APÊNDICE A – Fluxograma da Função Principal elaborada em FreeRTOS .... 104

APÊNDICE B – Fluxograma da task Define RPM elaborada em FreeRTOS ... 105

APÊNDICE C – Fluxograma da task DefineTinj elaborada em FreeRTOS ...... 107

APÊNDICE D – Fluxograma da task ADTPS elaborada em FreeRTOS .......... 110

APÊNDICE E – Fluxograma do Timer 2 elaborada em FreeRTOS .................. 112

APÊNDICE F – Fluxograma da task vLCDTask do FreeRTOS ........................ 113

ANEXO A – Esquema elétrico do Kit PIC 18 .................................................... 114

20

1 INTRODUÇÃO

O automóvel e outros meios de locomoção que utilizam um MCI sempre

acompanharam o desenvolvimento da humanidade e suas tecnologias. Com o

surgimento da necessidade de economia de combustíveis derivados de petróleo e

atualmente com exigências ambientais cada vez mais restritivas, o controle

eletrônico da injeção de combustível em um MCI é uma solução bem eficaz

encontrada pela indústria automobilística, se não for a única. Para atender a essas

necessidades foi necessário o aprimoramento dos modelos de injeção puramente

mecânicos, utilizados desde 1925 (BRUNETTI, 2012), passando pelos modelos

analógicos para hoje se chegar aos os modelos de gerenciamento digital, que são

largamente utilizados.

Graças ao desenvolvimento da indústria eletrônica e o seu barateamento as

indústrias automotivas começaram a realizar pesquisas e projetos agregando maior

quantidade de componentes eletrônicos, (BRUNETTI, 2012) já que, alguns

componentes mecânicos começaram a apresentar limitações construtivas e de

funcionamento no desenvolvimento de projetos mais modernos.

O sistema de injeção eletrônica digital possui grandes vantagens sobre um

sistema de injeção eletrônica analógica, ambos possuem uma ECM, porém as

diferenças vão desde a forma de transdução dos sensores do motor, tratamento das

informações dentro da ECM e velocidade de transmissão dos dados entre sensores,

módulo e atuadores, como os bicos injetores ou velas de ignição no caso de motores

a álcool ou a gasolina (ciclo Otto).

A relação estequiométrica ideal, ou seja, a reação de queima completa de

uma molécula de combustível, gasolina (C8H18), etanol (C2H6O) ou diesel (C14H30)

com o O2, deve resultar apenas em CO2 e água. Ademais quaisquer outros

componentes resultantes são tóxicos e poluentes. Hoje se sabe que quanto mais

uma molécula de combustível se aproxima da atomização as chances de ser

totalmente consumida pela reação aumentam.

Entende-se que um sistema como esse deve funcionar da forma confiável,

com certo grau de precisão e robustez, pois poderá ser solicitado por várias horas e

um sistema de injeção eletrônica atual faz uso de softwares estratégicos para atingir

isso.

21

Um RTOS possui algoritmos já programados os quais trabalham para que um

sistema que funcione com restrições temporais possa atuar de forma eficiente

mesmo que esse sistema trabalhe dinamicamente, como por exemplo, a

instrumentação de um avião que informa ao piloto dados de altitude a todo instante,

esses dados podem variar, pois reagem ao meio físico, ou mesmo uma ECM que

atende a diversas solicitações de aceleração ou desaceleração de um motorista e

cujo software de gerenciamento deve ler, medir e informar os dados em tempo hábil

para cálculo e atuação com as devidas regularidades. Portanto um RTOS não

precisa ser necessariamente um sistema controlador rápido, mas sim interagir com o

meio envolvente a tempo.

Existem muitas técnicas bem estabelecidas para escrever um software bem

incorporado sem o uso de um kernel (núcleo), e se o sistema que está sendo

desenvolvido é simples, técnicas comuns podem proporcionar uma solução mais

adequada. Em casos mais complexos, é provável que o uso de um kernel seja

preferível, mas onde o ponto de cruzamento entre o uso de um kernel ou um

firmware sempre será subjetivo. (www.freertos.org, 2016).

1.1 Motivação

Três motivos principais serviram como fonte de inspiração para esse trabalho.

Em primeiro lugar, seguir a tendência de mercado no desenvolvimento de softwares

para dispositivos embarcados. Já é comum o uso de RTOS para controle de

diversos dispositivos embarcados que possuem tarefas com restrições temporais

explícitas, como por exemplo, uma ECM. Um bom exemplo disso é a RusEFI, que

consiste de uma ECM construída com um microcontrolador ARM e com sistema de

gerenciamento escrito com o auxílio de um RTOS, o ChibiOS. Esse projeto é open

source, o significa que se pode copiá-lo, modificá-lo e distribuí-lo sem a necessidade

de se pagar royalties (direitos autorais) podendo ser usado em aplicações

comerciais.

Em segundo lugar, a familiaridade que adquiri ao longo do curso com os

microcontroladores PIC, o conhecimento de sua programação e sua arquitetura

22

possibilitou a escolha do PIC 24FJ256GB106 com o FreeRTOS, já que ambos são

compatíveis.

Em terceiro e último lugar a abrangência social que esse projeto pode

alcançar na atualidade, pois, segundo uma pesquisa do site

www.embarcados.com.br realizada entre os meses de setembro e outubro de 2015,

entrevistando 835 profissionais com conhecimentos amplos na área mostra que,

63% dos entrevistados já possuíam experiência com chips da fabricante Microchip,

conforme ilustra a figura 1 elaborada pela pesquisa.

Figura 1 - Pesquisa sobre o mercado de trabalho brasileiro de desenvolvimento de sistemas

embarcados 2015, quanto ao microcontrolador utilizado. Fonte: adaptado de

www.embarcados.com.br, 2015.

23

A pesquisa também revelou que 31% dos entrevistados possuíam experiência

com o FreeRTOS, como mostra a figura 2, também elaborada pela pesquisa.

Figura 2 - Pesquisa sobre o mercado de trabalho brasileiro de desenvolvimento de sistemas

embarcados 2015, quanto ao sistema operacional utilizado. Fonte: adaptado de

www.embarcados.com.br, 2015.

Além disso, 30% dos entrevistados trabalham ou já trabalharam com

embarcados para o setor industrial, 21% no setor automotivo e com 20%, na

automação residencial.

24

1.2 Objetivos

O objetivo deste trabalho é desenvolver um hardware que simule uma ECM

para veículos de ciclo Otto. Essa ECM, do tipo protótipo, utilizará o PIC 24 como o

núcleo de processamento e terá como sinais de entrada um potenciômetro que

simula o TPS, um sensor de temperatura do ambiente e um gerador de onda

quadrada para simular o efeito Hall de um distribuidor de ignição, o PIP ou mais

modernamente, o sinal da roda fônica. Além disso, o hardware também possuirá um

LCD para visualização de algumas informações referente ao processo, LEDS

indicativos e um botão comum, esses últimos elementos servem para incrementar o

software já que outro hardware, que utiliza o PIC 18 e servirá para comparação ao

final do projeto, também os possui. O software de gerenciamento desse sistema

será escrito em FreeRTOS e o do PIC 18 será um firmware on bare metal.

Com os dois hardwares funcionando, Kit PIC 24 e Kit PIC 18, ambos

receberão simultaneamente os sinais de entrada: PIP, sensor de temperatura e TPS,

gerando os pulsos de injeção com seus respectivos softwares em saídas específicas

de cada Kit. Esses pulsos de injeção serão captados em entradas distintas de um

mesmo osciloscópio e serão analisados.

A figura 3 é um diagrama de blocos que ilustra como será a distribuição dos

sinais paras os Kits e a captura dos sinais de injeção pelo osciloscópio.

25

Figura 3 - Diagrama de blocos do envio dos sinais de TPS, PIP e Temperatura para o Kit PIC 18

e Kit PIC 24 e medição dos sinais de injeção. Fonte: elaborado pela autora.

1.3 Organização do Trabalho

O capitulo 2 discorrerá sobre um breve histórico acerca do funcionamento das

injeções mecânica, eletrônica analógica e digital em um MCI de ciclo Otto, mas o

assunto de carburadores não será abordado.

O capítulo 3 discorrerá sobre os conceitos de sistema operacional, firmware e

RTOS.

O capítulo 4 abordará o processo de construção da ECM, Kit PIC 24, alguns

testes iniciais de funcionamento além da construção do gerador e do condicionador

de sinais que alimentam as ECMs, Kit PIC 24 e Kit PIC 18, além de aprofundar o

assunto de RTOS na criação do software de injeção utilizando a API do FreeRTOS.

No capítulo 5 será realizada a programação dos softwares e a análise dos

resultados.

No capítulo 6 a conclusão, e finalmente no capítulo 7 as propostas futuras.

26

2 BREVE HISTÓRICO DOS SISTEMAS DE INJEÇÃO DE

COMBUSTÍVEL EM UM MCI

O sistema de injeção eletrônica atual é uma evolução do sistema de injeção

analógica, e que por sua vez, é uma evolução do sistema mecânico de injeção de

combustível.

Os sistemas atuais se valem do desenvolvimento e da redução de custos

pelos quais passou a indústria da eletrônica (BRUNETTI, 2012), além da atual

obrigatoriedade de emitirem menos gases tóxicos na atmosfera.

Motores de ciclo Otto, que funcionam com álcool, gasolina ou ambos

possuem pequenas diferenças comparadas aos motores de ciclo Diesel em seus

sistemas de injeção, sendo que os primeiros necessitam de ar, combustível e

centelha para iniciar seu funcionamento, com uma taxa de compressão que varia

entre 8:1 a 11:1. Os de ciclo Diesel não necessitam de centelha e sua taxa de

compressão é mais alta, podendo variar de 16:1 a 24:1. Também possuem

diferenças construtivas em seus injetores e outros elementos construtivos, mas

ambos necessitam de correta quantidade de combustível injetado e no momento

correto.

Nesse breve histórico, os sistemas não serão analisados quanto ao seu tipo

de combustível, mas se são mecânicos, analógicos ou digitais. O leitor conseguirá

identificar o tipo de combustível devido a presença ou não da vela de ignição nas

figuras, embora isso não seja relevante.

Ao final entenderá basicamente, como é possível determinar a massa de

combustível em cada sistema no momento da injeção.

2.1 Sistema mecânico de injeção de combustível

O sistema de injeção mecânico de combustível, já utilizado em aviões desde

1925, passou a ser utilizado, com bombas em linha em veículos de competição, a

27

partir de 1950 (BRUNETTI, 2012). A figura 1 mostra um exemplo desse sistema, o

K-Jetronic da Bosh, produzido em série a partir de 1973, com os seguintes

componentes: 1. Injetor de combustível; 2. Coletor de admissão; 3. Regulador de ar

adicional; 4. Regulador de partida a frio; 5. Sensor de temperatura do motor-NTC; 6.

Distribuidor de ignição; 7. Injetor suplementar; 8. Borboleta de aceleração; 9.

Parafuso de regulagem da marcha lenta; 10. Regulagem de mistura; 11. Chave de

ignição, 12. Relé de comando; 13. Bomba de combustível, 14. Acumulador de

combustível; 15. Filtro de combustível e 16. Tanque de combustível

Figura 4 - Sistema mecânico de injeção de combustível K-Jetronic da Bosh, 1973. Fonte:

extraído do livro Motores de Combustão Interna Vol.1, Brunetti, 2012.

28

A figura 5 mostra o distribuidor de combustível mais detalhadamente, que é o

componente responsável pelo envio do combustível aos os bicos injetores presentes

no sistema.

Figura 5 - Distribuidor de combustível, regulador de pressão primário e o sensor de massa de

ar do sistema K-Jetronic system. Fonte: adaptado da instrução técnica do sistema K-Jetronic

da Bosh, 1974.

O sistema funciona da seguinte forma: a posição da placa do sensor depende

da quantidade de ar aspirado pelo motor, essa posição é transmitida para o êmbolo

de controle por meio de uma alavanca, dependendo da posição do êmbolo de

controle permite-se a passagem de maior ou menor quantidade de combustível que

fluirá pelos canais (A) até os bicos injetores, item (1) da figura 3.

Esse tipo de sistema embora possua alguns elementos elétricos essenciais

para seu funcionamento como; a bomba de combustível (13), relé de comando (12)

e o distribuidor de ignição (6) não possui uma ECM para gerenciamento e a injeção

29

de combustível é contínua e também não possui loop de correção de combustível

em malha fechada, causando desperdício de combustível.

2.2 Classificações dos sistemas de injeção eletrônica

Os sistemas de injeção eletrônica de combustível podem ser classificados de

várias maneiras, inclusive quanto a sua tecnologia, podendo ser analógicos ou

digitais, que como mencionado anteriormente possuem diferenças na forma de

aquisição, tratamento e transmissão dos sinais de entrada e saída.

No contexto nacional, a Resolução Nº 18 do CONAMA, de 6 de maio de 1986,

que trata dos limites emissões de gases tóxicos, ajudou a expandir o uso e

aprimoramento da injeção eletrônica.

2.2.1 Sistema de injeção de combustível eletrônico analógico

O primeiro sistema de injeção eletrônica lançado no Brasil foi o Le-Jetronic da

Bosh, é um sistema que possui um módulo eletrônico, porém o seu funcionamento é

analógico, esse sistema equipava, por exemplo, o Gol GTi o primeiro carro nacional

com injeção eletrônica lançado no final do ano de 1988 e o Santana GLSi de 1990,

entre outros veículos.

A figura 2 ilustra esse sistema e identifica os seguintes componentes: 1.

Tanque de combustível; 2. Bomba elétrica de combustível; 3. Filtro de combustível;

4. Tubo distribuidor; 5. Regulador de pressão; 6. Unidade de comando do motor; 7.

Válvula injetora; 8. Parafuso de marcha lenta; 9. Sensor da válvula de aceleração;

10. Válvula de aceleração; 11. Sensor de fluxo e temperatura do ar; 12. Relé do

comando; 13. Sensor de temperatura do motor; 14. Válvula auxiliar do condicionador

de ar; 15. Válvula auxiliar de ar; 16. Parafuso de CO; 17. Bateria; 18. Chave de

ignição; 19. Válvula diafragma; 20. Bobina.

30

Figura 6 - Esquema funcional de um sistema analógico de injeção eletrônica. Fonte: extraído

do manual técnico da injeção Le-Jetronic da Bosh, 1995.

No módulo de controle analógico do motor (item 6 - ECM) existem diversos

relés, resistores, e comparadores entre outros componentes eletrônicos básicos, que

calibrados corretamente, criam a lógica eletrônica necessária para combinar os

dados de entrada: volume de ar aspirado, pressão e temperatura ambiente, para

acionar um único atuador, o bico injetor.

A figura 6 ilustra melhor os elementos internos principais que compõem o

sensor de fluxo e temperatura do ar, elemento chave desse sistema.

31

Figura 7 - Sensor de palheta de fluxo e de temperatura do ar. Fonte: extraído do livro Motores

de Combustão Interna Vol.1, Brunetti, 2012.

O funcionamento básico do sensor de fluxo de ar consiste na mensuração da

força que emana da corrente de ar aspirado pelo motor por meio de palhetas, esta

força deve ser suficiente para neutralizar a força oposta aplicada por uma mola pré-

calibrada e presa ao eixo de rotação do conjunto de palhetas A e B, tendendo a

fechar a passagem de ar. Uma espécie de potenciômetro que consiste num contato

metálico com um eixo de rotação solidário ao conjunto, gira sobre uma pista resistiva

e mensura o valor de volume de ar em tensão e o enviando-o à ECM.

Como esse sensor é volumétrico o sistema possui também um sensor de

pressão ambiente e de temperatura para a determinação da vazão do ar em massa

(BRUNETTI, 2012).

Para prevenir oscilações no sistema de admissão, causadas pela própria

admissão, uma aba de compensação está ligado rigidamente à aba do sensor. As

32

oscilações de pressão têm os mesmos efeitos sobre ambas às palhetas e os

momentos de força anulam-se mutuamente para que a medição não seja afetada.

Como os dados desse sistema são puramente analógicos qualquer mau

contato, gripagem etc. acarretam em uma leitura errônea do comportamento dos

sensores e atuação equivocada nos atuadores, nesse caso, os bicos injetores.

Essa geração da Le-Jetronic ainda não trabalha em malha fechada com

sonda lambda para o correto cálculo estequiométrico e correção de combustível

injetado e nem possui diagnóstico embarcado. A figura 8 mostra o interior da ECM

analógica do sistema Le-Jetronic.

Figura 8 – Interior da ECM analógica do sistema Le-Jetronic da Bosh. Fonte: adaptado da

internet, http://produto.mercadolivre.com.br/MLB-710858107-modulo-de-injeco-bosch-kadet-

gsi-le-jetronic-reparaco-_JM, acesso em 01/12/2016.

33

2.2.2 Sistema de injeção de combustível eletrônico digital

O sistema de injeção eletrônica digital é o mais utilizado atualmente,

facilitando inclusive a manutenção. Do mesmo fabricante dos sistemas anteriores, o

LH-Jetronic (1982) é um exemplo de injeção eletrônica digital. Em umas das suas

primeiras versões possuía microcontroladores com 4 kB a 32 kB de memória de

programa e com correção de combustível em malha fechada por sonda lambda

(sensor de O2). A figura 7 ilustra esse sistema de injeção.

Figura 9 - Esquema funcional de um sistema digital de injeção eletrônica. Fonte: Manual

Técnico da Injeção LH-Jetronic da Bosh

34

Nesse sistema há a substituição do sensor de palheta de fluxo e temperatura

do ar pelo sensor MAF. Esse sensor, embora mais moderno, também funciona de

forma analógica, trata-se de um fio de platina aquecido por uma resistência que ficas

exposta ao fluxo de ar que trafega pelo coletor de admissão, uma corrente elétrica é

responsável por compensar o resfriamento do fio mantendo a temperatura de

equilíbrio. Um valor de tensão que corresponde a essa corrente elétrica é enviado ao

conversor A/D de um microcontrolador e posteriormente à sua CPU em formato

digital participando do cálculo da massa de combustível necessária.

Figura 10 - Funcionamento do sensor MAF. Fonte: adaptado de MTE Thomson, 1995.

O sinal da sonda lambda, instalada no coletor de escapamento, faz com que a

ECM, se necessário, realize as correções de massa de combustível a cada ciclo de

funcionamento do motor para atingir a correta relação estequiométrica. Essa

funcionalidade apresenta vantagens quanto à exatidão de massa de combustível

injetada para uma reação de queima mais completa, além de possibilitar a utilização

de diferentes tipos de combustíveis, a exemplo dos motores flex. (BRUNETTI, 2012).

35

Com a utilização de um µC, foi possível carregar sua memória de programa

ROM (Ready Only Memory – Memória Somente de Leitura) com mapas de injeção

de combustível pré-elaborados que são matrizes de dados combinados, cujas

variáveis recebem novos parâmetros a todo instante por meio dos sensores

preenchendo esse mapa e atuando no motor para atender às mudanças de regime

do veículo.

A figura 10 apresenta um diagrama de blocos que ilustra as funcionalidades

de uns dos primeiros microcontroladores utilizados na ECM da LH-Jetronic, o 80535

da fabricante Siemens.

Figura 11 - Esquema funcional do microcontrolador Siemens 80535. Fonte: adaptado do

datasheet, 1995.

No Brasil, a Resolução nº18, de 1º de janeiro de 1997, determina que no ano

de 2008, 11 anos após a sua criação, o limite de emissão de CO deveria reduzir-se

em doze vezes, passando de 24,0 gramas por quilômetro para 2,0 gramas por

quilômetro, reduzir em quatro vezes o índice de CO em marcha lenta, passando de

3,0% para 0,5%, além do HC não queimado, de 2,1 gramas para 0,3 gramas e do

NOx, reduzindo a emissão de 2,0 para 0,6 gramas por quilômetro.

A solução encontrada para o cumprimento dessas determinações em médio

prazo foi iniciar o investimento em projetos que agregassem o sistema eletrônico

digital de gerenciamento, como o já adotado em países mais desenvolvidos. A

36

programação tornou-se uma peça importantíssima na construção de veículos com

MCI, inclusive Diesel, pois foi possível equacionar inúmeros dados físicos e atingir

as metas impostas.

As ECMs modernas agregam uma grande evolução tecnológica e maior

quantidade de programação. Além dos dados típicos de entrada diversos outros

dados de comportamento do sistema são realimentados e analisados em conjunto.

O sistema responde acionando diversos atuadores e informando variáveis para

diversos outros módulos, por exemplo, parâmetros para a TCM (Transmission

Control Module - Módulo de Controle da Transmissão). Além disso, também exigem

uma alta demanda do processador, pois executam na faixa de milhões de cálculos

por segundo, além disso, os dados trafegam em formato digital pela moderna rede

CAN estabelecendo a comunicação entre os módulos.

A figura 11 mostra o interior da ECM de um veículo da Volvo de 1995, o S40,

um modelo importado.

Figura 12 – ECM digital da Bosh que equipa os motores do veículo S40 da Volvo. Fonte:

adaptado da internet, http://forums.swedespeed.com/showthread.php?215698-ECU-Hacking!,

acesso em 01/12/2016

37

Além disso, os componentes sensores também tiveram que evoluir, hoje os

automóveis trabalham com um corpo de borboleta associado a um TPS que

mensura a posição angular do eixo da borboleta, sendo, totalmente fechada 0 V e

totalmente aberta 5 V. A ECM utiliza esse sinal para identificar as condições das

mudanças de regime do motor e se houver aceleração atua no bico injetor

aumentando o tempo de injeção de combustível enriquecendo a mistura A/C. Para

regimes de desaceleração a ECM diminui a injeção de combustível evitando o

desperdício. As figuras 13 e 14 ilustram o funcionamento básico do TPS.

Figura 13 – O TPS detecta posição da borboleta fechada – 0V. Fonte: adaptado de MTE

Thomson, 2014.

Figura 14 - O TPS detecta posição da borboleta aberta – 5V. Fonte: adaptado de MTE Thomson,

2014.

38

3 SISTEMA OPERACIONAL, FIRMWARE, SISTEMA DE TEMPO REAL E SISTEMA OPERACIONAL DE TEMPO REAL

Como mencionado anteriormente, houve a necessidade do setor

automobilístico de se adequar as novas regras de emissão de poluentes. Utilizando

a eletrônica digital para obter sucesso nos novos projetos a fabricação dos softwares

que controlam as ECMs também se modernizou.

Atualmente é possível encontrar, desde softwares mais simples, os chamados

firmwares até sistemas operacionais de tempo real, executando tarefas que atendem

a diferentes níveis de confiabilidade e robustez.

3.1 Sistema Operacional (SO)

“O sistema operacional é uma camada de software colocada entre o hardware

e os aplicativos, aqueles programas que fazem as tarefas dos usuários do

computador” (Oliveira, 2010).

“É um software básico de qualquer computador, pois fornece ao usuário uma

interface conveniente e, ao mesmo tempo, gerencia o hardware, controlando de

forma ordenada e eficiente o acesso ao processador, memória e dispositivos de

entrada e saída pelos aplicativos que os disputam” (Pinto Neto, 2014).

No contexto da computação um SO é projetado para receber um estímulo (ou

evento), que pode ser interno ou externo, realizar o processamento e produzir uma

saída (Sérgio Prado, 2015), nas duas primeiras definições é possível notar a estreita

relação entre um sistema operacional e um computador multitarefas, no caso um

hardware com periféricos como monitor, teclado e mouse.

Sistemas operacionais como Linux, por exemplo, possuem um kernel de

processamento e controle que permite que um usuário ou vários executem vários

programas, aparentemente de forma simultânea, o sistema operacional ou também

chamado de operativo tem por funções abrigar o kernel, os aplicativos, realizar a

39

gestão geral dos recursos do hardware e principalmente servir de interface entre o

computador e o usuário.

3.2 Firmware on bare metal

O termo firmware on bare metal significa que no hardware não há uma

camada de sistema operacional, é um software semipermanente podendo ou não

ser atualizado com frequência, servindo geralmente para o funcionamento básico do

embarcado, como por exemplo, um teclado de computador ou uma impressora.

Geralmente o sistema de gerenciamento de um embarcado é uma espécie de

firmware multitasking (software permanente multitarefa).

A figura 15 mostra a estrutura das camadas de software existente em um

computador convencional e uma impressora, de baixo para cima, o hardware,

essencial em ambos, é responsável por abrigar todos os softwares, em seguida vem

o firmware, no computador ele é responsável por ligar o computador BIOS (Basic I/O

System – Sistema Básico de Entradas e Saídas) e na impressora ele abriga o

controlador (driver) que é responsável por torná-la reconhecível ao computador.

Além disso, no computador ainda existem o kernel, que é o componente central

dentro de um sistema operacional que cria uma interface de comunicação entre o

hardware e o software (www.freertos.org, 2016), e os aplicativos, que executam as

tarefas com interface do usuário.

Já a figura 16 ilustra a camada de software que roda no Kit PIC 18, composto

de um firmware como no exemplo da impressora, porém funciona com interação

com o meio externo, que é realizada através dos sinais enviados pelos sensores, por

se tratar de uma ECM.

40

Figura 15 – Camadas de software localização do firmware. Fonte: adaptado de

http://slideplayer.com.br/slide/2264943/

Figura 16 - Camadas de software do Kit PIC 24. Fonte: elaborado pela autora.

41

3.3 Sistema de Tempo Real

Sistemas que trabalham com eventos que possuem restrições de tempo são

chamados de “Sistemas de Tempo Real” e também são sistemas operacionais

multitasking (multitarefa). Essas restrições impõem limites de tempo entre o estímulo

ser processado e gerar a saída correspondente. (Sérgio Prado, 2015). A essa

capacidade dá-se o nome de determinismo, isso não significa que o sistema tenha

que ser rápido, mas deve agir tempo, cumprindo os prazos. Essa é uma

característica fundamental em um sistema de tempo real.

As figuras 17 e 18 exemplificam de forma didática a diferença entre as

restrições de tempo e a reação adequada exigida do piloto em cada sistema.

Figura 17 – Restrição temporal mais tolerante. Fonte: elaborado pela autora.

Figura 18 – Restrição temporal mais rígida. Fonte: elaborado pela autora.

42

Sistemas de tempo real são complexos, pois lidam com múltiplos eventos de

entrada e devem produzir várias saídas, normalmente os sistemas embarcados em

microcontroladores são multitasking, pois realizam mais que uma atividade de

controle ou monitoramento no caso de microcontroladores com apenas um núcleo

de processamento. Nesses processadores é realizado um chaveamento entre as

tarefas (tasks) para que todas tenham acesso ao processador, executando uma

tarefa de cada vez. Se um sistema operacional pode executar vários programas ou

tarefas de forma aparentemente simultânea, é considerado um sistema multitasking

(www.freertos.org, 2016).

A figura 19 ilustra como o chaveamento entre as tasks é realizado causando

essa impressão de simultaneidade.

Figura 19 - Dinâmica de funcionamento das tarefas em um sistema multitasking. Fonte:

adaptado de www.freertos.org/implementation/a00004.html

Sistemas multitasking de baixa complexidade são desenvolvidos como

sistemas foreground/background (primeiro plano/segundo plano). A aplicação

consiste em um loop (laço) infinito que chama algumas funções para realizar as

43

operações desejadas (background) sendo que as rotinas de tratamentos de

interrupções tratam eventos assíncronos (foreground) (Sérgio Prado, 2015).

A figura 20 mostra como é feita a programação descrita acima, sendo uma

ótima solução para projetos pequenos e com requisitos modestos de restrição de

tempo, sendo de fácil implementação.

Figura 20 - Técnica de programação chamada de super-loop. Fonte: Sergio Prado, treinamento

de FreeRTOS, 2015.

A desvantagem desse sistema, chamado de super-loop (super-laço), é que

todo o código em background tem a mesma prioridade e se uma das funções

demorar mais do que o esperado, todo o sistema será impactado. A figura 21 ilustra

essa desvantagem criada por meio da programação.

44

Figura 21 - Desvantagem do Super-Loop. Fonte: Sergio Prado, treinamento de FreeRTOS,

2015.

Sistemas foreground/background são, de fato, as arquiteturas mais comuns

para aplicações embarcadas, mas, qualquer alteração em determinada parte do

código pode impactar no tempo de resposta de todo o sistema e por isso pode ser

difícil de manter o código com múltiplos desenvolvedores.

3.4 Sistema Operacional de Tempo Real (RTOS)

Um RTOS pode ser uma solução em projetos de maior porte com sistemas

que possuem restrições de tempo e não podem admitir deficiências, a exemplo do

super-loop. Um RTOS é capaz de responder aos eventos de maneira previsível

dentro do calendário de restrições especificadas mesmo havendo alterações no

código, exceto algumas alterações na configuração de sua API.

Sistemas Operacionais de Tempo Real são construídos utilizando um kernel

de tempo real; um software responsável por gerenciar o tempo, os recursos da CPU,

o uso da memória, a comunicação entre as tarefas e interrupções, além de gerenciar

o acesso aos recursos da aplicação (hardware, estruturas de dados etc) e promover

outras funcionalidades (timers, tracing etc) (Sérgio Prado, curso 2015).

45

Para esse projeto a estrutura de software da ECM construída não possui uma

camada de firmware e sim um Sistema Operacional de Tempo Real. A figura 22

ilustra a estrutura das camadas de software do Kit PIC 24,

Figura 22 - Camadas de software do Kit PIC 24. Fonte: elaborado pela autora.

Aqui o hardware é gerenciado por um RTOS sendo seu kernel também de

tempo real. O sistema operacional fornecerá as aplicações, que são na verdade

tarefas (tasks), programadas especificamente para criar um sistema de injeção

eletrônica básico da ECM. Os detalhes de funcionamento do RTOS utilizado nesse

projeto serão descritos com maiores detalhes na secção 4.2.

Quanto às restrições de tempo de um RTOS, podem ser classificado como

Soft Real-Time; quando há maior tolerância quanto às restrições de tempo e quando

não atingida não inutiliza o sistema, não gera consequências catastróficas ou

quando há apenas a percepção de baixa qualidade do sistema, por exemplo, um

sistema baseado na internet ou uma comunicação simples entre pessoas, e Hard

Real-time; quando as restrições de tempo precisam ser atingidas, caso contrário,

ocorrem consequências catastróficas ou o sistema é inutilizado, como por exemplo,

uma parada de emergência de um comboio sem condutor frente a um obstáculo

46

(Hassan Gomaa, 2016). O termo comumente utilizado para definir esse atendimento

de prazos é deadline (data limite). A figura 23 ilustra didaticamente os conceitos

Soft Real Time e Hard Real Time.

Figura 23 – Diferença entre Soft e Hard Real Time. Fonte: elaborado pela autora.

Baseado no conceito de prioridades e tasks, as funcionalidades de um

sistema escrito em RTOS devem ser divididas em tarefas e a cada uma delas dada

uma prioridade, ficando sob a responsabilidade do desenvolvedor a decisão de

como isso será feito (Sérgio Prado, curso 2015). As tarefas devem ser bem definidas

e o contexto de cada uma deve ser objetivo.

O termo context switching, é o nome dado à mudança de contexto entre as

tarefas sendo que o kernel é responsável por salvar todas as informações ou

contexto (stack - pilha, registradores da CPU etc) referentes a cada tarefa que se

encontra em execução quando essa mudança de contexto ocorre. O contexto é

administrado por uma estrutura chamada de TCB (Task Control Block – Bloco de

Controle de Tarefa). Quando ocorre a mudança de contexto a tarefa em execução é

interrompida, os registadores do processador são salvos na memória e os mesmos

registradores são atualizados com os dados da próxima tarefa e então a nova tarefa

entra em execução; esse processo se repete continuamente. A figura 24 ilustra o

gerenciamento da stack de uma task pelo TCB.

47

Figura 24 - Típico gerenciamento da stack (pilha) pelo TCB. Fonte: adaptado do livro Real-Time Systems Design and Analysis, 2012.

O sistema operacional gerencia os TCBS, mantendo o controle do estado de

cada tarefa. Normalmente, uma tarefa pode estar em qualquer um dos seguintes

estados:

1. Executing or Running (Executando): é a task em andamento, em um

processador de apenas um núcleo pode haver apenas uma tarefa em

andamento de cada vez. No caso do FreeRTOS quando a tarefa é

completada ela retorna para o estado suspenso ou boqueado (blocked).

2. Ready (Pronto): tasks nesse estado estão prontas para executar, mas não

estão em andamento, pois uma tarefa diferente de igual ou maior

prioridade já está em estado de execução.

3. Blocked (Bloqueado): tasks que estão a espera de qualquer evento

externo ou temporal. Por exemplo, se uma tarefa chama vTaskDelay( ) ela

irá bloquear (será colocada em blocked state) até que o período de atraso

(delay) seja expirado. As tarefas também podem bloquear por esperar por

filas, semáforos, grupo de eventos, notificação ou evento semáforo. Tasks

48

em estado blocked normalmente tem um período de timeout (tempo

esgotado).

4. Suspended (Suspenso): Como as tarefas que estão em blocked state

tarefas que estão em suspended state não podem ser selecionadas para

entrar em running e não possuem timeout, em vez disso, elas só entram

ou saem do estado suspenso quando lhes é ordenado explicitamente fazê-

lo através do vTaskSuspend ( ) e xTaskResume ( ).

5. Dormant (Latente): esse estado é usado somente em sistemas que o

número de TCBS é fixo. Uma task nesse estado é mais bem definida

como uma tarefa que existe, mas não está no momento, disponível para

agendamento. (LAPLANTE; OVASKA, 2012).

No FreeRTOS as tarefa transitam pelos estados chamando para a execução

funções específicas contidas no kernel, como mostra a figura 25.

Figura 25 - Transições de estados válidos das tasks no FreeRTOS. Fonte: http://www.freertos.org/RTOS-task-states.html, acesso em 01/10/2016.

49

O context switching é ativado de diferentes maneiras, uma tarefa pode

bloquear esperando um recurso estar disponível, uma tarefa pode dormir por um

tempo ou ainda ser suspensa involuntariamente pelo kernel.

Utilizando um RTOS a programação é orientada à eventos evitando as rotinas

de pooling; técnica de programação que consiste em ficar perguntando

constantemente para a variável, por meio de um laço if ou while, se o valor dela já

chegou no valor desejado, tomando 100% do tempo de um processador e gerando

desperdício de CPU. Além disso, melhora a modularidade e manutenção do sistema

e reuso de código, já que as aplicações são definidas em tarefas, facilita os testes,

pelo fato de que cada tarefa é uma entidade independente e também o

desenvolvimento em equipes com múltiplos desenvolvedores.

3.4.2 O escalonador de tarefas de um RTOS

A API de um RTOS é uma espécie de biblioteca que possui um conjunto de

rotinas, protocolos e ferramentas padrões do RTOS, tornando a programação de um

RTOS, no nível de aplicação, mais fácil.

A principal rotina de um kernel de tempo real é o escalonador de tarefas

(scheduler), e em uma aplicação com diversas tasks em um microcontrolador de

apenas um core (núcleo) o scheduler é o responsável por decidir qual a próxima

tarefa que será executada. Essa rotina entra em ação durante o context switching.

No caso do FreeRTOS, o scheduler pode funcionar de forma pre-emptive sem

time slice (de preferência sem fatia de tempo), pre-emptive (de preferência) ou

cooperative (coperativo), a configuração do escalonador pode ser realizada por meio

da sua API de configuração no módulo customização.

A figura 26 ilustra o funcionamento do escalonamento pre-emptive, que

consiste basicamente em atribuir graus de prioridades diferentes a cada task, sendo

que a task de maior prioridade será executada primeiro. Nesse tipo de

escalonamento se a task de maior prioridade estiver pronta para a execução o

kernel salvará imediatamente todo o contexto da task em execução, e irá colocar em

execução uma task de maior prioridade (LI; YAO, 2003). A vantagem mais clara é a

50

possibilidade de priorizar tarefas para garantir que as restrições de tempo da

aplicação sejam atendidas.

Figura 26 – Escalonamento pre-emptive sem time slice. Fonte: Fonte: adaptado de http://www.embeddedlinux.org.cn/rtconforembsys/5107final/LiB0024.html, acesso em 01/12/2016.

O escalonamento pre-emptive concede prioridades diferentes e o mesmo time

slice para todas as tarefas com prioridades que podem ser diferentes. A figura 27

ilustra esse tipo de escalonamento

Figura 27 - Escalonamento pre-emptive. Fonte: adaptado de http://www.embeddedlinux.org.cn/rtconforembsys/5107final/LiB0024.html, acesso em 01/12/2016.

51

No escalonamento cooperativo todas as tasks possuem uma mesma

prioridade e não há uma definição de tempo para elas, o context switching ocorre

somente quando a tarefa que está rodando utilizar comandos do processador que

indique qual a task deverá ser executada em seguida. A figura 28 ilustra esse tipo de

escalonamento.

Figura 28 - Escalonamento cooperativo. Fonte: elaborado pela autora.

Outras políticas de escalonamento:

FIFO: (First-in, First-out - Primeiro a entrar, Primeiro a sair) ou (First-Come,

First-Served - Primeiro a chegar, Primeiro a ser servido): algoritmo de

escalonamento de fila simples, onde o primeiro elemento a ser retirado é o

primeiro elemento que foi inserido.

Round-robin: consiste em atribuir frações de tempo em partes iguais para

cada task sem estabelecer prioridades manipulando todas as tasks. Muitos

sistemas operacionais de tempo real usam uma política de escalonamento

Round-Robin, porque é simples e previsível, porém, é de interesse descrever

algoritmos de escalonamento mais populares de forma mais rigorosa.

(Laplante, Ovaska, 2012).

52

3.4.3 RTOS para embarcados

Um sistema embarcado em tempo real é um sistema de computador em

tempo real (hardware e software) que faz parte de um sistema maior (chamado

sistema em tempo real ou sistema cibernético) que normalmente tem peças

mecânicas e / ou elétricas, como um avião ou um automóvel. (Gomaa, 2016)

Atualmente a maioria dos embarcados é construída para atender restrições

de tempo, desde fornos de micro-ondas, passando por gravadores de blue-ray até

trens sem condutores e naves espaciais que exploram os confins do universo, essas

máquinas devem receber as ordens em um tempo correto para garantir uma

operação suave e responder às solicitações.

Um sistema de tempo real embarcado pode ser concebido para se ter um

sistema de arquitetura em camadas, como mostra a figura 29, que consiste no

sistema operacional de tempo real, na aplicação em tempo real e o hardware como

plataforma física.

Figura 29 – Arquitetura em camadas de um sistema embarcado em tempo real. Fonte: extraído do livro Real Time Software Design For Embedded Systems, Gomaa 2016.

Os sistemas incorporados em tempo real (tanto centralizados como

distribuídos) possuem aracterísticas que os distinguem de outros sistemas de

software:

53

A) Interação com o ambiente externo: um sistema embarcado de tempo real

interage com um ambiente externo que é em grande parte não humano. Por

exemplo, o sistema em tempo real pode ser o controle de máquinas ou pode estar

monitorando processos químicos e notificando as condições por alarmes.

B) Sensores e atuadores: a interação com o ambiente externo necessita de

sensores para receber dados do ambiente externo e atuadores para saída de dados

para e controlar o ambiente interno/externo, como mostra a figura 30.

C) Tempo de medição: um sistema em tempo real modela a passagem do

tempo do passado através do presente e no futuro. Um evento ocorre em um

instante de tempo (conceito de tempo zero). Uma duração é um intervalo de tempo

entre dois eventos, um evento inicial e um evento final. Um período é uma medida

de intervalos recorrentes da mesma duração.

Figura 30 - Sistema de tempo real embarcado. Fonte: livro Real Time Software Design For

Embedded Systems, 2016.

54

Atualmente para realizar a programação de um RTOS para um embarcado

existem ferramentas acessíveis e eficientes. Um método de projeto de software em

tempo real para sistemas embarcados deve ser capaz de abordar as seguintes

características:

Modelagem estrutural: modelar o domínio do problema, limite total do

hardware e software, componentes de interface entre hardware e software e os

limites do sistema de software.

Modelagem dinâmica (comportamental) - para modelar as sequências de

interação entre sistema e artefatos de software nos requisitos, análise e níveis de

design.

Máquinas de estado - para reagir a eventos externos, conforme determinado

pela entrada e o estado atual do sistema.

Concorrência - para lidar com múltiplas sequências de entrada e cargas

imprevisíveis, modelando atividades que executam em paralelo umas com as outras.

Arquitetura de software baseada em componentes - para fornecer uma

arquitetura consistente de componentes orientados a objetos concorrentes e

conectores, de modo que os componentes possam ser implantados em diferentes

nós em um ambiente distribuído.

Análise de desempenho de projetos em tempo real - analisar o desempenho

em tempo real antes da sua implementação, a fim de determinar rapidamente se o

sistema atingirá seus objetivos de desempenho.

Estes requisitos são todos abordados pelo projeto de software em tempo real

COMET/RTE (Concurrent Object Modeling and Architectural Design Method for

Real-Time Embedded Systems - Simulação Concorrente de Objetos e Método de

Projeto Arquitetural para Sistemas Embarcados em Tempo Real) (Gomaa,2016).

55

4 METODOLOGIA

Neste capítulo serão detalhadas as etapas de construção dos hardwares Kit

PIC 24, gerador e do condicionador de sinais, a programação FreeRTOS para o Kit

PIC 24 as finalizações construtivas, algumas adaptações no já existente firmware de

injeção eletrônica do Kit PIC 18 e sua programação final.

4.1 Projeto do hardware Kit PIC 24

A construção do hardware que serve de base ao PIC 24 seguiu quatro etapas

principais: escolha do microcontrolador, confecção dos esquemas elétricos,

montagem e testes.

4.1.1 Análise e escolha do µC

Para a escolha do microcontrolador foi necessário consultar a documentação

básica do FreeRTOS disponível no site, nela há uma listagem de µCs compatíveis

com o sistema, onde o PIC 24 está incluído. Optou-se pelo PIC 24 pelos seguintes

motivos:

Disponibilidade do PIC 24 no mercado a preço acessível.

Documentação com os detalhes de montagem da placa de desenvolvimento,

Explorer 16, comercializado pela fabricante Microchip, o qual utiliza um PIC

24FJ128GA010.

Para iniciar o estudo dessa portabilidade e o desenho definitivo do esquema

elétrico do Kit PIC24 foram combinados os esquemas elétricos da Explorer 16 e os

esquemas elétricos disponíveis no datasheet do PIC 24FJ256GB106. Após a análise

dos dois esquemas e das especificações foi montada uma tabela comparativa a fim

56

de determinar as principais características de cada um dos µCs e a portabilidade,

como mostra a tabela 1.

Tabela 1 – Comparação entre PICs - recursos básicos e tensão de alimentação

Fonte: Adaptado do site da Microchip, 2016

Analisando a tabela 1 constatou-se uma grande semelhança de recursos entre

os dois microcontroladores. Uma das preocupações era a quantidade de memória

de programa disponível, a EPROM (Erasable Programmable Ready Only Memory -

Memória Apagável e Programável Somente para Leitura) que é o local de

armazenamento do código feito em FreeRTOS, porém o PIC 24FJ256GB106 possui

uma memória de 256 kB, o que é mais do que suficiente para abrigar o código, só o

kernel ocupa aproximadamente 4 kB. Também era necessário que houvesse no

mínimo uma interrupção para ser utilizada como entrada do sinal PIP e no mínimo

duas entradas analógicas para os sinais temperatura e TPS, o que foi atendido. As

demais diferenças entre os dois modelos de PIC 24 não comprometem o projeto.

Todo esse processo foi necessário, pois o modelo do PIC da Explorer 16 não foi

encontrado para compra.

4.1.2 Diagrama de blocos do hardware

Antes de iniciar o desenho do esquema elétrico e já com o modelo do PIC24 a

ser utilizado definido, o 24FJ256GB106, foi necessário montar um diagrama de

blocos facilitando a visualização de como ficaria o hardware final. A intenção era

Produto

Tensão de

Operação

Mínima (V)

Tensão de

Operação

Máxima (V)

Memória de

Programa

(KB)

Memória

RAM

(Bytes)

Nº

Pinos

Pinos

I/O

Canais

ADC

Interrupção

Externa

Ferramenta de

gravação

PIC Kit 3

PIC24FJ128GA010

(Explorer 16)2 3.6 128 KB 8192 100 85 16 4 Sim

PIC24FJ256GB106

(disponível no mercado)2 3.6 256KB 16384 64 52 16 1 Sim

57

montar um hardware simples que atendesse aos requisitos mínimos de uma injeção

eletrônica.

A figura 15 mostra o diagrama de blocos contendo a alimentação do

microcontrolador, os sensores: PIP, que simula o sinal distribuidor de ignição do

veículo, o TPS, que simula o sinal do acelerador, o sinal do sensor de temperatura

ambiente, um botão (entrada extra) e os atuadores: pulso de injeção de combustível,

LCD e LEDS, além do conector de gravação que utiliza protocolo ICSP (In Circuit

Serial Programing – Circuito de Programação Serial).

Figura 15 – Diagrama de blocos inicial do hardware. Fonte: elaborado pela autora.

4.1.3 Definição das funções dos pinos

Ainda nessa fase foram definidas as funções de cada pino do PIC24 e

embora o chip possua 64 pinos disponíveis foram utilizados somente 35 pinos que

58

atendem a todas as funcionalidades estabelecidas para esse projeto. A tabela 2

mostra quais foram os pinos utilizados com suas respectivas funções.

Tabela 2 - Definição das funções dos pinos

Número

do pino

Nome

do pino

Função

definida

Modo de

trabalho Descrição

HW/SW

1 PMD5/CN63/RE5 RE5 - LCD Saída

Digital Display (D5)

2 SCL3/PMD6/CN64/RE6 RE6 - LCD Saída


3 SDA3/PMD7/CN65/RE7 RE7 - LCD Saída


7 MCLR RESET Entrada

digital

Acionamento

de RESET

por botão

9 VSS GND Terra Terra

10 VDD VCC Alimentação Alimentação

de 3.3V

11 PGEC3/AN5/C1INA/VBUSON/RP18/CN7/RB5 Clock

Gravação E/S Digital

Protocolo

ICSP

12 PGED3/AN4/C1INB/USBOEN/RP28/

CN6/RB4

Dados

Gravação E/S Digital

Protocolo

ICSP

15 PGEC1/AN1/VREF-/RP1/CN3/RB1 AN1 - LM Entrada

Analógica

Leitura da

temperatura

16 PGED1/AN0/VREF+/RP0/PMA6/CN2/RB0 AN0 - TPS Entrada

Analógica

Leitura da

aceleração

17 PGEC2/AN6/RP6/CN24/RB6 RB6 Saída

Digital

LED 0

(amarelo)

18 PGED2/AN7/RP7/RCV/CN25/RB7 RB7 Saída

Digital

LED 1

(amarelo)

19 AVDD VCC

Alimentação Alimentação

de 3.3V

59

20 AVSS GND Terra Terra

21 AN8/RP8/CN26/RB8 RB8 Saída

Digital

LED 2

(amarelo)

22 AN8/RP8/CN26/RB9 RB9 Saiída

Digital

LED 3

(amarelo)

23 TMS/CVREF/AN10/PMA13/CN28/RB10 RB10 Saída

Digital

LED 4

(amarelo)

24 TDO/AN11/PMA12/CN29/RB11 RB11 Saída

Digital

LED 5

(verde)

27 TCK/AN12/PMA11/CTED2/CN30/ RB12 RB12 Saída

Digital

LED 6

(verde)

30 AN15/RP29/REFO/PMA0/CN12/ RB15 RB15 -

LCD

Saída

Digital Display (E)

33 RP16/USBID/CN71/RF3 RF3 -

Botão

Entrada

Digital

Acionamento

de botão

38 VDD VCC Alimentação Alimentação

de 3.3V

39 OSCI/CLKI/CN23/RC12 OSCI Oscilador

externo

Cristal de 8

MHz

40 OSCO/CLKO/CN22/RC15 OSCI Oscilador

externo

Cristal de 8

MHz

41 VSS GND Terra Terra

49 VCPCON/RP24/CN50/RD1 RD1 Saída

Digital

Saída do

pulso de

injeção

52 RP25/PMWR/CN13/RD4 RD4 - LCD Saída

Digital Display (RW)

53 RP20/PMRD/CN14/RD5 RD5 - LCD Saída

Digital Display (RS)

56 VCAP/VDDCORE VDDCORE Alimentação

Alimentação

do núcleo

(2.5V)

57 ENVREG ENVEREG Alimentação Alimentação

do núcleo

60

(2.5V)

60 PMD0/CN58/RE0 LCD Saída










Fonte: adaptado do datasheet, Tabela da descrição da pinagem – família PIC24FJ256GB110.

4.1.4 Acomodação do PIC utilizando placa adaptadora

Como o encapsulamento do PIC 24 adquirido é do tipo TQFP, portanto foi

necessário adquirir uma placa adaptadora a fim de facilitar a sua fixação na chapa

fenolite e a conexão de outros componentes necessários. O resultado da adaptação

e a localização final dos pinos utilizados são mostrados na figura 20.

61

Figura 31 – Adaptação do PIC 24 em placa adaptadora. Fonte: elaborado pela autora.

4.1.5 Requisitos mínimos para funcionamento do µC

Para iniciar o desenho do esquema elétrico do Kit PIC 24 foi necessário

pesquisar sobre as conexões básicas do PIC24FJ256GB106 em seu datasheet,

disponível no site da fabricante Microchip. Desse datasheet foram utilizados o

esquema elétrico dos capacitores de desacoplamento, tensão do núcleo do µC e o

botão de reset do microcontrolador, o pino MCLR.

Já a documentação da Explorer 16 forneceu os esquemas elétricos da fonte

de alimentação de 3.3 V, do oscilador externo e do LCD 16x2.

4.1.5.1 Fonte de Alimentação de 3.3.V

A família do PIC 24 trabalha com fontes de alimentação que podem variar de

2 V a 3.6 V. Para esse projeto foi utilizada uma fonte de 3.3 V construída com o

62

regulador de tensão LM1117. Nesse caso utilizou-se uma fonte comercial com

tensão de saída de 12 V que alimenta o regulador. Os diodos D1 e D2 tem a função

de proteger o circuito contra uma possível tensão reversa, os capacitores C1 e C3

filtram oscilações de alta frequência e juntamente com os capacitores e C2 e C4

(eletrolíticos) fazem o circuito integrado trabalhar de forma estável, a indicação dos

capacitores foi obtida no datasheet do LM1117, o LED D3 é somente uma indicação

de que a fonte está em funcionamento. A figura 16 apresenta o esquema elétrico da

fonte de 3.3 V.

Figura 16 - Fonte de alimentação de 3.3V para microcontroladores família PIC24FJ256GB110

Fonte: adaptado do datasheet da placa de desenvolvimento Explorer 16, 2014.

4.1.5.2 Capacitores de desacoplamento, tensão do núcleo do µC e MCRL

Os capacitores de desacoplamento possuem como função no circuito manter

estável a alimentação do chip, já que em circuitos integrados, o formato digital de

funcionamento, convencionalmente 0-desligado ou 1-ligado, compromete a

alimentação aumentando a demanda energética de uma hora para outra. O

datasheet do PIC determina a utilização de capacitores de desacoplamento (C6-

C10) entre todos os pinos de alimentação do µC (VSS/VDD-AVSS/AVDD) devendo

ficar os mais próximos possíveis dos pinos correspondentes.

63

O PIC 24 necessita de uma alimentação em seu núcleo de 2.5 V que é

proporcionada por um regulador interno ao chip e que pode ser conseguida

inserindo 3.3V no pino ENVREG como informa o datasheet.

Além disso, o circuito do pino MCRL (master-clear), utilizado pelo sistema de

gravação ICSP e pelo RESET do µC não necessitou de um capacitor filtro para

efeito bouncing, que consiste em um mau contato de curta duração decorrente da

construção mecânica da chave/botão, gerando incerteza do estado lógico do sinal

que será lido pelo µC. O esquema elétrico com as conexões citadas pode ser

visualizado na figura 17.

Figura 17 – Conexões básicas recomendadas capacitores de desacoplamento e MCRL. Fonte:

adaptado de Microchip, datasheet PIC24FJ256GB110, 2009.

4.1.5.3 Oscilador externo

Um oscilador serve para determinar o ritmo de andamento e sincronizar a

lógica interna das operações realizadas no microcontrolador. Nesse projeto o PIC 24

64

trabalha com um cristal de quartzo externo de 8 MHz, posicionado a no máximo

12mm dos pinos de conexão juntamente com dois capacitores de carga.

O circuito de clock externo foi escolhido em detrimento ao uso do oscilador

interno RC (resistor/capacitor) que o µC possui que é mais sensível a temperatura,

ou seja, a frequência se altera em função da temperatura. Os cristais possuem

grande estabilidade e precisão na geração de frequências gerando uma frequência

de clock confiável.

O oscilador interno foi configurado para multiplicar a frequência de 8 MHz do

cristal através de um circuito PLL (Phase Lock Loop – Loop de Bloqueio de Fase),

desta forma se obtém uma frequência de trabalho de 32 MHz. Todas as instruções

da CPU são executadas com um ciclo de máquina, 16 MHz (65,5ns), exceto as

instruções de desvio de programa e chamadas de funções. O circuito do oscilador

pode ser visualizado na figura 18.

Figura 18 – Circuito do oscilador externo. Fonte: adaptado do datasheet da placa de

desenvolvimento Explorer 16, 2014.

65

4.1.5.4 LCD 16x2

As conexões do LCD são idênticas as do datasheet da Explorer 16, isso

possibilitou o uso da biblioteca lcd.c, que realiza a inicialização do LCD utilizada no

código demonstração do FreeRTOS com a adição de novas funcionalidades.

Figura 22 – Circuito do LCD, elaborado no Proteus. Fonte: adaptado do datasheet da placa de

desenvolvimento Explorer 16, 2014.

4.1.5.5 LEDS e botão

Como já dito o PIC 24 possui somente 64 pinos ao contrário da Explorer 16

que possui um µC de 100 pinos os LEDS precisaram ser conectados ao port B por

não haver port A. Além disso, foi incluída uma entrada com um resistor de pull-up

onde um botão foi conectado, agregando uma entrada extra para eventuais testes e

funcionalidades no Kit PIC 24. O circuito que contem os LEDS e o botão pode ser


D7

14

D6

13

D5

12

D4

11

D3

10

D2

9D

18

D0

7

E6

RW

5R

S4

VS

S1

VD

D2

VE

E3

DISPLAY LCD

3.3VR

E0

RE

1

RE

2

RE

3

RE

4

RE

5

RE

6

RE

7

RV2

3.3V

RB

15

RD

5

RD4

66

Figura 23 – Circuito dos LEDS e do botão, desenhado no Proteus. Fonte: adaptado do

datasheet da placa de desenvolvimento Explorer 16, 2014.

4.1.5.6 Resultado da montagem do Kit PIC 24 e teste inicial

Após a finalização da montagem do Kit PIC 24 foi realizado um teste de

funcionamento básico utilizando o gravador PIC Kit 3 da fabricante Microchip que

grava toda a família do PIC24. Já o software gravado foi uma aplicação demo

original escrita para PIC 24 na versão 9.0.0 do FreeRTOS, disponibilizada no site do

produto, em conjunto com a IDE MPLABX v.3.20 e compilador XC16 v.1.25

disponibilizados pela Microchip no site da fabricante.

Essa aplicação consiste na criação de quatorze tarefas, cinco co-rotinas e um

teste de interrupção de alta frequência.

O hardware se comportou de maneira esperada obtendo sucesso nesse

primeiro teste. A figura 32 mostra a finalização do Kit PIC 24 em funcionamento com

o software de teste.

RB0/PMA6/CN2/RP0/VREF+/AN0/PGED116

RB1/CN3/RP1/VREF-/AN1/PGEC115

RB2/CN4/RP13/C2INB/AN214

RB3/CN5/C2INA/AN313

RB4/CN6/RP28/C1INB/AN4/PGED312

RB5/CN7/RP18/C1INA/AN5/PGEC311

RB6/CN24/RP6/AN6/PGEC217

RB7/CN25/RP7/AN7/PGED218

RB8/CN26/RP8/AN821

RB9/PMA7/CN27/RP9/AN922

RB10/PMA13/CN28/CVREF/AN10/TMS23

RB11/PMA12/CN29/AN11/TDO24

RB12/PMA11/CN30/CTED2/AN12/TCK27

RB13/PMA10/CN31/CTED1/AN13/TDI28

RB14/PMA1/CN32/RP14/CTPLS/AN1429

RB15/PMA0/CN12/RP29/REFO/AN1530

RC12/CN23/CLKI/OSCI39

RC13/CN1/C3IND/SOSCI47

RC14/CN0/T1CK/RPI37/C3INC/SOSCO48

RC15/CN22/CLKO/OSCO40

RD0/CN49/RP1146

RD1/CN50/RP2449

RD2/CN51/RP2350

RD3/PMBE/CN52/RP2251

RD4/PMWR/CN13/RP2552

RD5/PMRD/CN14/RP2053

RD6/CN15/C3INB54

RD7/CN16/C3INA55

AVDD19

AVSS20

RE0/PMD0/CN5860

RE1/PMD1/CN5961

RE2/PMD2/CN6062

RE3/PMD3/CN6163

RE4/PMD4/CN6264

RE5/PMD5/CN631

RE6/PMD6/CN64/SCL32

RE7/PMD7/CN65/SDA33

RF0/CN6858

RF1/CN6959

RF2/CN70/RP3034

RF3/CN71/RP1633

RF4/PMA9/CN17/RP10/SDA231

RF5/PMA8/CN18/RP17/SCL232

RF6/CN72/INT0/RPI45/ASCK135

RG2/CN83/SCL137

RG3/CN84/SDA136

RG6/PMA5/CN8/RP21/C1IND4

RG7/PMA4/CN9/RP26/C1INC5

RG8/PMA3/CN10/RP19/C2IND6

RG9/PMA2/CN11/RP27/C2INC8

MCLR7

ENVREG57

RD8/CN53/RP2/RTCC42

RD9/CN54/RP443

RD10/PMCS2/CN55/RP344

RD11/PMCS1/CN56/RP1245

VCAP/VDDCORE56

PIC24FJ256GB106

LED 6

LED 5

LED 4

LED 3

LED 2

LED 7

LED 8

R8

R7

R6

R5

R4

R9

R10

3.3V

C13

R10

3.3V

R11

BT0

470R

470R

470R

470R

470R

470R

470R

10K

470R

0.1uF

67

Figura 32 - Hardware Kit PIC 24 finalizado em primeiro teste de funcionamento com aplicação

demonstrativa para PIC 24 em FreeRTOS. Fonte: elaborado pela autora.

4.1.6 Projeto do gerador de sinais para o Kit PIC 24 e Kit PIC 18

Um automóvel comum possui uma grande quantidade de sensores e por isso

mais variáveis que compõem seu software de controle de injeção, como mencionado

anteriormente a ECM construída com o Kit PIC 24 e o Kit PIC 18 receberão uma

quantidade menor de sinais.

68

Foi proposta a construção de um gerador de sinais para simular apenas o

PIP, TPS e a temperatura.

4.1.6.1 Fonte de 5V

Optou-se por construir uma fonte com saída de 5 V para a alimentação dos

circuitos geradores do PIP, sensores de temperatura e TPS em detrimento a

utilização da tensão de 5 V disponibilizada pelo Kit PIC 18. O regulador de tensão

utilizado foi o LM7805 e o seu circuito pode ser visualizado na figura 20.

Figura 33 - Fonte de 5V utilizando LM7805 para alimentação dos circuitos geradores de sinais.

Fonte: adaptado do datasheet do CI LM7805 da Texas.

4.1.6.2 TPS

O sinal do pedal do acelerador informa a porcentagem de abertura da válvula

borboleta, esse sinal é mensurado através do TPS e informa a ECM um valor de

tensão correspondente.

69

Para esse projeto será utilizado um potenciômetro linear de 1 kΩ para simular

o a abertura e fechamento da borboleta de aceleração gerando um valor de tensão

correspondente enviando-o ao Kit PIC 24 e ao Kit PIC 18 simultaneamente. O

resistor de 1 kΩ na saída do sinal serve para atenuar a corrente e proteção caso

ocorra eventual curto circuito no circuito de condicionamento. O esquema elétrico do

circuito do TPS pode ser visualizado na figura 22.

Figura 34 - Circuito gerador do sinal do TPS. Fonte: elaborado pela autora.

4.1.6.3 Temperatura

A temperatura do motor será simulada através de um circuito que utiliza o

LM35, um sensor que mede temperaturas de -55 ºC a 150 ºC com resolução de 10

mV/ºC. Ele será alimentado com 5 V e nesse caso trabalhará sempre com a

temperatura ambiente pois não haverá de fato um motor. O esquema elétrico pode

ser visualizado na figura 35.

1K1K

5V

Saída 5V MÁX.

70

Figura 35 - Circuito gerador do sinal de temperatura. Fonte: adaptado do datasheet do LM35 da Texas, 2016.

4.1.6.4 PIP

O PIP é um sinal utilizado para informar a posição do virabrequim e é uma

referência para a ECM que a partir desse sinal define o momento de injeção de

combustível e informa a velocidade do motor em RPM. Nos automóveis esse sinal

era, anteriormente, produzido pelo distribuidor de ignição com sensor Hall, hoje um

sensor de rotação com roda fônica montada concêntrica a árvore de manivelas é

responsável por converter o sincronismo mecânico do motor em sincronismo

eletrônico para a ECM.

O PIP simulado pelo gerador de sinais foi obtido por um circuito oscilador

utilizando o CI 555 em modo astável. Nesta configuração o circuito gera uma onda

quadrada com duty-cicle (ciclo de trabalho) de aproximadamente 50%, amplitude de

5 V e frequências que podem variar de 14 Hz a 12 kHz em função de um

potenciômetro de 10 kΩ. O esquema elétrico do circuito pode ser visualizado na

figura 21.

27.0

VOUT

LM35

5V

Saída 1.5V MÁX.

71

Figura 36 - Circuito gerador do sinal de PIP. Fonte: adaptado do datasheet do CI 555 da Texas, 2015 .

4.1.6.5 Resultado da montagem do gerador de sinais

A figura 36 mostra o gerador de sinais finalizado.

10k

5V

10K

Saída 5V

R

DC

Q

GN

DV

CC

TR TH

CV555

0.1uF

4.7uF

10K

100nF

1

2

4

5

6

7

8

3

72

Figura 37 – Gerador de sinais completo. TPS, Temperatura e PIP. Fonte: elaborado pela autora.

4.1.7 Projeto do condicionador de sinais para o Kit PIC 24 e Kit PIC 18

Para adaptar os sinais provenientes dos circuitos geradores aos padrões

aceitáveis dos microcontroladores PIC24 e PIC 18 foram construídos os circuitos

elétricos dos condicionadores para esses sinais.

O PIC 24 trabalha com sinais de tensão máxima de 3.6 V e o PIC 18 com

tensão máxima de 5 V, portanto para que ambos tenham o mesmo atraso no

recebimento do sinal todos foram condicionados.

4.1.7.1 Fonte de 6V

Após alguns testes com o LM358, o amplificador operacional que realiza o

condicionamento dos sinais analógicos, TPS e temperatura, verificou-se a

necessidade de alimentá-lo com uma tensão mínima de 6 V (output), para seu

correto funcionamento em configuração buffer (seguidor de tensão), para essa

finalidade foi construída uma fonte com saída variável regulada em 6V. O CI

utilizado foi o LM317 que nesse projeto possui uma tensão de entrada (input) de 12

73

V, e seguindo as recomendações do datasheet R1 é de 270 Ω e o trimpot R2 é de

3.3 kΩ ajustado em 1.15 kΩ. O esquema elétrico do circuito pode ser visualizado na

figura 37.

Figura 38 – Fonte de 6V utilizando o LM317 para alimentação do circuito condicionador dos

sinais analógicos. Fonte: extraído do datasheet do CI LM317 da Texas, 2015.

4.1.7.2 Condicionador do circuito do TPS

Foi utilizado para o condicionamento do sinal do TPS um amplificador

operacional, o CI LM 358 em configuração buffer. As saídas se dividem em 5 V máx.

e 3.4 V máx. A tensão de 3.4 V é conseguida através de um divisor resistivo que

atenua a tensão em aproximadamente 30%. O esquema elétrico do circuito pode ser


74

Figura 39 - Circuito condicionador do sinal do TPS. Fonte: adaptado do circuito da ECU do Gol, Prof. Edson, 2014.

4.1.7.3 Condicionador do circuito da temperatura

Foi utilizado para o condicionamento do sinal da temperatura o amplificador

operacional LM 358 em configuração buffer. A saída é de 1.5 V máx. tanto para o

PIC 18 quanto para o PIC 24. O esquema elétrico do circuito pode ser visualizado na

figura 39.

270

LM358

TPS

2K2

4K7

5V MAX - PIC18

3,4V MÁX - PIC24

6V (Fonte-LM317)

75

Figura 40 - Circuito condicionador do sinal de temperatura. Fonte: adaptado do circuito da ECU do Gol, Prof. Edson, 2014.

4.1.7.4 Condicionador do circuito do PIP

Foram utilizados para o condicionamento do sinal do PIP dois comparadores

internos ao CI LM 339. Um divisor de tensão na entrada formado pelos resistores de

4.7 kΩ e 10 kΩ atenua a tensão de entrada em 30% que é encaminhada para as

entradas positivas de ambos comparadores, o diodo é responsável por grampear a

tensão do sinal de entrada em caso de surto de tensão, os dois resistores em série

de 10 kΩ dividem a tensão de alimentação (5 V) pela metade para as entradas

negativas de ambos comparadores criando um Schmitt trigger. As saídas dos

comparadores terão nível lógico 0 somente se nas entradas positivas existir uma

tensão maior do que 2.5 V. A saída do LM 339 é configurada como coletor aberto,

portanto para obter nível lógico 1 é necessário um resistor de pull-up. Além disso, foi

necessário incluir um divisor de tensão na saída do comparador B para obter uma

tensão máxima de 3.4 V compatível com o PIC 24 e a saída do comparador A

alimenta o PIC 18. O esquema elétrico do circuito pode ser visualizado na figura 38.

LM358

TEMPERATURA

1.5V MAX - PIC18 e PIC24

6V (Fonte LM317)

76

Figura 41 – Circuito condicionador do sinal do PIP. Fonte: adaptado do circuito da ECU para o

Gol, Prof. Edson, 2014.

4K7

1N4001

10k

PIP

10k

10k

LM339

LM339

100nF

1k

5V MÁX - PIC18

5V

5V

2K2

4K7

3,4V MÁX - PIC24

77

4.1.8 Resultado da montagem do condicionador de sinais

A figura 35 mostra o gerador de sinais finalizado.

Figura 42 –

4.1.9 Resultado do hardware completo

A figura 22 mostra o hardware completo finalizado contendo o Kit PIC24, o Kit

PIC 18, o gerador e o condicionador de sinais. Foram realizadas medições para

certificação dos valores desejados nas saídas dos condicionadores e nas fontes de

alimentação.

78

Figura 43 – Hardware finalizado ainda sem softwares finais. Fonte: elaborado pela autora.

79

4.2 Modelagem do software de injeção eletrônica em FreeRTOS para o

Kit PIC 24

O FreeRTOS foi criado no ano 2000 por Richard Barry e hoje é mantido pela

empresa Real Time Engineers Ltd. sendo o RTOS de código aberto mais utilizado

no mundo, distribuído sob a licença GPL (General Public License – Licença Pública

Geral), que garante a liberdade de copiar, modificar e distribuir cópias sem que seja

necessário o pagamento de royalties para isso. É simples, pequeno e extremamente

portável, com uma vasta documentação oficial e não oficial, incluindo livros e vídeos.

Todo o código fonte do FreeRTOS é baseado no padrão MISRA C (Motor

Industry Software Reliability Association – Associação da Indústria Automobilística

de Confiabilidade de Software) escrito em linguagem C, com algumas exceções. A

MISRA, que é composto principalmente pelo setor automotivo, tem o objetivo de

promover melhores práticas para o desenvolvimento de produtos eletrônicos

automotivos.

No site do FreeRTOS, são disponibilizado projetos demonstrativos pré-

configurados para microcontroladores de mais de 30 arquiteturas diferentes.

Para esse projeto foi escolhida a versão 9.0.0 do FreeRTOS, em conjunto

como a interface de desenvolvimento MPLABX versão 3.20 e compilador XC16 na

versão 1.25.

Conforme recomenda a documentação do FreeRTOS, será utilizado o projeto

demo pré-configurado para PIC 24 disponível no diretório FreeRTOS\DEMO. Esse

projeto é específico para funcionar no Kit de desenvolvimento Explorer 16, porém,

após a obtenção dos arquivos fonte que formam o kernel do RTOS e dos caminhos

corretamente configurados, que são comuns a qualquer modelo de PIC 24, será

possível o desenvolvimento das aplicações de injeção eletrônica.

80

4.2.1 Estrutura básica do FreeRTOS

Uma vez que a aplicação de demonstração está construída e executando na

IDE MPLABX os arquivos se apresentam estruturados conforme mostra a figura 36.

Figura 44 – Estrutura de arquivos do FreeRTOS do projeto demo para PIC24FJ128GA110, carregados. Fonte: adaptado de MPLAB X IDE v.3.20.

81

4.2.2 Grupo de arquivos que formam o kernel

O diretório FreeRTOS_Source contém os três arquivos que são comuns a

cada microcontrolador; list.c, queue.c e tasks.c, o kernel está contido dentro destes

três arquivos, como mostra a figura 45.

Figura 45 – Arquivos do kernel que não necessitam de modificação. Fonte: extraído do ambiente de desenvolvimento do MPLAB X IDE v.3.20.

Dois arquivos opcionais; timers.c e croutine.c implementam as

funcionalidades de temporizador de software e co-rotina, respectivamente. A co-

rotina normalmente é utilizada em para trabalhar com microcontroladores de 8 bits e

memória RAM (Random Access Memory - Memória de Acesso Aleatório) muito

limitada.

O diretório FreeRTOS_Source\Portable contém os arquivos que são

específicos para um microcontrolador e ou compilador particular e diretório

FreeRTOS_Source contém os arquivos de cabeçalho do kernel: heap_1.c, list.c,

queue.c e tasks.c.

82

4.2.3 Configurando heap de memória

Como já mencionado, em uma configuração típica, o kernel pode ocupar de 4

kB a 9 kB de código (ROM/flash) e em torno de 200 bytes de dados (RAM), podendo

trabalhar de modo pre-emptive (de preferencia) ou colaborativo.

O kernel RTOS precisa de RAM cada vez que uma task, queue (fila),

temporizador de software, semáforo ou evento é criado. Sistemas de tempo real

embarcados podem ter diferentes requisitos de RAM e de sincronização de um para

outro, por isso um único algoritmo de alocação de memória só vai ser apropriado

para um subconjunto de aplicações. É no heap (empilhamento) que o kernel aloca

memória para armazenar os dados das tarefas, queues e semáforos usados na

aplicação.

A memória RAM pode ser automaticamente ou dinamicamente alocada no

FreeRTOS. O arquivo heap_1.c é a implementação mais simples, apenas aloca

memória de forma estática e não permite que a memória seja liberada após ser

alocada. É apropriada para esse projeto, pois as aplicações criarão todas as tarefas,

filas, semáforos, etc. necessárias quando o sistema for inicializado e, em seguida,

usarão todos esses objetos durante a vida útil do programa até que o aplicativo seja

desligado novamente, sem a exclusão de nenhum dos componentes criados.

A implementação heap_1.c é sempre determinista levando sempre a mesma

quantidade de tempo para executar e é adequada para uso em aplicativos que não

permitem alocação dinâmica de memória.

O tamanho total do heap é definido pelo configTOTAL_HEAP_SIZE que é

definido no arquivo de customização FreeRTOSConfig.h que será detalhado mais a

frente.

83

4.2.4 Grupo de arquivos que formam a aplicação de EFI

A figura 51 mostra os arquivos criados e modificados especificamente para

atender a aplicação de injeção eletrônica para o Kit PIC 24.

Figura 46 - Arquivos criados especificamente para a aplicação. Fonte: extraído do ambiente de desenvolvimento do MPLAB X IDE v.3.20.

A figura 51 mostra os arquivos criados e modificados especificamente para

atender a aplicação de injeção eletrônica para o Kit PIC 24.

84

4.2.5 A criação de tasks

O arquivo tasks.c provê as funções necessárias para a criação das tasks.

Antes de serem utilizadas as tasks devem ser deeclaradas e definidas.

Para o projeto foram criadas 4 tasks com funções específicas , vDefineTinj,

vADTPS, vADTemperatura e vDefineRotacao, o fluxograma das funções pode ser

visualizado na secção de APÊNDICES.

A aplicação em FreeRTOS será desenvolvida a partir de um conjunto de

tasks, onde cada task se comporta como um programa isolado em um loop infinito.

O arquivo KitPic24.c contem quatro tasks: define tempo de injeção (vDefineTinj), lê e

calcula o valor do TPS (vADTPS) lê o valor da temperatura (vADTemperatura)

calcula o valor da rotação (vDefineRPM), o arquivo KitPic24.h dá suporte a criação

das tasks e cria a estrutura utilizada pelas tasks vDefineTinj e vADTPS. A figura 47

mostra como é a sintaxe para a criação da task e seu loop no FreeRTOS.

Figura 47 – (a) Loop infinito de uma task e (b) criação da task. Fonte: adaptado de Using The FreeRTOS Real Time Kernel: A Pratical Guide PIC32, 2010.

No arquivo main.c

85

4.2.6 Utilizando as queues

A queue é um algoritmo que não pertence a nenhuma tarefa em específico e

são mecanismos primitivos utilizados por todas as comunicações e sincronizações

FreeRTOS e para a troca de mensagens entre as tarefas. As tarefas compartilham a

mesma queue tanto para ler como para escrever. Cada queue armazena um

conjunto finito de itens queue lenght (comprimento da fila) e cada item da queue

pode ter um tamanho fixo de bytes o item size. Ambos "queue lenght" e "item size"

são definidos no momento da criação da queue sendo que o FreeRTOS aloca

espaço no heap para as queues criadas.

Na figura 39 a queue é criada para permitir a comunicação entre a Task A e a

Task B. Ela permite no máximo 5 inteiros e quando é criada não contem nenhum

valor.

Figura 48 - Queue criada e sem elementos. Fonte: Using The FreeRTOS Real Time Kernel: A Pratical Guide PIC32, 2010.

Na figura 40 a Task A envia (send) o valor de uma variável local para a

queue. Como estava vazio no início o valor enviado é agora o seu único item.

Figura 49 - Envio de elemento para queue. Fonte: Using The FreeRTOS Real Time Kernel: A Pratical Guide PIC32, 2010.

86

Na figura 41 a Task A altera o valor da variável local antes de enviá-lo

novamente a queue. Após o envio ela conterá a cópia dos valores com o primeiro

valor escrito na frente na queue e o último valor subsequente. A queue agora possui

três espaços restantes.

Figura 50 - Envio de elemento para queue. Fonte: Using The FreeRTOS Real Time Kernel: A Pratical Guide PIC32, 2010.

Na figura 42 a Task B recebe (receive) da queue o valor dentro de uma

variável diferente. O valor recebido pela Task B é o primeiro valor enviado pela Task

A.

Figura 51 - Recebimento de elemento via queue. Fonte: Using The FreeRTOS Real Time Kernel: A Pratical Guide PIC32, 2010.

Na figura 43 a Task B remove o item recebido restando o segundo valor

enviado pela Task A, esse será o próximo valor que a Task B receberá se ler a

queue novamente. Restam agora quatro espaços disponíveis.

Figura 52 - Reposicionamento de elemento na queue. Fonte: Using The FreeRTOS Real Time Kernel: A Pratical Guide PIC32, 2010.

87

Antes das queues serem utilizadas devem ser criadas, mas sempre dentro

dos arquivos de aplicação. As queues recebem como retorno um QueueHandle

Para esse projeto foram criadas duas filas QueueHandle_t

xACCVALORQueue; QueueHandle_t e reutilizada uma fila da aplicação testada, a

xLCDQueue para envio dos três dados atualizados que aparecem no LCD, “Tinj”,

“RPM” e “T” (temperatura).

Duas variáveis globais precisaram ser criadas, pois ao acrescentar uma maior

quantidade de queue, notou-se em alguns testes uma considerável redução da

capacidade responsiva do bico de injeção, rpm_global e tinjglobal.

4.2.7 Semáforos

Além das queues os Semáforos Binários (Binarys Semaphores) são

mecanismos de sincronização disponibilizados pelo FreeRTOS.

Uma interrupção é capaz de deferir trabalho para uma tarefa através dos

semáforos podendo ser usado para acordar (desbloquear) uma tarefa quando

determinada interrupção acontecer, sincronizando a interrupção com a tarefa. Desta

forma, apenas o essencial é executado na interrupção, o restante do trabalho é

deferido para a tarefa correspondente ao tratamento da interrupção.

Um semáforo foi criado, xSemaphoreGiveFromISR (sem_INT0,

&task_woken) foi criada para sincronizar a task DefineTinj( ) com a interrupção

externa INT0/PIP, a variável task_woken é encarregada de sair da interrupção se

houver sucesso.na entrega do semáforo para a task.

Figura 53 -

88

A figura 53 ilustra o mecanismo de entrega give e tomada take de um

semáforo

Figura 54 -

4.2.8 Customização do FreeRTOS

O arquivo de pré-processamento FreeRTOSConfig.h é responsável pela

customização do FreeRTOS de qualquer nova aplicação e portanto não deve estar

localizado em um dos diretórios de código fonte do kernel e sim no diretório da

aplicação. No projeto existem defines do kernel e defines das APIs.

Os defines do kernel configurados para esse projeto podem ser visualizados

na tabela 3 e os defines das APIs na tabela 4.

89

Tabela 3 - Definição das funções dos pinos

#define configUSE_PREEMPTION

1 Para selecionar modo preemptive

#define configCPU_CLOCK_HZ

16000000 Hz

Mesmo clock da CPU, valor necessário para

configurar corretamente os periféricos do timer,

utilizado para gerar o tick interrupt para a troca

de contexto.

#define configTICK_RATE_HZ

100

(100Hz – 10ms)

Frequência de interrupção (tick), uma maior

freqüência de tick pode ser medido numa

resolução maior. No entanto, uma alta

freqüência de tick também significa que o kernel

RTOS usará mais tempo de CPU.

Mais de uma tarefa pode compartilhar a mesma

prioridade.

#define configMAX_PRIORITIES

4

O número de prioridades disponíveis para as

tarefas do aplicativo. Qualquer número de

tarefas pode compartilhar a mesma prioridade.

Cada prioridade disponível consome RAM no

kernel RTOS, portanto, esse valor não deve ser

superior ao realmente exigido pelo aplicativo.

#define configMINIMAL_STACK_SIZE

115

O tamanho da pilha usada pela tarefa ociosa.

Não deve ser menor do que 115

#define configTOTAL_HEAP_SIZE

((size_t) 5120 )

A quantidade total de RAM disponível no heap

do FreeRTOS e o aplicativo faz uso de um dos

esquemas de alocação de memória (heaps)

fornecidos no download do código fonte do

FreeRTOS.

#define configMAX_TASK_NAME_LEN

14

O comprimento máximo permitido do nome

descritivo dado a uma tarefa quando é criada. O

comprimento é especificado em número de

caracteres incluindo o byte de terminação

NULL.

#define configUSE_16_BIT_TICKS Como 1 faz com que TickType_t a variável

90

0 que configura o tick seja definido tipo

unsigned 16 bits. Como 0 faz com que

TickType_t seja definido tipo unsigned 32

bits.

Fonte :

#define configUSE_PREEMPTION

1 Para selecionar modo preemptive

#define configCPU_CLOCK_HZ

16000000 Hz

Mesmo clock da CPU, valor necessário para

configurar corretamente os periféricos do timer,

utilizado para gerar o tick interrupt para a troca

de contexto.

#define configTICK_RATE_HZ

100

(100Hz – 10ms)

Frequência de interrupção (tick), uma maior

freqüência de tick pode ser medido numa

resolução maior. No entanto, uma alta

freqüência de tick também significa que o kernel

RTOS usará mais tempo de CPU.

Mais de uma tarefa pode compartilhar a mesma

prioridade.

4.2.9 Configuração dos periféricos

O arquivo partes.c prove o setup dos registradores configurados no uC de

interrupção externa INT0 (PIP), interrupção de Timer2

91

5 GRAVAÇÃO FINAL DOS SOFTWARES E ANÁLISE DE

RESULTADOS

Foram utilizadas duas formas diferentes para a gravação dos PICs. O PIC 24

utiliza gravação com protocolo ICSP e o PIC 18 utilizou um bootloader.

Algumas pequenas modificações foram realizadas no firmware original do PIC

18, alterando apenas os LCD, para

92

Figura 55 -

93

A figura 54 mostra o resultado do pulso de injeção (laranja) sendo gerado de

forma incorreta com um grande atraso entre o sinal do PIP e o pulso. Isso ocorreu

quando a task DefineTinj ( ) possuía uma prioridade de 3.

Figura 56 - Pulso de PIP (azul de 5 V ) injeção (laranja de 3 V) gerado a 650 RPM pelo kit PIC 18. Fonte: elaborado pela autora.

Após a alteração da prioridade da mesma tarefa para 4 o pulso se comportou

de forma esperada. Não foram observadas defasagens significativas na amostragem

dos dados no display. A figura 55 mostra os pulsos de injeção sincronizados com os

de PIP.

A base temporal de calculo do ACC é 100ms criada pela vTaskDelayUntil( )

94

Figura 57 - Pulso de injeção gerado a 650 RPM pelo kit PIC 24. Fonte: elaborado pela autora.

As próximas figuras ilustram as comparações realizadas entre os dois kits em

três faixas de valores; 650 RPM, 3000 RPM e 6000 RPM, algumas mudanças de

escala foram necessárias para melhor visualização.

Como o osciloscópio utilizado possui dois canais os pulsos foram medidos

com relação ao seu próprio PIP.

A figura 57 mostra o pulso de injeção criado pelo kit PIC 18 a 650 RPM que

pode ser comparado com a figura 55 elaborada acima.


95

As figuras 58 e 59 ilustram ambos os pulsos gerados a 3000 RPM.



As figuras 60 e 61 mostram os pulsos de injeção criados a 6000 RPM, a partir

dessa faixa o RTOS do PIC 24 apresenta travamento e o reset do software por

alguns segundos. A figura 61 ilustra exatamente o momento do travamento do

software quando o bico permanece ligado por um tempo bem maior.

96



97

Figura 63 – Retomada do pulso de injeção gerado a 6000 RPM após reset pelo kit PIC 24.

Fonte: elaborado pela autora.

Retomando um rotação mais baixa as figuras 62 e 64 mostram o média de

tempo de pulso de injeção já incrementado pelo cálculo do ACC. No kit PIC 18 o

firmware que realiza o cálculo no PIC 24 o cálculo é realizado no pela Task

Figura 64 – Incremento de pulso via bomba de aceleração (TPS) do kit PIC 18. Fonte: elaborado pela autora.

98

Figura 65 - Incremento de pulso de injeção (laranja) via bomba de aceleração (TPS) do kit PIC 24. Fonte: elaborado pela autora.

O pulso de injeção mínimo configurado para ambos os softwares foi de 2 ms.

Isso se manteve

Figura 66

99

Figura 67 -

Foi medido o tempo decorrido entre a borda de descida do PIP e o

acionamento do bico injetor. As figuras

Figura 68 -

100

Figura 69 – Defasagem entre PIP e pulso de injeção no kit PIC 24. Fonte: elaborado pela autora.

6 CONCLUSÃO

Muitas dificuldades permearam a UMA DAS MEDIDAS para diminuir o erro

nos projetos é realizar comparações entre os sistemas operacionais utilizados

através de estudos encomendados, empresas como a Australiana Dedicated

Systems que atua desde 2003 realizando relatórios de desempenho de softwares, a

má aplicação ou mesmo a explosão da sonda petrolífera Deep Horizon no Golfo do

México em 2010, que causou um dos maiores desastres naturais ao desacoplar a

sonda O estudo demonstrou que a utilização do RTOS para controle da injeção

eletrônica pode ser viável mas que necessita de maiores testes entretanto podem ter

boa qualidade par sistemas de tempo real soft por enquanto.

No decorrer do projeto foi lançado o chibios para PIC 24 o que reforça ainda

mais essa opção pelo tema

A frequência da interrupção do tick RTOS.

A interrupção do carrapato é usada para medir o tempo. Portanto, uma maior

freqüência de tiquetaque significa que o tempo pode ser medido para uma resolução

maior. No entanto, uma alta freqüência de tick também significa que o kernel RTOS

usará mais tempo de CPU para ser menos eficiente. Os aplicativos de demonstração

101

RTOS todos usam uma taxa de tick de 1000Hz. Isso é usado para testar o kernel

RTOS e é maior do que seria normalmente necessário.O programador RTOS irá

compartilhar o tempo do processador entre tarefas da mesma prioridade alternando

entre as tarefas durante cada RTOS tick. Uma frequência elevada de frequência de

tiquetambém terá também o efeito de reduzir a "fatia de tempo" dada a cada tarefa.

Usar um tipo de 16 bits melhorará muito o desempenho em arquiteturas de 8

e 16 bits, mas limitará o período de tempo máximo especificável para 65535 'ticks'.

Portanto, assumindo uma freqüência de tick de 250Hz, o tempo máximo que uma

tarefa pode atrasar ou bloquear quando um contador de 16 bits é usado é 262

segundos, em comparação com 17179869 segundos quando se usa um contador de

32 bits.

7 PROPOSTAS FUTURAS

Utilização de APIs diferentes para a construção da mesma aplicação.

Inclusão de novas funcionalidades ao harware e software, inclusive a

temperatura como parâmetro para cálculo de débito de combustível.

Adaptação do hardware para recebimento dos sinais do veículo Gol ou outro

veículo disponibilizado pela FATEC Santo André.

Implantação de “sondas de software” para estudos mais aprofundados acerca

de

Utilização de outros RTOSs

Construção de aplicações diversas, para outros módulos eletrônicos

existentes no veículo e acionamento de outros atuadores.

102

8 REFERÊNCIAS

AROCA, R. V. Análise de Sistemas Operacionais de Tempo Real para Aplicações de

Robótica e Automação. Monografia (Dissertação de Mestrado) - Escola de

Engenharia de São Carlos, 2008.

BARRY, Richard. Using The FreeRTOS Real Time Kernel: A Pratical Guide, PIC32

Edition. London: Real Time Engineers Ltd. 2010. 175p. (ISBN: 1446171086)

BOSH. Technical Instruction Gasoline Fuel-Injection System L-Jetronic. 1995.

Alemanha. Disponível em: <http://www.cardiagnostics.be/-

now/Educational_sites_bestanden/BOSCH%20L-Jetronic%20Injection%20Manual.pdf>

Acesso em: 03 mai. 2016.

BRUNETTI, Franco. Motores de Combustão Interna – Vol.1. São Paulo: Blucher

2012. 554p. (ISBN: 9788521207085)

MATA, V. M. J. da; MOSCARDINI, D. Unidade de Gerenciamento Eletrônico de

motor de ciclo Otto Volkswagen 2.0L: Plataforma de desenvolvimento III. Monografia

(Trabalho de Conclusão de Curso) – FATEC Santo André, 2014.

103

MICROCHIP. User’s Guide Explorer 16 Development Board, 2005-2014. Disponível

em: <http://ww1.microchip.com/downloads/en/DeviceDoc/51589a.pdf> Acesso em:

14 fev. 2016.

MICROCHIP. Section 6 Oscillator. PIC24F Family Reference Manual, 2009.

Disponível em: <http://ww1.microchip.com/downloads/en/DeviceDoc/39700c.pdf>

Acesso em: 20 fev. 2016.

MICROCHIP. Section 8 Interrupts. Family Reference Manual, 2006. Disponível em: <

http://ww1.microchip.com/downloads/en/DeviceDoc/39707a.pdf> Acesso em: 13 jun.

2016.

MICROCHIP. Section 14 Timers. Family Reference Manual, 2006. Disponível em: <

http://ww1.microchip.com/downloads/en/DeviceDoc/39707a.pdf> Acesso em: 10 ago.

2016.

MICROCHIP. Section 17 10-Bit A/D Converter. PIC24F Family Reference Manual,

2006. Disponível em: <http://ww1.microchip.com/downloads/en/DeviceDoc/39705b.pdf>

cesso em: 20 fev. 2016.

PORTAL FREERTOS. FreeRTOS Real Time Kernel v.9.0.0. Disponível em:

<https://sourceforge.net/projects/freertos/?source=typ_redirect>. Acesso em: 20 mai.

2016.

PRADO, Sergio Prado. FREERTOS. Treinamento, 2015, São Paulo, 321p.

MICROCHIP. Datasheet PIC24FJ256GB110 Family, 2009. Disponível em:<

<http://ww1.microchip.com/downloads/en/DeviceDoc/39897c.pdf> Acesso em: 18

jan. 2016.

<http://rusefi.com/wiki/index.php?title=Main_Page > Acesso em 11 dez. 2016.

Notas de aula do professor Edson Caoru Kitani

104

APÊNDICE A – Fluxograma da Função Principal elaborada em FreeRTOS

105

APÊNDICE B – Fluxograma da task Define RPM elaborada em FreeRTOS

106

107

APÊNDICE C – Fluxograma da task DefineTinj elaborada em FreeRTOS

108

109

110

APÊNDICE D – Fluxograma da task ADTPS elaborada em FreeRTOS

111

112

APÊNDICE E – Fluxograma do Timer 2 elaborada em FreeRTOS

113

APÊNDICE F – Fluxograma da task vLCDTask do FreeRTOS

114

ANEXO A – Esquema elétrico do Kit PIC 18

Documents

CENTRO PAULA SOUZA FACULDADE DE TECNOLOGIA …fatecsantoandre.edu.br/arquivos/TCC470.pdf · CENTRO PAULA SOUZA FACULDADE DE TECNOLOGIA DE SANTO ANDRÉ Tecnologia em Eletrônica Automotiva