Forum Mjukvara Linux och övriga operativsystem Tråd Inlägg

Kompilera en egen kernel för Raspberry

1
Skriv svar
Permalänk
Medlem
●

Kompilera en egen kernel för Raspberry

Är det någon som har erfarenhet av att kompilera egna kernels för raspberry?

Jag har planer på att köra en raspberry för att använda flera dallas sensorer och mäta temperaturer i olika soner.

Men för att göra detta vill jag ha varje temp sensor på en egen ingång på GPIO. Istället för att lägga dem i serie på samma ingång.

Vad jag har förstått så ligger det något i kernel på rapian som gör att den snackar one wire protocol på en pin, men att det lika gärna kan kompileras om och man kan lägga samma protokoll på flera pins.

Mer än så vet jag inte, men hur stor är kunskapskravet för att man skall få till det? Är det elite-asembler-proffs eller klarar en average linux användare av det?

Mycket tacksam för svar från er som har lite koll på saker!

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av goodfidelity:

Är det någon som har erfarenhet av att kompilera egna kernels för raspberry?

Jag har planer på att köra en raspberry för att använda flera dallas sensorer och mäta temperaturer i olika soner.

Men för att göra detta vill jag ha varje temp sensor på en egen ingång på GPIO. Istället för att lägga dem i serie på samma ingång.

Vad jag har förstått så ligger det något i kernel på rapian som gör att den snackar one wire protocol på en pin, men att det lika gärna kan kompileras om och man kan lägga samma protokoll på flera pins.

Mer än så vet jag inte, men hur stor är kunskapskravet för att man skall få till det? Är det elite-asembler-proffs eller klarar en average linux användare av det?

Mycket tacksam för svar från er som har lite koll på saker!

Gå till inlägget

En average dude kan få det att fungera. Jag har (dock inte just för Raspberry, men för mer obskyra plattformar)

Däremot, om du tänker korskompilera (vilket jag antar att du gör, dvs att du kompilerar kärnan för ARM från en x86-plattform) så kan det vara meck med att få i gång toolchainen. Men det lär finnas dokumenterat på internet (till exempel här). Annars kan du självklart kompilera direkt från Pien i fråga - det tar bara lite längre tid.

Men nu till min egentliga fråga: Hela vitsen med 1-wire-protokollet är just att det ska vara en tråd (och gemensam jord). Varför dela upp pinnarna? Vad är det du vill åstadkomma? Näten ska klara ruggigt många noder (kör 40-talet hos farsan).

Visa signatur

Jag är en optimist; det är aldrig så dåligt så att det inte kan bli sämre.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Jag önskar egentligen endast att ändra på existerande kernel, dvs lägga till one wire protokollet på flera portar och köra precis så som det är annars. Funkar ju fint med drivers och så då.

Anledningen att jag vill ha en modul på varje pinne är följande:

Protokollet adresserar med långa adresser, om man skall sätta upp ett stort nätverk av flera enheter så är det väldigt omstänigt att hålla reda på flera olika adresser. Om man dessutom skall låta kunder installera det själv så kan man absolut inte kräva att kunden ens skall förstå hur detta fungerar..

Om man däremot har en helt vanlig TP kabel så kan man ju bära signal från 6 olika enheter på en TP kabel. Och alla har sin egen kanal att prata på på raspberry. Då kan man ha en kanal som heter exempelvis garage, en som heter kök, en som heter vardagsrum, en som heter osv.. Så behöver man bara förhålla sig till att använda rätt kanal.

Det blir fort väldigt mycket kodande annars när man skall identifiera exempelvis 6 olika temp sensorer efter ett långt nummer-ID. Och sedan om man har gjort 50 installationer så är det ganska mycket slöseri på tid att göra på det sättet. Enklare att lägga ner lite extra tid i början

Sedan är det också så att vissa one wire moduler inte kan samarbeta på samma nätverk, de klarar bara av en modul på ett nätverk. Tror att DHT22 är en sådan. För att då mäta temperatur och luftfuktighet i flera olika områden så måste man ha flera kanaler att skicka informationen på.

Jag gillar iden av att ha flera sensorer på en wire, och det är ju lite det som är poängen med systmet. Men det gör ju också att man måste lägga väldigt mycket tid på att identifiera varje sensor och lagra infon någonstans för varje sensor man installerar. Och ännu mer problem blir det dagen man måste byta ut en sensor för att den är trasig.

Om man då har baserat ID på sensor ID i en databas så är det helt plötsligt ett nytt sensor ID där, och då får man ingen kontinuitet på mätdatan. Om man istället har BUS ID eller kanal ID i databasen så kan man montera nya sensorer med andra IDn utan att det blir några problem.

Vad är det för spännande du loggar hos farsan med 40 olika mätpunkter? Det låter som en stort projekt

//GF

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Men att det är långa adresser löser du ju inte så bra med att begränsa antalet enheter till en per port.

Jag bygger nätet, håller handen kring en sensor, och läser av alla och den som ligger närmast 37 är troligen den jag håller i

Därefter är det bara att symlinka eller, om man använder ex. Domoticz, döpa om till ex. Garage, frysbox eller vad det nu kan vara.

Fast nu börjar du blanda äpplen och päron: one wire och 1-wire är inte riktigt samma sak. 1-wire är ett protokoll framtaget av Dallas/Maxim. DHT22 använder en tråd för kommunikation men är inte ens i närheten av kompatibelt med 1-wire (så du kan inte använda w1-gpiomodulen för DHT22). Däremot kan du använda exempelvis den här för att mäta luftfuktighet mha 1-wire. Följer enheten 1-wireprotokollet kan du använda många, då är begränsningen ström och nätlayout.

