varia

Legacy Radeon on Linux

Door Blokker_1999 op zondag 09 februari 2014 20:52 - Reacties (11)
Categorie: /var, Views: 2.686

Het word al jaren gezegd en heb het vandaag zelf nog eens mogen ervaren. Radeon drivers en Linux gaan niet samen. Heb het vandaag zelf nog eens mogen ervaren. Hoewel ik in het verleden nooit echt problemen heb ondervonden met een ATi kaart en Linux is het een ander verhaal wanneer je met legacy drivers moet samenwerken.

Ik had dus het plan opgevat om mijn HTPC als 1 van mijn laatste dedicated Windows machines ook eindelijk eens om te zetten naar Linux. Deze machine draait op een ondertussen oudere AMD X2 CPU met een IGP uit de 3200HD reeks. De drivers voor deze IGP worden door AMD niet meer bijgewerkt sinds eind 2012. de laatste versie die hiermee compatibel is, is 13.1.

Als distributie kies ik voor mijn vertrouwde Debian in de testing versie (relatief recent, uitermate stabiel). De AMD drivers zijn in principe gewoon uit de juiste repositories te nemen. ... Niet dus. De drivers die te vinden zijn in de repos willen niet werken wegens andere afhankelijke pakketten die niet (meer) aanwezig zijn in diezelfde repos. Dan maar compileren van scratch.

Maar ook hier stoot ik weer op een probleem. Het compileren gaat vrij vlot, tot de laatste stap. Het bouwen van de kernel modules. DKMS faalt hierbij, telkens opnieuw. Uit een snelle blik op het internet blijkt dat de driver niet meer compatibel is met Linux Kernels >= 3.5. Op te lossen met een patch, maar ook dat brengt geen redding omdat er ondertussen alweer meer veranderd is in die kernel.

Ik wil niet teruggaan naar een oude(re) linux versie en ik ben weer een tegenslag rijker. Omdat het probleem bij de "slechte" drivers van AMD zit denk ik er nu dus over na om een compacte nVidia kaart te kopen en de IGP gewoon uit te schakelen. Met nV heb ik deze problemen namelijk nog niet eerder gehad.

Arduino snelheid

Door Blokker_1999 op zondag 17 november 2013 19:09 - Reacties (16)
Categorie: /var, Views: 3.585

Dit weekend heb ik me bezig gehouden met wat leuk speelgoed. 2 grote LED matrix displays van elks 16x64. Deze displays zijn afkomstig uit de interne bestemmingsaanduiders van de M6 rijtuigen.

Deze displays vormden een leuke uitdaging. Ze worden voor ons op maat gemaakt, maar eigenlijk weten we zeer weinig van deze displays. De leverancier van deze displays gaf recent een interessante demo bij ons op kantoor met deze displays voor een ander project. Bij deze demo gebeurde de aansturing met behulp van een arduino microcontroller. Daar ik thuis zelf zo een controller heb liggen dacht ik: dat moet ik ook eens proberen.

De uitdaging was alleen iets groter dan eerst voorzien. De elektronische schemas van het display zijn welliswaar beschikbaar in de datasheet van de displays, maar de aanduidingen op die schemas zijn onleesbaar. Met veel geduld, een multimeter en scherpe meetpennen die door de beschermlak gaan toch het schema kunnen herconstrueren en de aansluitingen kunnen bepalen, tijdens het weekend nog altijd sneller dan deze aan de leverancier te vragen ;).

Direct volgde de volgende tegenslag. De meeste voorbeelden die je online vind gaan er van uit dat je een datalijn hebt per rij die je gaat aansturen. dat geeft dat je een volledige kolom in 1 keer kunt weergeven en dat je dus kolom per kolom kan weergeven. Helaas, niet op deze displays. Omdat we 16 rijen hebben heeft men ervoor gekozen deze achter een 1-of-8 Decoder/Demultiplexer te plaatsen waardoor je slechts 1 rij gelijktijdig kan laten oplichten. Als ik kolom per kolom wens op te bouwen moet ik dan ook elke LED apart gaan laten oplichten wat de scantime over het display enorm de hoogte indrijft. De eerste code die ik geschreven heb paste dit principe toe, maar bleek uiteindelijk onwerkbaar.

