Embedded Linux-bok
Embedded Linux-bok
Kan någon rekomendera en bok som är up-to-date och fokuserar på Linux med inriktning mot inbyggda system, realtidsprocesser, drivrutiner, hårdvarunära programmering etc? Vore kul att göra en djupdykning och inte bara skriva program som körs i user-miljö.
Undrar vilken typ av nördskada det tyder på 
Oj då, gratis är ju inte helt fel. Och att det dessutom är för 2.6 är ju riktigt bra. Den där boken i kombination med LFS (Linux From Scratch) kanske räcker för att man ska klara sig ganska långt. Sen lär man ju kunna kolla mer på hur man gör olika optimeringar osv i kernelen och ränsar bort grejer som inte behövs.
Webbaserade gratis Embedded Linux kurser:
Försöker väcka tråden igen, med lite webbaserade kurser i Embedded Linux. Letar också efter någon bra lärarledd kurs, har hittat på Init och Enea, men det borde finnas fler? Problemet med böcker i detta ämne borde annars vara att de blir ganska kvickt föråldrade?
Webbaserade gratis Embedded Linux kurser:
CNW Consulting Network AB
http://cmsms.cnw.se/index.php?page=embe ... s&hl=sv_SE
Free-Electrons
http://free-electrons.com/docs/kernel/
ENEA
http://www.enea.com/templates/Extension____24705.aspx
Webbaserade gratis Embedded Linux kurser:
CNW Consulting Network AB
http://cmsms.cnw.se/index.php?page=embe ... s&hl=sv_SE
Free-Electrons
http://free-electrons.com/docs/kernel/
ENEA
http://www.enea.com/templates/Extension____24705.aspx
Re: Embedded Linux-bok
Nu är jag ju partisk i frågorna om lärarledda embedded linuxkurser och bara fått en privat snabbversion av Eneas grundkurs. Men jag tycker den är bra upplagd med bra kursmaterial.
Och våra lärare är kunniga...
Nu ska jag sluta göra reklam
chille: ja det är ett tillägg, men nä jag har ingen hands on på just det...
Och våra lärare är kunniga...
Nu ska jag sluta göra reklam
chille: ja det är ett tillägg, men nä jag har ingen hands on på just det...
Re: Embedded Linux-bok
Kan nämna att jag gjorde en stegmotorstyring med en linuxdriver, där jag utgick från ett exempel från ovan nämnda bok, Corbet&Rubini, för några år sedan. Char-drivers. Kernel 2.4.
Den gick att köra upp till ca 3 kHz mot avbrott från parallellporten, alltså ett par tiopotenser snabbare än user-mode. Körkommando från perlskripter i user-mode.
Det tog väl någon vecka att komma igång, men sedan gick det smidigt.
Som jämförelse kan jag säga att det nog är lite lättare att göra motsvarande med separat mikroprocessor(AVR), i alla fall så länge mikroprocessorn går autonomt. Om den skall kommunicera med PCn kan det kanske gå på ett ut.
Den gick att köra upp till ca 3 kHz mot avbrott från parallellporten, alltså ett par tiopotenser snabbare än user-mode. Körkommando från perlskripter i user-mode.
Det tog väl någon vecka att komma igång, men sedan gick det smidigt.
Som jämförelse kan jag säga att det nog är lite lättare att göra motsvarande med separat mikroprocessor(AVR), i alla fall så länge mikroprocessorn går autonomt. Om den skall kommunicera med PCn kan det kanske gå på ett ut.
Senast redigerad av SvenW 28 januari 2009, 10:02:18, redigerad totalt 1 gång.
Re: Embedded Linux-bok
Problemen med realtidsprestanda i Linux äro många tyvärr.
För det första så är det i regel inte ett tillägg, utan flera, och dessa hamnar rätt ofta på nåt arkitekturspecifikt i slutänden. Så realtid handlar en hel del om vilken arkitektur man vill köra. x86 kommer nog alltid ha bäst stöd. PowerPC ska ha rätt bra stöd, men jag har aldrig testat. Jag har mest kört Linux på Atmels ARM9, och där är det ju lite sådär kan man säga. Så länge man inte pröjsar för en realtidskärna så är det åtminstone ett jävla fippel innan det funkar, om det funkar. Pröjsar man så kan det mycket väl funka, men man får se till att ha stora plånboken med sig, om man inte lyckas hitta nån "evaluation" nånstans. Realtidsprestandan med "vanilla"-kärna på Atmels ARM9 är lite sådär, någon hård realtid i mikrosekundklass hade iaf inte uppenbarat sig senast jag pysslade med sånt. Skiter man i realtidsprestandan, åtminstone hård realtid, så funkar Atmels grejer bra, både Arm och AVR32. Den senare är dessutom billig i form av utvecklingskort, som ju annars brukar kosta som ett helt gäng skjortor.
En annan skola är att köra ett litet OS som i sin tur kör dels Linux, dels dina realtidstrådar. Kommer inte på nåt bra exempel, men tänk ut ett fånigt namn med "microkernel" med nånstans så hittar du säkert nåt.
En tredje variant är att försöka göra kärnan så pass duktig att den kan schemalägga en usermode-process så pass deterministiskt snabbt att man fortsätta som vanligt, med drivare för att hantera hårdvaran, och usermode-processer för att använda sagda hårdvara. Med den fantastiska nya egenskapen att saker och ting faktiskt går att lita på, tidsmässigt. Dock blir det ju alltid fler hopp mellan kernelmode och usermode med en sån taktik.
Personligen så får jag lite utslag av första och andra alternativet. Det är väl å andra sidan dom som uppvisar bäst prestanda i praktiken. Skulle tippa på att dom slutat i ett och annat magsår också. Vad gäller det tredje så vill jag minnas att det har funnits benchmarks på x86 med worst case runt 50 mikrosekunder på en 1GHz, och det är ju rätt bra för att vara grejtiss. Vet inte om nån annan arkitektur kommit ikapp, det vore ju kanske mer intressant med en Arm eller en PowerPC än x86 i de flesta lägen, innan Atomen blir var ingenjörs egendom iaf.
Det var ett tag sen jag grottade i det här, och det fanns egentligen aldrig tid mer än för att konstatera att realtidsprestandan inte var alldeles mogen på den plattform det gällde då, så ta det med en matsked salt. Nån bra bok har jag egentligen aldrig hittat, det finns kanske nån vettig bok om inbyggda system och linux, men nåt som är aktuellt och handlar om realtidslinux har jag inte sett. Vill du bara skriva drivare så är O'Reillys LDD bra, men inte helt aktuell överallt. Har du väl kommit så långt att du börjat knappa så märker du dock snart vad som inte stämmer, och du har dessutom hunnit komma på var du ska titta för att se vad som gäller nu.
För det första så är det i regel inte ett tillägg, utan flera, och dessa hamnar rätt ofta på nåt arkitekturspecifikt i slutänden. Så realtid handlar en hel del om vilken arkitektur man vill köra. x86 kommer nog alltid ha bäst stöd. PowerPC ska ha rätt bra stöd, men jag har aldrig testat. Jag har mest kört Linux på Atmels ARM9, och där är det ju lite sådär kan man säga. Så länge man inte pröjsar för en realtidskärna så är det åtminstone ett jävla fippel innan det funkar, om det funkar. Pröjsar man så kan det mycket väl funka, men man får se till att ha stora plånboken med sig, om man inte lyckas hitta nån "evaluation" nånstans. Realtidsprestandan med "vanilla"-kärna på Atmels ARM9 är lite sådär, någon hård realtid i mikrosekundklass hade iaf inte uppenbarat sig senast jag pysslade med sånt. Skiter man i realtidsprestandan, åtminstone hård realtid, så funkar Atmels grejer bra, både Arm och AVR32. Den senare är dessutom billig i form av utvecklingskort, som ju annars brukar kosta som ett helt gäng skjortor.
Om du med detta menar realtidstrådar, så ska man nog vara medveten om att det finns flera skolor här. Dels kan man satsa på att köra trådar i kärnan, i vanliga moduler egentligen, men med nån typ av tillagt API för att göra det. RTAI funkar så. Går att göra utan tillägg också, men då hamnar det nog mest i kategorin fulhack, och jag tror inte du får med det på kernel.org iaf.... och inte bara skriva program som körs i user-miljö.
En annan skola är att köra ett litet OS som i sin tur kör dels Linux, dels dina realtidstrådar. Kommer inte på nåt bra exempel, men tänk ut ett fånigt namn med "microkernel" med nånstans så hittar du säkert nåt.
En tredje variant är att försöka göra kärnan så pass duktig att den kan schemalägga en usermode-process så pass deterministiskt snabbt att man fortsätta som vanligt, med drivare för att hantera hårdvaran, och usermode-processer för att använda sagda hårdvara. Med den fantastiska nya egenskapen att saker och ting faktiskt går att lita på, tidsmässigt. Dock blir det ju alltid fler hopp mellan kernelmode och usermode med en sån taktik.
Personligen så får jag lite utslag av första och andra alternativet. Det är väl å andra sidan dom som uppvisar bäst prestanda i praktiken. Skulle tippa på att dom slutat i ett och annat magsår också. Vad gäller det tredje så vill jag minnas att det har funnits benchmarks på x86 med worst case runt 50 mikrosekunder på en 1GHz, och det är ju rätt bra för att vara grejtiss. Vet inte om nån annan arkitektur kommit ikapp, det vore ju kanske mer intressant med en Arm eller en PowerPC än x86 i de flesta lägen, innan Atomen blir var ingenjörs egendom iaf.
Det var ett tag sen jag grottade i det här, och det fanns egentligen aldrig tid mer än för att konstatera att realtidsprestandan inte var alldeles mogen på den plattform det gällde då, så ta det med en matsked salt. Nån bra bok har jag egentligen aldrig hittat, det finns kanske nån vettig bok om inbyggda system och linux, men nåt som är aktuellt och handlar om realtidslinux har jag inte sett. Vill du bara skriva drivare så är O'Reillys LDD bra, men inte helt aktuell överallt. Har du väl kommit så långt att du börjat knappa så märker du dock snart vad som inte stämmer, och du har dessutom hunnit komma på var du ska titta för att se vad som gäller nu.
Re: Embedded Linux-bok
Finns det någon defacto-standard för vad som definierar realtidsprestanda?
Re: Embedded Linux-bok
Njae, det kan man väl inte säga, jag tycker inte det iaf. För mig handlar realtidsprestanda mer om spridning än om absoluta värden. Mjuk realtid kan man väl säga handlar om saker som inte är farliga, och där är det väl intressant att svarstider hamnar under en viss gräns i 99% av fallen, eller 99.9% osv. Hård realtid handlar enligt min mening enbart om det sämsta fallet, att vad som än händer så hamnar svarstiden aldrig över en viss gräns. Var man sen sätter gränsen beror på applikationen, och sen får man välja den plattform som klarar den satta gränsen.
Jag har en bestämd känsla av att jag läst den där benchmarken om x86, men jag vet inte var, och jag får inte vara uppe längre nu så jag kan inte leta på den. Men 50 mikrosekunder i Linux är jävligt snabbt, om det handlar om worst case. För en ARM9 (180 MHz) hamnade kravet i en applikation jag känner till på 0.5-1 millisekund, och det klarade inte vanilla-kärnan då, ca 2-3 år sen. Jag har inte testat nåt nyligen, men jag skulle bli glatt överraskad om kärnan klarade det nu. Fyll i, den som vet!
Jag har en bestämd känsla av att jag läst den där benchmarken om x86, men jag vet inte var, och jag får inte vara uppe längre nu så jag kan inte leta på den. Men 50 mikrosekunder i Linux är jävligt snabbt, om det handlar om worst case. För en ARM9 (180 MHz) hamnade kravet i en applikation jag känner till på 0.5-1 millisekund, och det klarade inte vanilla-kärnan då, ca 2-3 år sen. Jag har inte testat nåt nyligen, men jag skulle bli glatt överraskad om kärnan klarade det nu. Fyll i, den som vet!
Re: Embedded Linux-bok
På nyare FreeBSD/Linux versioner går det visst att byte schedulern som modul. Så då borde det gå att modifiera den för att hantera ens egna realtids "trådar".
För mig är realtid, när man vet att t.ex. en insignal besvaras inom maximalt X µs. Kan vara rätt bra om man hanterar någon form av reglering
För mig är realtid, när man vet att t.ex. en insignal besvaras inom maximalt X µs. Kan vara rätt bra om man hanterar någon form av reglering
