Interaktioner i ett *moderkort*!

Ptja var ska man börja nånstans?
Kan säga att i ett moderkort så finns oftast ett gäng komponenter som är standard,
då menar jag Chipset, processor, BIOS, RAM och andra viktiga kretsar,
men jag ska vara mera specifik, och har då forskat kring hur alla dess interagerar med varandra
och för att förenkla det hela, så ska moderkortet bestå av så få komponenter som möjligt
alltså istället för 4 RAM minnen så väljer jag bara 1 osv.
Så om man börjar med processorn, hur kommunicerar den med andra enheter?
Processorn jag har valt, är en Intel pentium 4 och det finns 2 varianter av den
gemensamt för bägge är att dem har 478 pins, alltså en väldigt komplicerad IC
så det krävs enhel del kopplingar för att den ska funka som det ska,
men det man kan trösta sig med är att dem flesta pins'en är inte bara massa olika signal ben utan
istället till funktion likadana som ska jordas eller tar emot spänning, vilket då förenklar designen ytterligare.
Så tillbaka till frågan, det viktigaste för processorn är att skapa kommunikation med nordbryggan
dvs skapa en trafik - en databuss, och gemensamma namnet för denna buss är FSB - front side bus,
jag vet inte om det kallas så numera, eftersom tekniken jag pratar om här är från 2003.
hursomhelst, denna buss har en viss bandbredd och bandbreddens storlek kan bestämmas av olika saker och just
bandbredd är hur snabbt data kan förflyttas, och hastigheten beror på vilken frekvens den arbetar med.
och frekvensen beror i sin tur på vilken inställning man gjort på klockgeneratorn,
så den generator jag har valt ut har 56 pin, där 2 av dessa pin bestämmer hur många mega hertz, som processorn ska jobba med
så t ex, om en av dessa pins är låg, (dvs tar inte emot nån spänning) så kommer den generera kanske 200 Mhz, vilket beror på om den kopplad till
processorn eller ej, det intressanta att notera här är att det inte är bara 1 klocksignal, utan faktist 2 som kopplas dit
och dem är kopplade på ett sätt som kallas "differential pair", som motverkar uppkomsten av störningar, typ EMI osv.
och för just denna design så har dessa ledningar krav, dvs ledningarna ska vara 5 mil bred, och mellanrummen mellan dessa 2 ska vara 11 mil
och avståndet till andra ledningar ska vara 25 mil, där "mil" är en enhet för att bedömma avstånd på ett mer bekvämare sätt.
men det finns andra störningar än bara EMI, utan störningar som kan påverka bandbredden så den blir sämre
eftersom bandbredden som sagt beror på klockfrekvensen, och FSB muliplicerar denna med 8, så blir den 800 Mhz,
men denna siffra kan påverkas negativt av "jitter" om man inte har ett speciellt filter, som kallas PLL.
sen finns andra faktorer som påverkar prestandan, såsom speciella kondensatorer som kallas avkopplingskondensatorer, som sitter runt om processorn
helst väldigt nära själva chippet, som funkar som en buffer.
Nu har jag bara pratat lite om processorn, men det känns nog, så jag har bilder på designen just nu, som är långt ifrån färdig, vilket är
dels schemat och dels PCB.
 

 

Interaktioner i Ethernet-ramen!

