Raspberry Pi CPU -lastindikator: 13 trinn

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:20

Når du kjører Raspberry Pi (RPI) som hodeløs uten konsollmonitor, er ingen spesifikke visuelle indikasjoner tilgjengelig for å gjenkjenne at RPI faktisk gjør noe.

Selv om ekstern terminal brukes med SSH, er det nødvendig med kjøring av Linux -kommando av og til for å kontrollere hvor mye systembelastning som belaster CPU nå

Så denne kretsen er laget for å hjelpe med å gjenkjenne den virkelige aktiviteten til CPU (kanskje semi-reell eller nær ekte måte) for å utføre systembelastninger som brukes nå.

Selv om bare pythonprogrammering og mye enklere krets kan støtte den samme funksjonaliteten, vil det kreves litt komplekse pythonkoder for å simulere den sofistikerte LED -kontrolllogikken som kreves av denne kretsen.

Paradoksalt nok vil også kompleksiteten til python -koden belaste CPU mer med økt systembelastning.

Derfor vil det være rimelig å laste ned alle indikasjonsfunksjoner så mye som mulig til ekstern maskinvarekrets, siden denne tjenesten bør kjøre hele tiden og ofte, for eksempel hvert femte sekund.

Og denne kretsen vil legge til en litt morsom funksjon for hodeløst kjørende RPI.

Trinn 1: CPU Load Checking Linux Command

Det er forskjellige CPU -belastningskontroll Linux -kommandoer er tilgjengelige, for eksempel top, iostat, sysstat og oppetid.

Hver kommando har spesifikke fordelaktige funksjoner når det gjelder informasjonsmangfold og viser enkelhet.

Toppkommando er den mest informasjonsrike og svært detaljert data er tilgjengelig for umiddelbart å gjenkjenne systembelastning.

Men den fungerer som iterasjonsmodus (viser data kontinuerlig på skjermen) og informasjonsformat er ganske komplisert for å trekke ut bare nødvendige CPU -lastdata ganske enkelt.

Kommandoen iostat gir grundig systembelastningsinformasjon ved å skille bruker- og systemkjøringskøjobber som belaster CPU for tiden.

Men det er også unødvendig komplisert å få gjeldende CPU -belastning som rask og intuitiv måte.

Ved oppetid er veldig enkle systembelastningsdata tilgjengelig på 1 minutt gjennomsnitt, 5 minutter gjennomsnitt og 15 minutter oppsummert gjennomsnitt.

Som nevnt ovenfor er det nødvendig å forenkle python -koden fordi den bør utføres ganske ofte, for eksempel hvert 5 sekund eller 10 sekund.

Når python -koden blir kompleks, vil den belaste CPU mye.

Det er et slags paradoks at du belaster RPI for å overvåke systembelastningen.

Derfor velger jeg oppetidskommando for å samle CPU -belastning og samhandle med indikatorkrets fordi det er det enkleste.

Men ettersom oppetid viser 1 minutt gjennomsnitt av systembelastning, skal indikatorkretsen drives ikke like strengt i sanntidsmodus.

Likevel kan denne kretsen gi nyttig visuelt hint som viser hvordan RPI gjør det nå.

Trinn 2: Skjemaer

Denne kretsen vil motta 4 forskjellige nivåer (f.eks. 00-> LOW, 01-> LIGHT, 10-> MEDIUM, 11-> HIGH) av gjeldende CPU-belastning fra RPI via to optokoblinger-innganger.

74LS139 (2 til 4 dekoder og de-multiplexer) dekoder to bit-innganger til en enkelt utgang blant 4 mulige måter som 00 (LOW)-> B0, 01 (LIGHT)-> B1, 10 (MEDIUM)-> B2, 11 (HØY)-> B3.

Ettersom 74LS139 -utgangen er omvendt (00 inngang -> B0 blir LAV og andre 3 utganger HØY), brukes 74HC04 -omformeren for å gjøre utgangen reversert en gang til.

Når utgangen på 74LS139 er normal HØY, er ikke 74HC04 nødvendig.

Men på en eller annen måte er 74LS139 laget slik. (Sjekk sannhetstabellen til 74LS139)

Når en av 74LS139 -utgangene er valgt, vil den aktivere en bestemt analog bryter blant 4 brytere som er inkludert i CD4066 IC.

CD4066 kan støtte 4 analoge brytere, og hver bryter består av 1 kontrollinngang og 2 analoge utganger.

Når kontrollinngangen blir HØY, blir to utgangstilkoblinger lav impedans (motstand blir 0) og andre blir HØY impedans (motstand mellom to utgangsbaner blir flere hundre mega ohm) nivå.

