PIC18 kredsene, er blandt de større PIC kredse - det er faktisk den serie, som jeg hentyder til, når jeg skriver de godt kan programmeres i C. Til 18 serien, er det meste af Microchips eget software også i C - og du kan få TCP/IP og netværkssoftware til 18 serien. De findes med indbygget 10 MBIT LAN. PIC10 kredsene, er nogle af de små. De er ikke så egnet til C. Dog, så er f.eks ATMEL kredse mere egnet end 18 serien, da du her kan bruge en standard GNU C. Det findes ikke til PIC serien. Derfor, vil man typisk kode de komplekse ting ind i ECU'en, hvor der bruges en kreds, der er egnet til f.eks. C, eller et andet programmeringssprog.
Med hensyn til baudrate, så er det meget normalt, at modtageren (ECU'en) detekterer denne. Det sker ved at måle på pulsernes bredde, og indstille frekvensen derefter. Nogle sender en speciel sekvens først, for at frekvensen nemt detekteres. Hvis sync pulsen, er negeret, så vil start bit være en bit bred, og dermed kan sendefrekvensen nemt detekteres udfra startbittens bredde på første byte der sendes. Det er meget normalt, at modtageren detekterer frekvensen ved PIC kredse, fordi de er uden krystal - så for alle de små, fungerer det ofte sådant. De RS232 biblioteker som findes på nettet, rummer normalt automatisk detektion af hastigheden, ved at f.eks. finde mindste bredde af en databit i en sekvens. Den vil i langt de fleste tilfælde, svare til en bit bredde, og kan bruges til hastighedsmåling. Det er også meget normalt, at starte en sekvens med f.eks. 55H, hvor bittene skifter skiftevis.
Det er ikke muligt, at genneralt sige tjeksum er bedre end at sende data 3 gange. En tjeksum indeholder mindre information - og hvad skal den være tjeksum af? Vil du sende en sum, af de to sensorers værdi? Og skulle det være mere sikkert, end at sende hver enkelt sensors værdi med tjeksum? At sende værdien to gange, svarer til tjeksum - hvis du sender den ene negeret. Det betyder dog ikke meget her, da det ikke er et problem hvis udgangen konstant hives høj eller lav. Så modtages ikke valid data. Det er derfor sikkert nok, selvom hver anden ikke sendes negeret. At sende 3, gør det naturligvis mere sikkert end tjeksum. Og det rummer mulighed for, at ECU'en kan foretage fejlretning, men også nemt kan se, at der er sket fejl. Desuden sendes data igen, meget kort tid efter - typisk 100 gange i sekundet - og den kan springe målingen over, hvis den fejler.
Selvtest er til en vis grad med, for ændrer du i koden, ændrer en bit i registrene eller andet, så vil de tre data ikke passe. Det betyder, at ECU'en kan se der er opstået en fejl. Hvis reset oscillatoren svigter, så opdages det også - da vil ingen data sendes. Det er faktisk svært at gøre noget, som ikke opdages. Hvis A/D konverteren fejler, er den ligesom HALL elementerne duppleret, så det også opdages.
Alle dine sikkerhedsanalyser skal ikke ind i PIC'en. Standard afvigelse på ADC læsningerne, afvigelse på data mellem de to analoge værdier osv. hører under ECU'en, og er præcis det samme, som nu er programmeret i ECU'en. Reset, watch-dog, osv. er der også taget hensyn til. Den resetter hele tiden, af watch-dog'en, således at der sendes en portion data 100 gange i sekundet. Hvis reset eller watch-dog ikke virker, så kommer ingen data. Og det opdager ECU'en.
Sker fejl, så kan ECU'en slukke for strømmen til såvel HALL sensors, som til PIC'en, og forsøge om det virker med genstart.
Jeg kan ikke udelukke, at det kan gøres bedre, hvis man overvejer det grundigt. Som eksempel, kan ECU undersøge lækstrømme i ledningerne. Dette vil kræve, at PIC'en sætter udgangen threestate et stykke tid. Det er ikke medtaget. Men, det kan nemt lægges ind, at den f.eks. skifter til three-state, i et stykke tid mellem hver pakke. Det er ikke nødvendigt at sende data i begge retninger.
Det er korrekt, at jeg ikke nævte de funktioner som nu er i ECU'en, da formålet med PIC'en alene er at videresende de analoge signaler - og det betyder naturligvis at den eksisterende sikkerhed i ECU'en stadigt skal være der. Dette inkluderer vurdering af de analoge inputs, deres interval, osv. Og at eventuelt sammenholde med forrige værdier. For PIC kredsen, starter hele livet forfra, med en ny sending data. Dette øger sikkerheden. For ECU'en sammenholdes værdierne, og i nogle tilfælde, vil måske tages et gennemsnit, udover at åbentlyst forkerte konverteringer smides bort. En konvertering ved speederen, er dog ikke så kritisk, som hvis du fører ledninger op til ECU'en, da du undgår støj i kablet.
På mange måder, er "min" løsning, omtrent samme som du oprindeligt foreslog: At sende de analoge signaler direkte til ECU'en. Dog, vil jeg lige digitalisere dem først. Og sende dem et par gange, eller tre - således jeg opdager, hvis der er fejl i koden. Tjeksum, kan naturligvis også bruges som alternativ. De fleste fejl, som PIC kredsen kan medføre, svarer til sensorfejl eller analog konverteringsfejl, og opdages af ECU'en. Så vi behøver egentligt ikke, at sende data flere gange, eller sende tjeksum. Uanset, hvad der sker, så burde det opdages af ECU'en udfra analyse af de analoge værdier i forhold til de forrige.
Koden er derfor ikke kritisk. Det kritiske er, at sikre der ikke bruges data mellem resets, og sikre at der resettes f.eks. 100 gange i sekundet. Koden, må helst ikke indeholde en watchdog clear indstruktion, da denne indstruktion gør kode usikker (en løkke kunne aktivere indstruktionen til at køre uafbrudt). Normalt, skal der være to indstruktioner, der skal køre skiftevis - således at to uafhængige rutiner, kan aktivere dem på skift. Desvære, giver PIC kredsene ikke mulighed for det, så derfor er mest sikkert, at bare genstarte dem hele tiden.
Dertil, skal du analysere de analoge data i ECU'en - og typisk smide åbentlyse data bort, og måske lave gennemsnitsmåling over nogle målinger.
5