Har gjort lite research kring ethernet ramen och vill granska den
genom att skilja ut vad som är vad!
* om ramens header är 14 bytes(exkluderat preamble), då är 2 sista bytesen (dvs EtherType från http://en.wikipedia.org/wiki/EtherType)
intressanta om dem innehåller värdet 0x0806 så är det
ARP
* börja med ARP-paket
Detta innebär att i högre nivåer i protokoll stacken så används IP-adresser
och därför måste man accociera/adressera den unika MAC adressen(6 bytes) till
en IP-adress
Detta är jätte viktigt och som kan ses som första kommunikation sätt mellan 2 system
som handlar om request och reply, dvs ena systemet kan skapa en request dvs, broadcastar en fråga med en specifik MAC adress
och får unicast som reply.
replyen som innehåller i detta fall en IP och MAC adress kan sedan lagras temporärt i en cache
så att systemen slipper göra om ARP processen.

* om EtherType annars är 0x86DD så är det ipv6 annars om det är 0x0008 så är det ipv4
som är en 20 bytes header.
0x0008 och 10 bytes från denna finns protokollfältet och 2 bytes från detta fält finns
source adress och efter den finns Destination adress, dvs 32 bitars adresser - så man behöver en struktur
som beskriver ipv4 headerns olika element i ordning.
om protokollfältet innehåller 0x06(dvs nummer 6) så är det tcp :D
osv...
andra protokoll nummer som finns är 1 för ICMP, 17 för UDP och 2 för IGMP
* om det är ett ICMP paket så börjar ICMP headern direkt efter ipv4 headern, dvs man
kan säga att det är en payload till ipv4 :D
ICMP strukturen består av 8-bytes header, där dem första 4 bytesen är viktigaste.
dvs, 1:a byten beskriver Type, 2:a byten beskriver Code och 2 sista bytes beskriver Checksum.
type och code sammarbetar tillsammans och skapar olika kontrol medelanden.
* En typ av kontroll medelande kan skapa PING, som används för att se om en viss värddator är åtkomlig via nätverket.
en dator skickar då en echo request och väntar på en echo reply från värddatorn,
* om det är UDP paket så används en header på 8 bytes ochså och består av 4 fält dvs,
source port nummer, destination port nummer, length och checksum.
fördelen med UDP framför TCP är att det inte använder error checking och korrektur,
vilket ökar överföringshastigheterna,samt det är mkt enklare i förstå hur det fungerar.
* UDP kan användas för att implementera DHCP, som ger dynamiskt tillgång till 32-bitars ipv4 adress efter request till en server.
DHCP servern har port nummer 67 och klienten nummer 68.
* om det är ett tcp paket/segment så består dess header av 10 fält(finns några till men de är optimala)
efter headern kommer dess data, dvs dess payload.
Man kan säga att TCP operationen är uppdelad i 3 faser, dvs anslutningsfas, dataöverföringsfasen och nedkopplingsfasen.
dessa faser kan ha olika tillstånd.
* i anslutningsfasen är olika flaggor som SYN och ACK satta i speciell ordning.
dvs, först skickar klienten SYN, sen om servern går med på det skickas SYN-ACK.
klienten svarar sedan med en ACK - Detta kallas trestegshandskakning.
* Efter första fasen så kommer dataöverföringen dvs payload-data, som kan vara strömmar av HTTP ,IRC, FTP och Epost trafik osv.
För att segmenten ska hamna i rätt ordning så används ochså ett sekvens nummer som är ett av de 10 fälten.
* om det handlar om HTTP trafik, så bör man först "connecta" via tcp efter en specifik IP och port
sen om handskakningen gick på rätt sätt, så vill man uppenbarligen skicka en sträng som innehåller
en vanlig HTTP metod, tex: GET /index.html HTTP/1.1 så att man kan få filens innehåll utprintad!
* om det är IRC trafik så "connectar" man i samma princip, men strängen som man sen vill skicka är olika
för olika händelser, man kanske först vill skicka en sträng som syftar på vilken server och kanal man vill gå in på
samt vilket nick man ska ha.
Sedan när man är inne i en kanal så vill man förmodligen ochså skicka meddelande till andra som bygger på denna syntax:
PRIVMSG #Kanalnamn

Interaktioner i ett simpelt OS, men vilken väg ska man ta?!

 
 
texten annan simulering med rutor
blå fönster
initialt
***********ROADMAP*********(bildeerna visar grundläggande grafik hur det kan se ut när man gått igenom alla punkter)


1.Fixa grub + kernel (barebones?)
* Man vill installera stacken
* anropa kmain i kerneln
* göra så att den kan kommunicera med grub filerna,dvs grub kompatibel
* Man vill ochså skicka information om adresser till kerneln som argument via stacken man installerade
2.skapa först länk fil
* var nånstans i minnet vill man ladda kernel?
* vilka objekt filer ska man länka ihop till en kernel? man behöver veta kod, data och bss, ska de ligga på separat page? alltså page aligned.
* vilken är den första filen som man starta, dvs som ska funka som startup/entry? i detta fall grub.o
3.skapa en bra makefile
* vilka filer ska kompileras, både nasm och gcc
* vilka gcc och nasm kommandon behövs? tex man kan inte använda funktioner från gcc biblioteket, alltså behövs -fno-builtin och -nostdinc osv..
om man vill använda header filer i en mapp så använder man -I ./include
* make clean kommando behövs för att ta bort alla objekt o kernel filer.
* använd den skapade länk filen
4.printa ut tecken i textläget och simulera i QEMU
* skapa först funktioner så att man kan kommunicera med portar för olika kretsar och kanske lägga dessa i gemensamma "include" mappen
* gör en funktion som kan printa ut strängar, den beror på att man kan först printa ut tecken
som i sin tur beror på att man kan flytta kursorn och scrollning
att flytta kursorn beror på att man skickat rätt kommandon till vga portar.
* rensa skärmen, vilket kan vara bra så man slipper läsa allt junk som QEMU printar ut i början.        
5.fundera hur man kan skapa en printf så att text formateringen blir mer vacker
* använda sträng funktionen för att printa "varierande variablar" som kan vara hex värden konverterade från integers
* kunna bestämma vilken rad medelandet ska ligga på
6.Installera avbrottstabellen för cpun, så att man kan hantera undantag och irq
* gör en tabell struktur på 64 bits
* Hur många entrys ska den ha? dvs hur många undantag och irq fall ska den kunna hantera?
* initiera olika värden för tabellerna, tex vilken adress ska den ha till isr?
* hur laddar man in den nya tabellen till cpun?
7.fixa undantags hantering vilket är bra för debugging
* se till att cli är gemensamt för varje isr anrop
* anropa den gemensamma isr_stubben
* Denna stub sparar info om processor status(vilket måste göras i asm) innan man anropar den abstrakta avbrotts hanterar funktionen,
* i denna funktion visa undantag medelande för specifikt undantags nummer
8.lär dig hantera avbott från olika hårdvara
* Först måste man remappa PIC så att tex IRQ 0 ligger på tabell gate nummer 32 i idt
* sedan installera  hårdvaran på ett abstrakt sätt(med funktions pekare) till ett unikt IRQ nummer
* varje gång ett irq avbrott inträffar anropa gemensamma irq stubben som tar en till hanteraren
som kör isr vilket är specifikt för just hårdvaran.
* Se till att skicka "end of interupt" kommandot så att man kan fortsätta ta emot avbrott.
* kom ihåg att aktivera avbrott i huvudfilen.
9.Första hårdvaran - börja med PIT timern
* Använda kanal 0 och installera den till IRQ 0
* skapa en timer wait funktion som ska motsvara "delay" funktionen från C biblioteket
* testa att ticka ut ett medelande 1 gång varje sekund
10.fundera hur inbyggda pc speakern fungerar
* programmera om PIT kanal 0 med frekvensen 44100Hz
* använd timer wait funktionen för att inte göra någoting,dvs tystnad
* skapa ljud genom att sätta bit 0 av port 0x61
11.skriv ut info om cpu(hastighet och vendor)
* Använda PIT för att beräkna cpu hastigheten så bör man veta hur många klockcykler en viss mängd kod tog.   
* för att ta reda på CPU Vendor ID String så använder man cpuid instruktionen, därför bör
man kolla upp om den fungerar, strängen lagras EBX, EDX och ECX
12.gör en simpel tangentbords drivrutin (brans osdever.net?)
* Första måste man hämta scankoden från tangentbordet, vanligtvis via porten 0x60 dataregistret
* Sedan kontrollera om knappen släppts
* Sedan omvandla scankoden till ascii kod och skriver ut det till skärmen
13.Ordna RAM minnet med paging aktiverat, så att man får mer koll och ordning på vad som är vad. (james molloy?)
* skapa en page katalog(4kb stor) med 1024 page tabeller(ochså 4kb stor) som i sin tur innehåller 1024 pages, vilket täcker hela ram minnet på 4gb
* varje page har en 32 bitars(word) descriptor, 20 bitar av den innehåller frame adressen, övriga beskriver egenskaper hos page'n, tex om den är present eller ej
* alltså måste man loopa igenom RAM minnet efter första bästa pages som är 'present', man returnar sedan adressen från denna frame till allokeringsfunktionen.    
* sedan bitställer man den till vår via en bitset funktion, och nu är pagen "våran"
* sedan scanna av hela page katalogen efter fria page, eller specifika med 'get_page'(mappar) funktionen som parameter till allokering.
* sedan enkla kvar är det bara att aktivera paging via asm och installera pagefault hanteraren.
14.Fixa nu heapen som kan tänka sig vara en utökning på hur man hanterar minnet.
* definera en index lista som är en array karta, kanske man kalla det
* nu skapa heap funktionen som anropas i paging modulen(efter att man allokerar frames till den)
den ska en mängd argument,den ska anropa index listan som vi skapade, den ska ha satser som skapar ett stort hål som man sedan
matar in array indexet, returnera sedan hela heap strukturen som sista steg.
* Nu kan man använda sig av funktionen som allokerar dynamiskt minne från heapen vi skapade
denna funktion ska bla först leta efter det minsta passande hålet till minnet man requesta.
så man anropar en funktion itererar genom listan utifrån minnet storleken man behöver
o returnerar ett index nummer.
Detta nummer kan vara felaktigt så därför behöver man "error checking"
annars ska man dela upp hålet man hittade i 2 delar?
Sedan ska minnet man efterfrågar vara "page aligned"?
* Nu måste man fixa free funktionen så att naivt sätt gör om blocket till ett hål igen.
genom att använda unifierings principen.
15.Gör ett filsystem som man laddar som modul till grub, använd modulen för att lista tex innehåll i en textfil
* initrd modulen skrivs i C och använder stdio bibliotek
* ladda modulen genom att hämta den från multiboot struktur
den innehåller adressen till den vill säga
* installera sedan initrd
* scanna igenom initrd efter noder, är det en katalog eller textfil?
är det textfil, loopa igenom och printa ut innehållet.
16.skapa ett kommandoskal (cake os? :D)
* fixa strcmp funktionen
* Vilka kommandon ska få vara med? ls för att lista noder
sedan cat för att lista en textfil
clear för att "spaca" skärmen osv...
17.Fundera på hur multitaskingen ska fungera, ska man spara task strukturer i en singel länkad lista? hur tar man sig till usermode?(prettyos (task.c rev 151))
* skapa en task funktion som skapar en ny stack som hanterar både ring0 och ring3
* switcha till denna task genom att byta till taskens page katalog och ändra på tss stack värden
sedan returnera den nya stacken pekare vidare till irq hanteraren
18.Kommunicera med ring 0 via systemanrop
* vilka system anrop behövs för usermode? så att man kan använda sig av högre priviligerade instruktioner
19.Dela upp textläget i olika konsoller.(prettyos console.c rev 286)
* genom att allokera strukt för specifikt text område
sedan använder man struktur medlemmarna när man anropar funktioner
20.Gör en speciell task som kan switcha grafik läge,
* modifiera task funktionen så att när den anropas switchar till v86 läge
* GDT fungerar inte i V86 men paging fungerar, vilket innebär att man kan ha koden varsomhelst
i fysiska minnet.
den är känslig för IOPL instruktioner, dvs om IOPL<3 så ändras EFLAGS:IF
vilket leder till GPF som hanteras av kerneln.
V86 kod körs i ring 3 och den använder IDT ochså
motsatsen till EFLAGS.VM är EFLAGS.IF funktionellt sätt
(VM tar en in i v86 medan IF tar en ut till kernel)
Man hamnar i v86 när man poppar bla VM flaggan från stacken
* skapa en GPF hanterare i IRQ filen som tar emot IOPL<3 instruktioner, tex INT instruktionen
* Nu när man kan switcha läge och hantera viktiga instruktioner så kan man börja med
att byta grafik läge till VESA.
Först så måste man se till att hela asm koden för BIOS funktioner laddas in i RAM på nån adress, vilket man gör med memcpy funktionen.
sedan vill man att task-funktionen ska byta EIP till en adress(nånstans där man specifiera med
med memcpy) genom att anropa entry för just den funktion som finns i asm filen där
man växlar grafik läge, sen kan det ochså vara nödvändigt att specifiera upplösningen.
* Sedan gäller det att allokera pages till just där VESA pekar mot, detta beror ju förstås på hur mkt total minne som behövs.

En förenklad bild över mitt senaste projekt!

 
Här är komponenterna jag har beställt för bygget!
 
 
          
Man ska antingen kunna skicka kommandon i realtid till radio mottagaren via en sändare genom PPM
oftast så ligger frekvensen runt 2.4 Ghz eller så vill man att
trikoptern ska förflytta sig enligt förprogrammerade kommandon, dvs den blir autonom.

Källkoden laddar man upp via USB interfacet till arduinon som är kopplad till en PC.
Man kan antingen använda en FTDI kabel som usb interface, eller ett chipad alternativ.
För att hålla trikoptern stabil dvs horisontell i luften så estimerar IMU detta, bestående av
gyroskop och accelerometeter som kommer från WII spelet. Man vill att dessa sensorer ska kunna skicka
mätetal från alla riktningar via protokollet I2C som omvandlas via ADC, så att MCU'n kan korrigera balansen genom att skicka
kommdandon via PWM till ESC som respons av detta som i sin tur reglerar RPM för motorerna.
Sedan ska man kunna med hjälp av en PID regulator, reglera vilket "mode" den ska ha, dvs hur
effektiv stabiliseringen ska vara.
Om man antar att farkosten har setpoint vid horisontellt läge, då vill man alltså att mätdata från IMU sensorerna ska vara lika med setpoint, men tyvärr är det inte så i verkligheten utan det skapas error värden
då man subtraherar setpoint med sensordatan. Det är då PID kommer in i bilden!
Enligt min uppfattning så verkar det som att man "tunar" PID variablerna för att få error värden = 0.

Jag vill ochså att den ska ha GPS för autonom körning, samt att den ska vara FPV.
Som framtida uppgraderingar så vill jag då att den ska ha en HD-kamera.
Eftersom det är en trikopter det handlar om, alltså med bara tre propeller, så behövs
ochså en servo som justerar tiltandet av svans-propellen så att koptern kan yaw'a.
Annars så har jag tänkt mig att kroppen ska bestå av plywood och armarna ska vara av carbon fiber material.
Skruvar och kontakter fixar jag då jag fått hem alla "stora" komponenter.
Totala kostnaden för allt blir runt 1750 kr exkluderat frakt och radiokontroller/sändare.



Interaktioner mellan kretsar i en mobiltelefon!

Vill kunna förstå abstraktionerna i en mobiltelefon, dvs. interaktionerna mellan kretsarna

Därför skrev jag denna text.


Jag börjar med inte allt för hög zoom på komponenterna och sen dyker vi in på detalj nivå.
En mobils huvudsakliga funktion är att lyssna med hjälp av en antenn efter radiovågor.
Själva antennen har inte så stor räckvidd utan signalen boostas med hjälp av basstationer som växlar den vidare.
Signalen som induceras är antagligen analog och samplas dvs. görs om så att IC kretsen
förstår den. Vidare skickas signalen ut till högtalaren som avger ljudvågor, låter kanske som en radio apparat,
men den här enheten eller GSM modulen som den också kallas lyssnar bara efter vissa frekvenser typ 900 MHz. Ju
högre frekvensen blir desto fler basstationer krävs för att underhålla kommunikationen.
Men hur social är den här kretsen då? Jo, den kommunicerar med annan krets via ett
protokoll som kallas UART, på så vis att GSM modulen tar emot speciella AT-kommandon som exempelvis handlar om
att skicka sms, göra röstsamtal, kolla status, m.m.  Den här komponenten som skickar dessa kommandon är faktiskt
en mikroprocessor och mer än så, det är mikrokontroller som inte bara har en beräkningsenhet utan också bl.a.
ram och flashminne. Flashminnet är programmerbart, dvs. man kan mata det med instruktioner från ett
programmerings- interface. Eftersom MCUer i regel inte har så mkt programminne, kan man externt koppla in ett extra flashminne.
Eftersom MCUn (mikrokontrollerenheten) kan vara ifrån Microship så har den RISC,
alltså reducerat antal instruktioner som man kan interfaca den med, vilket underlättar
kodandet. Förutom att den är programmeringsbar så innehåller den många I/O portar som
gör att den kan skicka och ta emot data utan något speciellt protokoll, i
mobilapplikationen kan det vara i form av tryckknappar. Men hur visualiserar man
det man gör beroende på vilket input man ger? Därför behövs display av någon typ, i vanliga fall är
det en LCD baserad på pixlar. Den kan kommunicera med MCU via ett annat seriellt protokoll, nämligen
SPI. Skillnaden mellan UART och SPI är att den senare behöver en klocka att jobba med. Klockfrekvensen
genereras antingen internt eller externt kopplad till MCU. Ju högre desto bättre bildkvalitet.
Oftast har MCUn en funktion för att multiplicera frekvensen som kallas PLL, men man
får passa sig eftersom displayen kanske inte klarar hög frekvens av fyrkantsvågen.
För att exempelvis plotta ut en bild på displayen efter ett givet knapp tryck,
så bör man först installera en liten drivrutin för styrkretsen som finns runtomkring
displayen. Denna drivrutin helt enkelt sätter igång LCDn så den blir mottaglig för kommandon och data.
Man bör också installera knapparna så att MCUn kan lyssna efter events (händelser)
från dem via sin input portar. Sedan är det bara att skicka kommando och efterföljande data.
Så här kan det gå till:

Knapp trycks ner orsakar binär etta som är en spänning puls av 5 volt.
MCUn reagerar på det och som konsekvens hoppar programräknaren och pekar
på de instruktioner som finns på vissa adresser i flashminnet som man vill
exekvera. Instruktioner skickas sedan till en multiplexer som omvandlar de
från parallell format till seriellt för att sedan komma till ALU där de
beräknas antingen logiskt eller aritmetiskt. Resultaten lagras i ackumulatorn
och sedan hamnar de i MCUns portregister för att sedan skickas ut till dess
portpinnar. Dessa portpinnar är konfigurerade som SPI, alltså skickas datan
i seriell ordning med en viss klockfrekvens. Datan består av binära koder
som först beskriver hur stor bilden ska vara och vilken position den ska ha.
Resten av koden består av en stor arraydata som beskriver hur bilden ska se ut.
Mottagaren, alltså styrkretsen för LCDn, som är en slav, lagrar datan i sitt
RAM och pixelrenderingen börjar vanligtvis från vänster hörn längst upp och fortsätter ner tills hela displayenär fylld.

RSS 2.0