Bare kontroll 1 (pin 13) på CD4066 blir HIGH, banen mellom utgang 1 (pin 1) og utgang 2 (pin 2) er tilkoblet, mens andre utganger ikke er tilkoblet (i høy impedans -tilstand).

På samme måte kobler HØY inngang til kontroll 2 (pin 5) utgang 1 (pin 4) og utgang 2 (pin 3) til mens andre utganger er frakoblet.

Deretter blinker LM555 to lysdioder i forskjellig blinkhastighet.

Som du kan se i skjemaet ovenfor, vil NE555 fungere med en av motstandsverdien blant 4 (12k, 24k, 51k, 100k) mulige motstandsnivåer.

Trinn 3: NE555 forskjellig klokkegenerering

Som vist i skjematikken, vil NE555 bruke en av mulige motstandsverdier som 12k, 24l, 51k og 100k.

Faktisk er NE555 -tidskretsdelen en viktig visuell indikasjon som støtter en del av kretsen.

Kretsoperasjonsskjema er som følger.

- Når det ikke er noen signifikant CPU -belastning, sender python -programmet installert i RPI 00 utganger til indikatorkretsen. Deretter aktiveres to utganger til CD4066, og NE555 opererer med 12k motstandsverdi. Derfor blinker lysdioder 1,5 ganger i sekundet (blinker ganske raskt)

- CPU er lett lastet (Da blir køtiden på oppetid 0,1 ~ 0,9), python sender 01 til kretsen. Deretter aktiveres CD4066 med utganger tilkoblet med 24k motstand. Som et resultat reduserte LED -blinkingen 1,2 ganger per sekund (LED -blinkingen ble noe redusert, men fortsatt litt rask)

- Når CPU-belastningen økte betydelig (Da blir oppkø-lengden på oppetid 1,0 ~ 1,9 nivå), vil python sende 10 til kretsen. Deretter åpnes 51k motstandstilkoblingsbane og NE555 opererer 0,8 ganger per sekund. Nå blir blinkhastigheten betydelig redusert.

- Tunge belastninger som belaster CPU og lengden på kø-køen blir lengre (mer enn 2 jobber vil vente på å bli utført av CPU og oppetid vil rapportere mer enn 2,0). Etter som 100k motstandstilkobling er valgt, blinker NE555 LED 0,5 ganger i sekundet (blinkhastigheten blir veldig langsom)

***

Sammen med økt systembelastning vil LED -blinkhastigheten reduseres tilsvarende.

Når LED blinker ganske sakte, overbelastes RPI sikkert betydelig.

Denne måten er belastningsindikasjonskretsrapporten du gjeldende lastnivå for RPI.

Trinn 4: Deler

For å lage denne kretsen brukes forskjellige IC -brikker.

Selv om jeg nevner 74LSxx, CD40xx -type gamle IC -brikker, kan du bruke nylige typer TTL- og CMOS -brikker som 74HC4066 og 74ASxx når valgt IC -brikke er DIP -type.

Utenpåliggende type liten IC -pakke kan også brukes når du kan lodde de små riktig på den universelle kretskortet.

Andre er vanlige deler du enkelt kan kjøpe fra Internett-butikker.

- 74LS139 (2 til 4 dekoder, de-multiplexer) x 1

- 74HC04 (6 inverter) x 1

- CD4066 (4 analoge brytere IC) x 1

- NE555 Timer IC x 1

- Kondensatorer: 10uF x 1, 0.1uF x 1

-PC817 optokobler x 2 (hvilken som helst vanlig 4-pinners optokobling kan brukes)

- Motstander: 220ohm x 4 (begrensning av LED-strøm), 4,7K (optokoblingsgrensesnitt) x 2, 12K,/24K/51K/100K (klokkestyring) x 1

- LED x 2 (forskjellige farger som gul, grønn eller rød, grønn)

- Universalplate 30 (W) x 20 (H) hullstørrelse (Du kan kutte alle størrelser på universalplaten for å passe denne kretsen)

- Tinntråd (For å lage ledningsmønstre på det universelle kretskortet)

- pinnehode (3 pinner) x 3

- IC -pinnehode (4 pinner) x 4

- ledninger i rød/blå farge

***

Trinn 5: Lag PCB -tegning

Selv om jeg viser PCB -tegning i hvert prosjekt, er ledningsdesignet bare en referanse som vil guide deg til å lodde hver del på universell PCB.

Men du trenger ikke nødvendigvis å holde deg til dette ledningsopplegget.

