[Linux] msg led aansturen

[Fido]

Is er misschien iemand die mij kan vertellen hoe ik de msg led van mijn asus bord kan aansturen onder Slackware?

[Verwijderd]

Denk dat dat niet met zomaar een tooltje gaat. Als je het ledje bedoelt dat brand als de hardeschijf bezig is, denk ik dat het helemaal niet kan. Anders ff vragen in p&w. Taal wordt dan waarschijnlijk asm.

[SvMp]

Op dinsdag 04 december 2001 21:24 schreef the_tag-man het volgende:
Denk dat dat niet met zomaar een tooltje gaat. Als je het ledje bedoelt dat brand als de hardeschijf bezig is, denk ik dat het helemaal niet kan. Anders ff vragen in p&w. Taal wordt dan waarschijnlijk asm.

Kan wel in C hoor.
Ik heb in de zomer een device driver geschreven voor Linux als vakantie-werk, geen regel ASM

[chromeeh]

ASM is wel vele malen sneller dan C, alleen ASM werkt nog met oude instructies die nieuwe procs. nie zo lekker vinden.

[Verwijderd]

Misschien willen ze je bij ASUS meer informatie geven. Heb je al een mail gestuurd?

[RemcoX]

Op dinsdag 04 december 2001 21:24 schreef the_tag-man het volgende:
Denk dat dat niet met zomaar een tooltje gaat. Als je het ledje bedoelt dat brand als de hardeschijf bezig is, denk ik dat het helemaal niet kan. Anders ff vragen in p&w. Taal wordt dan waarschijnlijk asm.

Het gaat denk ik niet over de hdd LED, maar over een LEDje dat aangeeft of je nieuwe email hebt.

(ik las in ieder geval ergens dat sommige Asus boards over zo'n aansluiting beschikken)

[XTerm]

Moet kunnen; ge gaat wel ruzie krijgen met de kernel.
Ge moet gewoon naar een bepaalde geheugenlocatie een waarde schrijven. En hops het ledje verspringt.
Nu nog kwestie van geheugen direct te benaderen. Dat kan misschien met een device te maken in /dev ?

Aan jou om uit specification sheets dat geheugenadres te peuteren.

Ik weet nog dat ik met QBasic ooit m'n numlock lampje kon laten meedansen op de maat van een melodietje

[deadinspace]

Op dinsdag 04 december 2001 23:22 schreef crashoverride het volgende:
ASM is wel vele malen sneller dan C, alleen ASM werkt nog met oude instructies die nieuwe procs. nie zo lekker vinden.

Neuh.
Om te beginnen 'werkt asm niet met instructies die de nieuwe procs niet zo lekker vinden'; Assembly is niets anders dan de rechtstreeks de instructies van een CPU programmeren (via mnemonics). Als je een recente assembler hebt, kun je dus alle instructies van je cpu programmeren.

Bovendien is de hele x86 lijn qua cp backwards compatible (op een paar uitzonderingen na), dus tegen het probleem van instructies die 'nieuwe cpus niet zo lekker vinden' zul je niet aanlopen.

En verder produceert een goede C compiler efficientere programma's dan een goede ASM programmeur.

[deadinspace]

Op dinsdag 04 december 2001 23:31 schreef XTerm89D het volgende:
Moet kunnen; ge gaat wel ruzie krijgen met de kernel.
Ge moet gewoon naar een bepaalde geheugenlocatie een waarde schrijven. En hops het ledje verspringt.
Nu nog kwestie van geheugen direct te benaderen. Dat kan misschien met een device te maken in /dev ?

Het zal eerder een i/o poort zijn waar hij aanhangt, of misschien zelfs via de systeembus (dan issie via I2O/lmsensors blaat te addresseren).

[Servowire]

Op dinsdag 04 december 2001 23:22 schreef crashoverride het volgende:
ASM is wel vele malen sneller dan C, alleen ASM werkt nog met oude instructies die nieuwe procs. nie zo lekker vinden.

echt niet

[SvMp]

Op dinsdag 04 december 2001 23:42 schreef deadinspace het volgende:


En verder produceert een goede C compiler efficientere programma's dan een goede ASM programmeur.

Dat is flauwekul.
Als die goede asm programmeur er genoeg tijd in stopt, zijn die programma's efficienter.
Het is alleen efficienter qua verhouding ontwikkelings-tijd - performance - omvang.

[chromeeh]

Op dinsdag 04 december 2001 23:42 schreef deadinspace het volgende:

[..]

Neuh.
Om te beginnen 'werkt asm niet met instructies die de nieuwe procs niet zo lekker vinden'; Assembly is niets anders dan de rechtstreeks de instructies van een CPU programmeren (via mnemonics). Als je een recente assembler hebt, kun je dus alle instructies van je cpu programmeren.

Bovendien is de hele x86 lijn qua cp backwards compatible (op een paar uitzonderingen na), dus tegen het probleem van instructies die 'nieuwe cpus niet zo lekker vinden' zul je niet aanlopen.

En verder produceert een goede C compiler efficientere programma's dan een goede ASM programmeur.

Ja ok das waar Was ik ff vergeten

[deadinspace]

Op woensdag 05 december 2001 08:14 schreef svdmeer het volgende:
Dat is flauwekul.
Als die goede asm programmeur er genoeg tijd in stopt, zijn die programma's efficienter.
Het is alleen efficienter qua verhouding ontwikkelings-tijd - performance - omvang.

Nee, want een assembly programmeur houdt niet bij:
• Hoeveel CPU cycles welke instructie op welke CPU kost (dit verschilt sterk per CPU).
• Welke instructies op welke CPUs parallel uitgevoerd kunnen worden en welke niet. (verschilt sterk per CPU).
• Dat data en instructies bij sommige CPUs beter gealigned kan worden op bijvoorbeeld 32 of 64 bits, wat efficientere addressering tot gevolg heeft.

Een compiler kan dit wel allemaal onthouden en toepassen, waarbij vooral opmerking 1 en 2 zwaar wegen.

En dan heb ik het alléén nog maar over de x86 lijn van CPUs...