Na even mijn hersenen te pijnigen er toch achter gekomen hoe het dan wel moet. Je stuurt de data voor de hele lijn in 1 keer door de schuifregisters, latcht deze vast, zet je uitgang hoog voor die rij, en terwijl die rij oplicht laad je de data voor je volgende rij in je schuifregister. Eenmaal ingeladen, even je uitgang laag brengen, latch loslaten, vastzetten, van rij verspringen en uitgang terug hoog zetten.

Als dit snel genoeg gaat krijg je zo een proper beeld van je display. … Maar hier komt arduino op zich te kort. Omdat de arduino software een eigen programeertaal heeft gaat er redelijk wat snelheid verloren. Na het herschrijven van de software had ik dan ook een enorm flikkerend (en dus storend) beeld.

Ik ben dan op het internet op zoek gegaan, en je kan blijkbaar digitalWrite(PIN STATE); ook vervangen daar volwaardige C code. Volgens testen die ik ben tegengekomen gaat het met C-stijl code ongeveer 10x sneller. Nadat ik de 2 meest gebruikte pinnen in mijn code had omgevormd was het beeld op het display gewoon stabiel te noemen. Ik ben dan nu ook bezig met de andere pinnen ook nog om te vormen.

Arduino heeft alle pinnen netjes genummerd, maar om deze rechtstreeks aan te spreken moet je deze vertalen naar het juiste poortnummer van je controller, hiervoor kan je op het internet figuren vinden, ook op de arduino website zoals voor mijn eigen Mega2560.

Het direct aansturen van de pinnen doe je op volgende manier:

Een poort hoog zetten:
PORT{letter} |= _BV(P{letter}{number});

Een poort laag zetten:
PORT{letter} &= ~_BV(P{letter}{number});

Een voorbeeld van Pin13 op mijn Mega2560 (poort B7):
PORTB |= _BV(PB7); //PIN13 hoog
PORTB &= ~_BV(PB7); //PIN13 laag

Wanneer snelheid belangrijk is loont het dus om de arduino code te vervangen door C-stijl code die de AVR GCC compiler kan verstaan. Nog beter is uiteraard om de arduino omgeving volledig links te laten liggen en helemaal in C-stijl te gaan programmeren.

http://tweakers.net/ext/f/UxqcP4BaqR8oUSjjr6y7iDUw/medium.jpg

Volgende dingen op het programma: mijn ASCII tabel verder uitwerken (op dit moment enkel het alfabet in hoofdletters), display uitbreiden naar een formaat dat vergelijkbaar is zoals we het in de trein terug vinden, animaties toevoegen (text scrolling), communicatieprotocol toevoegen, … . Maar ook bestaat de kans dat ik de arduino ga inruilen voor iets anders, zoals een pandabord met sturing via de GPIO pinnen.

UPS (koerier) Failed

Door Blokker_1999 op woensdag 13 februari 2013 08:44 - Reacties (39)
Categorie: /var, Views: 9.115

Vorige donderdag stond ere en koerier aan mijn deur met een pakje voor mij. Spijtig genoeg voor hem bleef de deur toe. Spijtig want ik had hem met niet veel tijd gemist. Ik kom thuis en vind het briefje in mijn brievenbus.

Lees verder »

An app for that.

Door Blokker_1999 op vrijdag 04 januari 2013 12:19 - Reacties (7)
Categorie: /var, Views: 4.402

Bij de recente berichten over het verlies van Apple in een rechtzaak tegen Amazon [1] die handelde over het gebruik van de term appstore op de kindle doken op vele sites in de comments de claims op dat Apple diegene is die de term app bedacht en grootgemaakt heeft.

Lees verder »

Gefeliciteerd.

Door Blokker_1999 op dinsdag 01 januari 2013 13:00 - Reacties (2)
Categorie: /var, Views: 1.555

De kerstman is weer naar huis vertrokken. De kater van vanacht is bijna doorgespoeld. Het nieuwe jaar is ondertussen in de hele wereld ingezet. Rest me niet veel maar dan iedereen die dit leest te feliciteren. U heeft het jaar overleefd waarin de wereld tot zijn einde kwam. Laat ons daarom van 2013 een onvergetelijk jaar maken!

http://tweakers.net/ext/f/kStTqCBBfHlvS8X9TxBEMQCn/full.jpg