Som du kan se koblingsskjemaet ovenfor, er det ganske komplekst og krever betydelig stor PCB.

Du kan bruke felles kabel til å koble deler i stedet for tinntråd for å redusere størrelsen på loddet ferdig PCB.

Bare bruk PCB -tegningen for å kontrollere og bekrefte riktig lodding mellom delene.

Når antallet TTL- eller CMOS -ICer økes, blir PCB -tegning vanligvis ganske komplisert utover riktig integrering på den ene siden av PCB.

Derfor brukes flerlags PCB ofte til industrielle digitale kretser som inkluderer mye TTL, CMOS og mikroprosessor.

Trinn 6: Lodding

Jeg bruker tinntråd og vanlig ledningskabel sammen for å minimere PCB -størrelsen så mye som mulig.

Når du sammenligner med PCB -tegning, blir plasseringen av hver del fullstendig endret.

Men fortsatt brukes PCB -tegning for å verifisere riktig forbindelse mellom deler under lodding.

Du kan se at 12k/24k/51k/100k motstander er satt inn på IC -pinnehodet uten lodding.

Derfor kan du erstatte motstander til andre verdier for praktisk skiftende kretsoperasjon senere.

Trinn 7: Montering

Fullført lastindikatorkrets (heretter som INDIKATOR) er installert på RPI -boksen til musikkspilleren som vist på bildet ovenfor.

Denne musikkspilleren er installert med DAC, og jeg bruker denne nylig for å spille musikkvideo.

Om denne RPI -boksen, vil jeg forklare senere og nå skal vi fokusere på INDIKATOR ettersom kretsen er hovedemnet for dette prosjektet.

Jeg kjøpte Raspberry Pi 4 Model B 2GB (heretter RPI 4B) nylig for å støtte videospilleapplikasjon.

Siden RPI 4B har økt ytelsen til 4 kjerner CPU, blir systembelastningshåndteringen forbedret ganske betydelig fra RPI 3B+.

Derfor bør utgangskjørelengdens lengdeutgang behandles annerledes enn RPI 3B+.

- For den veldig konvensjonelle systembelastningen, for eksempel avspilling av video, er lengden på løpekø vanligvis mindre enn 0,5 (Så LAV systembelastning vil være 0,0 ~ 0,5 nivå)

- Når en liten ekstra systembelastning legges til, for eksempel avspilling av video og kopiering av filer fra og til lokale kataloger, fører det til en liten belastning på CPU. (Så det LYTE lastnivået vil være 0,5 ~ 1,0)

- Når det påføres betydelige belastninger, for eksempel å spille av video i nettleseren på Youtube -nettstedet og surfe på en annen nettleser, blir hastigheten på RPI 4 litt treg (så MEDIUM -lastnivået skal være 1,0 ~ 2,0)

- Endelig blir RPI 4-systembelastningen HØY når du kjører flere nettlesere og kopierer store mengder filer til en annen RPI-server gjennom nettverket (Da blir kjørelengden mer enn 2,0)

***

Disse lastnivådataene vil bli brukt av skal utvikles python -kode i neste trinn.

Trinn 8: Revidere original krets

På grunn av flere feil i den originale kretsdesignen, endrer jeg kretsen som vist på bildet ovenfor.

Årsakene til endring er som følger.

- NE555 klokkepuls består av høy og lav bølgeform. Men vanligvis er HIGH og LOW signalvarighet (t = 1/f) ikke det samme (for eksempel HIGH er 70% og LOW er 30% i original krets). Derfor er ikke blinkende hastighet på to lysdioder (grønn/gul LED i originalutførelse) den samme (én lysdiode lyser lenger enn den andre). Av denne grunn er visuell indikasjon ved LED -blinking ikke så lett gjenkjennelig. '

- Derfor legger jeg til flere lysdioder og lager sirkulært iterasjonsmønster med CD4017 for å sikre enkel gjenkjenning av driftstilstand

- Endrer også LED -blinkskjemaet omvendt, for eksempel sakte blinking ved LAV belastning og raskere blinking med HØY belastning. (Den originale kretsen er laget for å blinke raskere ved LAV belastning og sakte blinking ved HØY belastning). I situasjonen HIGH load blir alle RPI -handlinger trege. Og å vise sakte LED -blinking vil ikke gjøre deg glad. (I det psykologiske aspektet velger jeg mer positivt visningsopplegg)

***

Selv om LED -skjermdelen er vesentlig endret, er det generelle endringsnivået med den opprinnelige kretsen ikke så mye som du kan se i neste trinn.