Det är väl ganska lätt att byta enhet? Notera vilket ID som försvinner och vilket som dyker upp när man kopplar i och ur, och justera i sin grafritning. Piece of cake. I din databas bör du alltså inte ha sensorIDt som nyckel, utan något annat.

Hos farsan mäts allt möjligt, tillexempel frysboxen (med larm om det blir för varmt), utomhustemperaturen (styr motorvärmarna på vintern), växthuset, en liten stuga där vi kan fjärrställa önskad temperatur (står en elradiator som styrs med hjälp av en Nextabrytare, tellstick, och mätvärden från temperaturgivaren).

Skrivet av goodfidelity:

Jag önskar egentligen endast att ändra på existerande kernel, dvs lägga till one wire protokollet på flera portar och köra precis så som det är annars. Funkar ju fint med drivers och så då.

Anledningen att jag vill ha en modul på varje pinne är följande:

Protokollet adresserar med långa adresser, om man skall sätta upp ett stort nätverk av flera enheter så är det väldigt omstänigt att hålla reda på flera olika adresser. Om man dessutom skall låta kunder installera det själv så kan man absolut inte kräva att kunden ens skall förstå hur detta fungerar..

Om man däremot har en helt vanlig TP kabel så kan man ju bära signal från 6 olika enheter på en TP kabel. Och alla har sin egen kanal att prata på på raspberry. Då kan man ha en kanal som heter exempelvis garage, en som heter kök, en som heter vardagsrum, en som heter osv.. Så behöver man bara förhålla sig till att använda rätt kanal.

Det blir fort väldigt mycket kodande annars när man skall identifiera exempelvis 6 olika temp sensorer efter ett långt nummer-ID. Och sedan om man har gjort 50 installationer så är det ganska mycket slöseri på tid att göra på det sättet. Enklare att lägga ner lite extra tid i början

Sedan är det också så att vissa one wire moduler inte kan samarbeta på samma nätverk, de klarar bara av en modul på ett nätverk. Tror att DHT22 är en sådan. För att då mäta temperatur och luftfuktighet i flera olika områden så måste man ha flera kanaler att skicka informationen på.

Jag gillar iden av att ha flera sensorer på en wire, och det är ju lite det som är poängen med systmet. Men det gör ju också att man måste lägga väldigt mycket tid på att identifiera varje sensor och lagra infon någonstans för varje sensor man installerar. Och ännu mer problem blir det dagen man måste byta ut en sensor för att den är trasig.

Om man då har baserat ID på sensor ID i en databas så är det helt plötsligt ett nytt sensor ID där, och då får man ingen kontinuitet på mätdatan. Om man istället har BUS ID eller kanal ID i databasen så kan man montera nya sensorer med andra IDn utan att det blir några problem.

Vad är det för spännande du loggar hos farsan med 40 olika mätpunkter? Det låter som en stort projekt

//GF

Gå till inlägget
Visa signatur

Jag är en optimist; det är aldrig så dåligt så att det inte kan bli sämre.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Jag förstår hur du tänker, tyvärr är ditt sätt att tänka jättebra för hemmaanvändare som bygger ett system som de själva skall underhålla. Men helt 100% oanvändbart för något som skall användas kommersiellt eller säljas.

Om man behöver mer än läskunnighet för att installera något så är det oanvändbart för 99.9% av befolkningen. För att kunna nå en större grupp så måste man förenkla installationerna.

Därför skall man ha en ingång för varje sensor, utan behov för att göra någon justering alls vid utbyten. Information skall automatiskt hitta till rätt ställen i databasen, helt utan användarens ingrepp på någon annan nivå än den fysiska.

Det skall inte behövas några förändringar alls i mjukvaran när man kopplar till eller från eller byter ut sensorer. Det skall bara fungera helt automatiskt.

Detta kan man endast få till genom att göra som jag beskriver, dvs använda en ingång för varje sensor, och sedan lagra data i databasen efter vilken port det kommer ifrån och inte efter vilket ID sensorn har. Metoden är överlägsen ur ett användarperspektiv.

Tänk dig om supportavdelningen skulle få ett telefonsamtal på 20 minuter varje gång någon vill byta eller koppla in en ny temperatursensor.. Eller om man måste skicka ut en tekniker. Det skulle bli en ganska dyr produkt.

Vidare så är sensorn på m.nu alldeles för dyr. Jag kan inte förstå hur någon betalar 500:- för den. Den skall kosta 50:- och inte mer. En Dallas sensor kostar typ 20:- med kabel och kapsling, en DHT22 tippar jag kostar 50:-, det är länge sedan jag köpte mina.

Att kunna koppla dessa rakt in på en raspberry är vida överlägset att använda modulen du länkar till. För det prisen kan man ju lika gärna använda en raspberry för varje mätpunkt, priset blir ju detsamma.

Det är lite annorlunda när man skall bygga en produkt för hundratals användare än när man skall bygga något för sitt eget bruk.

Min produkt är avsedd att övervaka pulser, av/på signaler och temperaturer och redovisa detta på en hemsida väldigt enkelt och ha möjlighet att skicka PUSH signaler. Ungefär som du beskriver systemet du byggt upp.

Det låter sjukt kul hur du fixat allt hos din far. Jag tycke raspberry är en fantastisk produkt som verkligen gör mycket möjligt. Nu gäller det bara att brygga gapet till människor som bara vill koppla in strömmen och köra

Redigera
Citera flera Citera
1
Skriv svar
Senaste nyheterna
Hårdvara
Mjukvara
Övrigt
Nytt i forumet
Datorkomponenter
System
Ljud, bild och kommunikation
Spel och mjukvara