I2C-bussen, som ofta används för kommunikation mellan olika komponenter inom inbyggda system, är designad för att koppla samman flera enheter på en och samma tvåtrådsbuss. Bussen fungerar genom att en enhet, kallad master, initierar och kontrollerar kommunikationen med de anslutna enheterna, kända som slavar. Kommunikation på denna buss sker genom specifika start- och stoppvillkor som alla enheter på bussen känner igen och reagerar på.
Vid inaktivitet är både SCL (klocksignal) och SDA (datainformation) höga, vilket indikerar att bussen är ledig. En ram på bussen startas när master-enheten drar SDA-linjen låg medan SCL förblir hög, ett tillstånd känt som START-villkoret. Alla enheter på bussen känner igen detta som början på en ny ram. Kommunikationen avslutas med ett STOP-villkor där master-enheten höjer SDA-linjen från låg till hög medan SCL fortfarande är hög. När STOP-villkoret inträffar, går bussen tillbaka till inaktivt tillstånd, vilket gör det möjligt för vilken som helst master-enhet att initiera en ny busstransaktion.
Under själva ramen genererar master-enheten klocksignalen SCL, medan slav-enheterna kontrollerar SDA-linjen under ack-punkten. I2C-kommunikation överför data bit för bit, där varje byte överförs MSB (most significant bit) först. Efter att 8 bitar har överförts, skickar den mottagande enheten ett bekräftelsebit (ACK) på den nionde klockcykeln genom att dra SDA-linjen låg.
För att förstå kommunikationen på bussen är det viktigt att notera att den första byten i varje ram innehåller en 7-bitars adress som identifierar den enhet som master-enheten försöker kommunicera med. Följt av denna adress är en bit som anger om master-enheten avser att skriva (logisk 0) eller läsa (logisk 1) från den adresserade enheten. Om den adresserade slav-enheten är närvarande och redo att kommunicera, kommer den att generera ett ACK genom att dra SDA-linjen låg under den nionde klockcykeln.
En annan viktig aspekt är att en I2C-buss kan ha flera master-enheter, vilket innebär att flera enheter kan försöka ta kontroll över bussen samtidigt. Detta fenomen kallas för busstävlan. I en sådan situation försöker en enhet att sända logisk 0 medan en annan försöker sända logisk 1, vilket leder till att SDA-linjen förblir låg. Enheten som inte får kontroll över bussen kommer att avbryta sin överföring. Om båda master-enheterna försöker läsa data från samma enhet kommer båda master-enheterna att kunna läsa samma data, förutsatt att de använder samma klockfrekvens.
I2C-bussens unika egenskap ligger i användningen av öppna kollektorlinjer, vilket gör att olika enheter kan arbeta tillsammans utan att orsaka kortslutning eller skador på kretsarna. Vid användning av öppna kollektorlinjer kan en enhet dra linjen låg, medan en annan kan dra den hög utan att det uppstår några konflikter. Detta tillvägagångssätt används också för funktioner som busståvlan och klocksträckning. Klocksträckning tillåter långsammare enheter på bussen att dra ner SCL-linjen för att få mer tid för sina operationer, vilket gör det möjligt för enheter med olika hastigheter att samexistera på samma buss.
En annan aspekt som är viktig för att förstå I2C-kommunikation är adresseringen av enheterna. Varje enhet på bussen har en unik 7-bitars adress som vanligtvis är inbyggd i enheten själv, men vissa enheter tillåter justering av adressen genom externa pinnar. På detta sätt kan en I2C-buss ha upp till 127 enheter. Men även om I2C tillåter flera master-enheter, är det vanligaste arrangemanget att en enda master-enhet kontrollerar bussen, medan de andra enheterna fungerar som slavar.
Det är också viktigt att notera att när man arbetar med en I2C-buss är det vanligt att en mikrocontroller fungerar som master-enhet, medan sensorer, kontroller och andra enheter fungerar som slavar. Mikrocontroller-enheten behöver inte ha en egen I2C-adress eftersom den inte kan bli adresserad av andra enheter. I det här fallet är det mikrocontroller-programvaran som kontrollerar klocksignalen SCL och datalinjen SDA, vilket kräver noggrant programmering för att hantera hastigheten på olika enheter anslutna till samma buss.
För att ytterligare underlätta användningen av I2C-kommunikation kan externa kretsar, som t.ex. PCF 8485, användas för att hantera själva kommunikationen mellan mikrocontroller och andra enheter. Sådana kretsar möjliggör enklare integration av I2C-bussens funktioner och gör det möjligt att hantera komplexa interaktioner mellan enheter på ett mer effektivt sätt.
Hur säkerställer man att en produkt verkligen möter kundens behov?
Verifikation och validering är grundläggande processer inom systemdesign och produktutveckling som säkerställer att en produkt eller system uppfyller de behov och krav som har ställts. Även om verifikation handlar om att kontrollera att de tekniska specifikationerna uppfylls, går validering längre genom att bekräfta att produkten verkligen tillgodoser kundens behov, även de som inte alltid kan formuleras i tekniska termer.
I många fall kan kundens behov vara svåra att exakt uttrycka genom specifika krav. Exempelvis kan estetiska faktorer, som hur en bro integreras med den omgivande arkitekturen, eller hur användargränssnittet på en operatörskonsol känns för användaren, vara avgörande för produktens framgång. Dessa behov är svåra att kvantifiera eller uttrycka genom matematiska modeller, men de påverkar starkt hur väl produkten tas emot av användaren. Under designfasens senare skeden kan arkitektexperter ge råd om hur produkten kan passa in i sin omgivning, men den slutgiltiga bedömningen sker först när produkten är färdig och användarna kan avgöra om den verkligen möter dessa mer subjektiva krav.
Validering handlar om att utvärdera hur väl en produkt möter de olika intressenternas behov – kunder, användare, projektledare och andra aktörer. Det handlar inte bara om att fastställa om kraven har uppfyllts, utan också om att bedöma hur väl dessa krav har uppfyllts. Är behoven knappt tillgodosedda eller uppfyllda på ett mer övertygande sätt? Utvärdering och reflektion kring designprocessen, konstruktion och implementering är avgörande för att förbättra framtida produkter. Det är en process där man inte bara verifierar utan också lär sig av det som gjorts, så att det kan appliceras på framtida projekt.
Verifikation är en process som säkerställer att varje steg i designen lever upp till de initiala kraven som ställdes för det steget. Vid varje designfas skapas en produkt, en modell, som utgör en grund för nästa fas och som måste uppfylla de krav som definierades i föregående fas. Verifikation görs antingen genom formella metoder, som matematiska bevis, eller genom informella metoder som genomgångar och simuleringar. De senare metoderna kan inte nödvändigtvis bevisa att alla krav är uppfyllda, men de kan vara övertygande nog för att ge trygghet till de inblandade parterna.
Varje krav kan uttryckas som en egenskap som måste vara sann. Till exempel, i ett broprojekt kan ett krav vara att barriärerna måste vara nere och vägtrafiken måste vara rensad från bron innan den kan höjas. Detta kan verifieras genom att undersöka meddelandeflödesdiagram i den beteendemodell som används under designfasen. Krav som ställs i den beteendemodellen leder vidare till krav i andra modeller, som till exempel FSM (Finite State Machine) eller Petri-nett, och måste också verifieras på dessa nivåer.
Det finns emellertid krav som inte direkt relaterar till någon av modellerna utan handlar om andra aspekter av systemet. Ett exempel på detta kan vara kravet på att systemet måste kunna upptäcka en båt som närmar sig bron minst tre minuter innan den når bron. Detta är en egenskap som inte kan modelleras direkt med beteende-, FSM- eller Petri-modeller utan måste tas i beaktning under valideringen.
Egenskaper som är av intresse i verifiering kan vara av olika slag: vissa krav gäller för att något alltid ska vara sant, som att trafiken alltid måste vara rensad från bron innan den höjs; andra kan vara att något aldrig får vara sant, som att bron aldrig får höjas när det finns bilar eller fotgängare på den. Det kan också finnas krav på att något ska inträffa förr eller senare, som att trafiken så småningom ska tillåtas passera över bron efter att systemet startats. Dessa krav är ofta relaterade till hur systemet förväntas bete sig under olika scenarier.
Vid verifiering används olika tekniker för att säkerställa att systemet fungerar enligt de angivna kraven. En vanlig metod är att resonera bakåt, vilket innebär att man börjar med slutsatserna och arbetar sig bakåt för att förstå vilka antaganden och förutsättningar som krävs för att dessa slutsatser ska vara sanna. Detta kan vara särskilt användbart vid verifiering av inbäddade system där olika scenarier behöver beaktas.
En annan teknik som används vid verifiering är fallanalys, där olika scenarier behandlas separat för att förstå hur systemet reagerar under olika omständigheter. Denna metod är särskilt användbar vid verifiering av system som bygger på olika användningsfall och där olika vägar i systemets funktioner kan leda till olika resultat.
Slutligen är en annan användbar metod att använda motexempel. Dessa används för att visa att en viss egenskap inte uppfylls under vissa förutsättningar. Simuleringar och genomgångar med utvecklingsteam kan ofta avslöja sådana motexempel, vilket leder till att modellen behöver revideras.
Förutom dessa tekniska metoder finns det flera andra aspekter som är viktiga att ta hänsyn till vid utvecklingen av inbäddade system. En viktig del är att förstå och hantera komplexiteten i systemet. Ett system som är för komplext att verifiera eller validera kan vara föremål för risker och kan vara svårt att implementera på ett tillförlitligt sätt. Genom att arbeta med modeller och kontinuerligt validera och verifiera varje steg i utvecklingsprocessen, kan dessa risker minimeras och systemets funktionalitet garanteras.
Vad är viktigt att tänka på vid val av processorelement för inbyggda system?
I dagens värld är inbyggda system en avgörande del av den tekniska utvecklingen, och val av rätt processorelement är grundläggande för effektivitet och funktionalitet. Dessa system är ofta designade för att hantera specifika uppgifter och operera med begränsade resurser, vilket innebär att varje beslut om komponenter och deras funktioner kan påverka systemets prestanda och pålitlighet. Det är därför viktigt att förstå de olika typerna av processorer som finns tillgängliga och deras specifika användningsområden för att kunna fatta rätt val.
För inbyggda system finns det två huvudsakliga typer av processorelement: mikrokontroller och mikroprocessorer. Mikrokontrollersystem är vanligtvis utrustade med integrerade komponenter som ADC (analog-till-digital-omvandlare), DAC (digital-till-analog-omvandlare), timers och andra funktioner som är användbara för många tillämpningar. Däremot saknar mikrokontrollersystem ofta de avancerade instruktionerna som finns i mikroprocessorer. Mikrokontroller används därför främst i system där det inte krävs en omfattande beräkningskapacitet men där det är viktigt med låg strömförbrukning och snabb respons.
Mikroprocessorer, å andra sidan, är mer kraftfulla och har ofta rika instruktioner för avancerad matematik och beräkningar, vilket gör dem användbara i applikationer som kräver mer komplex bearbetning, som grafiska system eller digital signalbehandling (DSP). Dock saknar de de inbyggda komponenterna som mikrokontroller har, vilket innebär att de ofta kräver externa komponenter för funktioner som kommunikation eller signalbearbetning.
Vid valet mellan en mikrokontroller och en mikroprocessor måste en designteam ta hänsyn till flera faktorer. En viktig övervägning är avbrottssystemet. I många inbyggda system är hantering av externa avbrott och timers kritiska för att säkerställa att systemet kan reagera på externa händelser i realtid. Mikrokontroller är ofta mer effektiva i denna aspekt eftersom de har interna timers och avbrottshantering redan integrerat. Mikroprocessorer kräver däremot externa komponenter för att hantera dessa funktioner, vilket kan leda till ökad komplexitet i systemet.
En annan viktig faktor är strömkontrollen. Många inbyggda system är designade för att arbeta under strikta strömbegränsningar, särskilt de som är batteridrivna. Mikrokontroller tenderar att ha mycket bättre strömsparfunktioner, som vilolägen och möjligheten att stänga av oönskade funktioner för att minska energiförbrukningen. Mikroprocessorer, trots sina beräkningskapaciteter, har ofta högre energiförbrukning och mindre effektiva strömsparfunktioner.
Det finns också icke-funktionella faktorer som påverkar valet av processorelement. Dessa inkluderar formfaktor (dvs. fysisk storlek på komponenterna) och tillgången till utvecklingsverktyg för mjukvaruutveckling. Utvecklingsverktygen kan spela en stor roll i hur snabbt och effektivt ett system kan designas, vilket innebär att tillgången till rätt verktyg kan vara en avgörande faktor för val av processor.
För att illustrera de olika alternativen kan man titta på två populära processorfamiljer: 8051 och Stellaris. 8051 är en klassisk mikrokontroller som är enkel och kostnadseffektiv för enklare applikationer. Stellaris, å andra sidan, representerar en mer avancerad mikrokontroller som erbjuder högre prestanda och fler funktioner, inklusive bättre strömsparlägen och inbyggda kommunikationsmoduler. Valet mellan dessa två beroende på systemets krav ger en bra översikt av de överväganden som ett designteam måste göra.
För att effektivt hantera system med flera olika moduler eller komponenter är det också viktigt att förstå starttidsproblem. När ett system består av olika moduler som måste kommunicera med varandra, kan det vara nödvändigt att noggrant analysera när olika kretsar slutar arbeta när spänningen försvagas, och om det kan få några negativa effekter på systemet. Dessa problem kan vara särskilt kritiska i applikationer där pålitlighet och realtidsrespons är avgörande.
Det är också viktigt att ha en förståelse för hur mikrocontrollersystem reagerar på externa avbrott och hanterar tidskritiska uppgifter. T.ex., om ett system ska läsa sensorer som mäter temperatur eller fuktighet, och sedan skicka den informationen till ett styrsystem, måste mikroprocessorns förmåga att hantera både sensoravläsning och kommunikation beaktas noggrant. Om det finns en möjlighet att mikroprocessorn ska gå in i en viloläge mellan avläsningarna för att spara energi, måste också den specifika processorn kunna väckas tillräckligt snabbt för att genomföra uppgiften utan fördröjning.
En annan aspekt som bör beaktas är hur mikrocontrollerbaserade system kan användas för att kontrollera och övervaka mekaniska system, exempelvis genom att mäta varvtal på ett hjul eller övervaka rotationshastighet. För att denna funktion ska fungera korrekt måste rätt timerkapacitet och interrupt-system användas för att säkerställa att varje puls eller signal från sensorer hanteras korrekt och i tid.
Endtext

Deutsch
Francais
Nederlands
Svenska
Norsk
Dansk
Suomi
Espanol
Italiano
Portugues
Magyar
Polski
Cestina
Русский