Trinn 9: Opprinnelig skjematisk endring

Tillegg av CD4017 og 8 lysdioder er store endringer.

For å endre NE555 -klokkefrekvensen og omvendt LED -blinkingsskjema, endres motstandsverdiene som vist i skjemaet ovenfor.

Siden tilleggskretsdelen er en enkel CD4017 -basert chaser -krets, hopper jeg over andre detaljerte forklaringer på den modifiserte kretsen.

All endret kretsdel kan lages som datter -PCB -kort som CD4017 og 8 lysdioder er loddet til.

Datterkortet kan festes til hovedkortet (hovedkortet) som vist på bildet i trinn 8.

Trinn 10: Testing

Testvideo av alle operasjonelle stadier (LAV, LETT, MEDIUM og HØY belastningstilstand) vises av filen som er lagret i google -stasjonen nedenfor.

***

drive.google.com/file/d/1CNScV2nlqtuH_CYSW…

***

I henhold til gjeldende systembelastning vil blinkhastigheten bli endret blant en av 4 tilstander som vises i videoen.

Trinn 11: Python -kode

Siden det meste av styringslogikk er inkludert i ekstern maskinvarekrets, er driftslogikken for python -koden relativt enkel, inkludert de følgende trinnene.

- Få CPU -temperaturdata til å sammenligne relativitet mellom systembelastning og temperaturøkning

- Samler gjennomsnittlig systembelastning på 1 minutt fra oppetid

-Lag tidsstempel som åå-mm-dd hh: mm: ss-format

- Skrive temperatur, systembelastning sammen med tidsstempel

- I henhold til gjeldende systembelastningsdata (00, 01, 10, 11) til INDIKATOR -kretsen

- Sov 5 sekunder før du starter trinnene nevnt ovenfor

Ettersom python -programmet trenger streng innrykk i kildekoden, kan du laste ned kildefilen fra Google Drive ved å følge lenken nedenfor.

***

drive.google.com/file/d/1BdaRVXyFmQrRHkxY8…

***

Siden jeg ikke bruker RPI som stasjonær datamaskin, er kjøring av Libre -kontorprogrammer eller nettleser svært sjelden.

Vanligvis spiller jeg musikkvideo, filkopiering/flytting eller python -programmering med nylig kjøpt RPI 4B 2GB.

Derfor er gjennomsnittlig belastning vanligvis mindre enn 1,0 i mitt tilfelle, og derfor endrer jeg nivåene LOW/LIGHT/MEDIUM/HIGH i koden min. (Du kan endre testbetingelsene ellers)

Men når du vanligvis ser på YouTube -videoer med RPI, vil mer enn 2,0 systembelastninger ofte skje.

Trinn 12: Relativitet mellom systembelastning og CPU -temperatur

Vanligvis gjetter jeg og er sikker på at økende systembelastning vil øke CPU -temperaturen.

Men inntil nå har jeg ikke et klart bilde av den gjensidige driften mellom dem.

Som du kan se i grafen ovenfor, er de veldig sterke ko-relasjoner som følger.

- For enkel sammenligning multipliserer jeg 10 til gjennomsnittlig systembelastning. Ellers er omfanget av systembelastningen veldig liten (0,0 ~ 2,0), direkte sammenligning blir vanskelig.

- Ettersom kjøling FAN -krets er installert på musikken som spiller Pi -boksen, overstiger CPU -temperaturen aldri mer enn 50C

- Når systembelastningen er innenfor området 0,0 ~ 1,0, temperaturer innenfor området 45 ~ 48C (CPU -metalldekselet varmes litt opp)

- Men tung belastning påføres (Vanligvis nettleser og spiller Youtube -videoer), belastning skyhøye og så temperaturen

***

Ettersom RPI 4B er installert med 4 -kjerners CPU, vil teoretisk sett ikke ytelsen forringes mye til belastningsnivå (oppetidskø) 4.

Men fortsatt mindre enn gjennomsnittlig belastningsnivå 4, vil passende temperaturkontroll være nødvendig.

Trinn 13: Fullføring

Jeg fullfører dette prosjektet ved å installere INDICATOR to Pi -boksen som bildet ovenfor.

Under uformell bruk av denne Pi -boksen viser INDIKATOR sjelden HØY nivå og dynamisk LED som blinker.

Vanligvis forble den i sakte blinkende lysdioder (så lavt eller lett nivå).

Uansett, lagt til visuell indikator gjør det litt morsomt, i det minste viser det at RPI gjør noe akkurat nå.

Takk for at du leste denne historien ….