[EiP] Wekkerradio++

[Sprite_tm]

Het is al een tijd terug dat ik een EiP gedaan heb en ik heb nu een geinig projectje wat wel leuk is om te documenteren. Vandaar:

EiP: Wekkerradio++

Het Idee

Ik heb al ongeveer 15 jaar deze wekkerradio:

Een Philips AJ3040. Erg degelijk en naast de niet te voorkomen stroomuitval-fail heeft 'ie me nog nooir in de steek gehouden, maar heel sexy is 'ie niet: hij geeft de tijd aan maar heeft maar 1 alarm, met de keuze uit een irritante beeper of klassieke AM/FM-ontvangst. Dat betekent dat elke keer als ik uit kan slapen of op een andere tijd wakker moet worden, ik het ding op de complexe manier moet verzetten. Verder zijn de 4 7-segments-leds ook wel leuk, maar ze zijn nogal jaren-tachtig in hoe ze eruitzien en dat ze de hele tijd op volledige sterkte aanstaan is ook een beetje jammer. Verder snapt het ding niet dat na snoozen het alarm niet weer aan moet gaan als ik niet in bed lig; da's ook een beetje jammer.

Daarmee zijn de requirements van deze mod wel een beetje duidelijk:
• Het instellen moet makkelijker
• De alarm-opties moeten uitgebreider
• Het display moet sexy'er, en moet automagisch dimmen
• Het alarm moet telepatisch worden uitgaan als ik opgestaan ben
• De wekkerradio moet nog steeds even degelijk zijn als de afgelopen 15 jaar.

Ik besloot eerst maar eens met het ding te beginnen waar ik de rest van de tijd tegenaan moet kijken:

Het Display

Als je wat anders wilt dan een 7-segments-display-klok, zou je denken dat de mogelijkheden best groot zijn: Gooi er een LED-matrix in! Of een LCD! Als je echter wat langer nadenkt blijkt het complexer te liggen: een LED-matrix leest op deze grootte toch niet zo lekker af als een 7-segments-display en is nog steeds jaren-80-spul. Een LCD is ook lastig: als je ze zo breed wil hebben als het oorspronkelijke display zit je aan een zwartwit-LCD'tje en naar mijn mening hebben die dingen een bagger contrast en komt er een te grote bak licht uit het backlight. Ik wil iets met een hoog contrast hebben wat niet meer licht geeft dan wat nodig is om de digits zichtbaar te maken.

Wat blijft dan over? Nou, oled-displays! Die zijn te krijgen in groottes zoals die van het 7-segments-display, hebben een hoog contrast en een best redelijke resolutie en een pixel geeft echt nul licht als 'ie uit is.

Het eerste begin van het project was dan ook op eBay, oled-schermen scoren. Ik liep al vrij snel tegen een mooi 288x48-pixel scherm van Osram aan, de lekker bekkende OS288048PQ33MY0C11 (eBay-link). Dit is een scherm wat geel oplicht en via een SPI- of i2c-linkje aan te sturen is.

First life!

Toen ik vandaag uit mijn werk thuiskwam vond ik dus een pakje op mijn mat met twee van deze beestjes erin:


En natuurlijk ben ik dan iemand die het kreng meteen aan wil sluiten. Datasheet erbij en gededuceerd dat het ding als je 'em goed aansluit maar 4 data-draden nodig heeft. Ik had nog wat code liggen om zo'n FT232-moduletje als 4xGPIO te gebruiken en de logica om daar een SPI-bus over te maken had ik ook al. Verder had het ding 12V nodig om de ledjes te laten oplichten; ik had gelukkig op een mislukt prototype-PCBtje nog een boostconverter zitten die dat wel kon maken.

Lang verhaal kort: wat solderen, programmeren en een testplaatje in The Gimp inelkaarklikken had ik 't display werkend:


En dan is de vraag natuurlijk: hoe goed doet dit display het in de wekkerradio? Het display is groen-gelig en de wekkerradio heeft een contrastverhogend rood glaasje ervoor. Er is maar een manier om dat uit te zoeken:

Nou, da's best acceptabel

En nu?

Da's een goede vraag. Het display is een redelijke no-brainer: hang er een microcontroller met wat grafische routines achter en je hebt een wekkerradiodisplay wat een heel stuk leuker is dan het bestaande LCD. Maar dan? Om het beest goed in te kunnen stellen wil je eigenlijk een webpagina hebben ofzo. Internet-connectivity is ook wel leuk om bijvoorbeeld eventueel te kunnen syncen met een agenda of iets dergelijks. Het probleem met zo'n bult aan functionaliteit is dat ik best een redelijke coder ben, maar je wel een verhoogd risico loopt op bugs. Dat kan betekenen dat ik 's ochtends niet wakker word. De vraag is dan: hoe zorg ik ervoor dat de kans dat de wekker faalt qua aflopen, maar ik toch zoveel mogelijk functionaliteit krijg?

[AlexanderB]

GPS dr in en altijd op de seconde nauwkeurige tijd hebben?

Een RTC moduletje dr in zodat ie niet gaat afwijken.

[Sprite_tm]

GPS is leuk, maar ik wil het ding toch aan het netwerk hangen; kan ik net zo goed een sync op NTP doen.

[sopsop]

Kun je niet jouw geknutsel unobtrusive toepassen? Jij vangt de signalen voor het huidige display af, derhalve weet je wat het display hoort te tonen, voor het instellen van de wekker koppel je de bestaande knoppen. Omdat je weet wat het display toont, moet het ook gewoon mogelijk zijn om met pulsjes de knopjes te bedienen om tijd in te stellen.

En ook meerdere alarmtijden. Je stelt alarm 1 gewoon op de wekker in. Zodra die is geweest, zet je het tweede alarm erin via bovengeschreven methode.

Zo heb je volledige controle over snooze, alarm on/off, instellen van het alarm, etc. En je behoudt de core betrouwbaarheid van de wekker, omdat je aan die electronica niet hoeft te komen.

Feitelijk maak je dus een interface voor alle I/O van de wekker.

[ Voor 4% gewijzigd door sopsop op 02-05-2014 08:19 ]

[The Lord]

Sprite_tm schreef op donderdag 01 mei 2014 @ 23:11:

En nu?

Da's een goede vraag. Het display is een redelijke no-brainer: hang er een microcontroller met wat grafische routines achter en je hebt een wekkerradiodisplay wat een heel stuk leuker is dan het bestaande LCD. Maar dan? Om het beest goed in te kunnen stellen wil je eigenlijk een webpagina hebben ofzo. Internet-connectivity is ook wel leuk om bijvoorbeeld eventueel te kunnen syncen met een agenda of iets dergelijks. Het probleem met zo'n bult aan functionaliteit is dat ik best een redelijke coder ben, maar je wel een verhoogd risico loopt op bugs. Dat kan betekenen dat ik 's ochtends niet wakker word. De vraag is dan: hoe zorg ik ervoor dat de kans dat de wekker faalt qua aflopen, maar ik toch zoveel mogelijk functionaliteit krijg?

Ik zou kiezen voor zo min mogelijk code in de wekker: tijdweergave, NTP, een registratie routine en een set instel API's. Dan zou ik de rest overlaten aan een web pagina en/of applicatie (al dn niet op een telefoon).

[sebastius]

Is het een idee om de wekker an sich door een controller te laten draaien (dus tijd + bv 4 wektijden) en dan via een protocol een andere chip de actuele stand van zaken (NTP, verse alarmtijden etc) er in te blazen? Dan zijn het twee separate functies.

Of een soort watch-dog achtige constructie dat de ene de ander bewaakt?

[Stoney3K]

Radio vervangen door een digitaal te sturen PLL circuit, zodat je presets kan tunen?

Of zelfs gewoon met een Squeezebox client...

[sebastius]

Als je die moeite doet, kun je net zo goed er een Pi aanhangen met Spotify of iets dergelijks

[Sprite_tm]

Ik zat inderdaad te denken aan een AVR die het daadwerkelijk wekken regelt en een Carambola ofzo die de rest doet. De radio ga ik niet vervangen: feitelijk heb ik 'em altijd tussen stationnen staan zodat ik wakker word met ruis (en niet blijf liggen omdat de DJ toevallig interessant doet); dat hoeft van mij niet anders te worden.

[Notna]

Ha, toevallig heb ik deze wekkerradio ook en ook voor de tijd dat jij hem hebt ongeveer. Recentelijk heeft hij echter het loodje gelegt. Nouja, de tijd ging steeds meer voorlopen. Verder functioneert hij nog prima.

Ik heb het nu in de schuur staan als klus radio maar het enige nadeel is wel dat hij na een uur op Radio mode uitgaat automagisch. Wellicht nog een leuk idee om dat aan te passen zodat je het ook gewoon als Radio kan gebruiken?

[sebastius]

In het kader van Feature Creep kan ik je aanraden uit persoonlijke ervaring om er een WakeUp-Light-functie in te bouwen. Wij worden echt stukken prettiger wakker dan voor we het ding hadden

[Sprite_tm]

No worries, een wakeup-light-functie heb ik al sinds voor de tijd dat de wakeup-light een ding is De huidige incarnatie is een 250W halogeenlamp die via een KaKu-dimmer aan mijn server hangt. Een van de redenen dat ik mijn wekkerradio wil ombouwen is dat ik geen twee tijden meer wil instellen.

[sebastius]

Gaat een en ander in de huidige behuizing komen of ga je een nieuw kastje knutselen?

[Sprite_tm]

De behuizing blijft. Als ik de bestaande pcb eruitrop moet ik genoeg ruimte hebben voor een complete embedded machine

[kELAL]

Meh. Wakeup-lights zijn voor losers die nog geen slaapfasewekker hebben geprobeerd
Dus doe er ook maar een nRF module in, voor communicatie met de sensorarmband...

[Sprite_tm]

kELAL: Sensor-armbanden zijn voor mensen die bang zijn voor DIY. Ik ben zeker van plan een slaapfasedetectiewekkerfunctie (Scrabble!) in te bouwen, maar da's nog een ander project.

[sebastius]

Ik ben nu wel al enigszins getriggerd om zelf ook weer aan een klokje te beginnen, maar ik wil echt Nixies er in hebben Hoewel ik dat OLED scherm mooi vind gaat er niks boven die buisjes in mijn optiek

[Osiris]

Ik zou 't vooral leuk vinden om vooral niet naar zaken als Rπ's te grijpen e.d.. 't Moet natuurlijk wel een beetje hobbyen blijven i.p.v. the easy way out kiezen

[Sprite_tm]

Okay, dit weekeind weer wat verder gekomen. Osiris: ik ga er geen Raspberry Pi ingooien, maar onder een Linux-boardje kom ik toch niet uit, if any omdat ze geen drol kosten en het te comfortabel devven is. Ik zou een bordje willen hebben wat in principe maar minimale processing-power en RAM hoeft te hebben, maar onboard WiFi lijkt me dan wel weer handig, en het moet klein genoeg zijn om in de radio te passen. In dit geval leek een HLK-RM04 van ongeveer EUR12 me een hele goede, maar daat had ik er geen meer van over. Wat ik nog wel had liggen is een Carambola, een iets duurder (EUR22) en iets krachtiger (2x zoveel flash en ram) bordje. Die dus maar gebruiken.

Anyway, FT2232 eruit en Carambola erin en we komen uit op deze dradenboel:


Onderaan de Carambola, met serieel-naar-USB-adaptertje voor de console. Ernaast de Ethernet-aansluiting ervoor, waarboven het OLED-display ligt. Helemaal bovenaan zit de 12V power supply die nog steeds nodig is.

Maar alleen met draden solderen ben je er niet: er moet ook software geschreven worden. Ik besloot om meteen een framebuffer-driver voor het LCD te schrijven: daardoor ziet Linux 'em feitelijk als een complete, hoewel kleine en raargevormde, monitor. Dit heeft een aantal voordelen: ten eerste kan ik in mijn software netjes LibSDL gebruiken, waardoor ik het kan schrijven en testen op een normale PC voordat ik het overzet op de Carambola. Ten tweede, wie wil er nou geen wekkerradio die zo opstart?

[Osiris]

Sprite_tm schreef op zondag 04 mei 2014 @ 22:54:
Ten tweede, wie wil er nou geen wekkerradio die zo opstart?
[video]

* Osiris steekt z'n hand op

't Heeft natuurlijk wel zo z'n voordelen, moet ik toegeven.. Kun je veel vettere dingen mee, qua arbeid/opbrengst-verhouding dan wanneer je in een assembly language gaat proggen

[D4V3]

Leuk project, erg vet om te zien zo'n simpel OLED schermpje als monitor
Persoonlijk zou ik het denk ik niet als wekker willen, ze zien me al aankomen:

Sorry, ik heb me verslapen, m'n wekker had vannacht een kernel panic

[Sprite_tm]

En dat is de reden dat ik het daadwerkelijke wekken waarschijnlijk aan een losse AVR overlaat. De code daarin kan simpel blijven en als 's nachts de Linux-module besluit te bokken, mag ik misschien geen beeld meer hebben (of een kernel panic-tekst inplaats van de tijd) maar word ik in ieder geval nog wakker.

[Osiris]

Then again, ga nou eens na, wat is de kans op een kernel panic?

Ik draai al jaaaaaaaren privé Linux op server én workstation en de keren dat ik kernel panics kreeg is toch wel op één hand te tellen en dan door een defect RAM of mobo.

Een defecte AVR geeft je ook een verslapen ochtend..?

[Sprite_tm]

Klopt. Je moet echter ook naar codesize kijken: het programma op de Linux-bak gaat redelijk veel manieren krijgen om de fout in te gaan: misschien krijg ik onverwacht troep binnen via de webinterface en ben ik vergeten die netjes af te handelen, misschien misbruik ik mijn grafische library ergens waardoor ik een null pointer dereference, misschine vergeet ik een free() waardoor het geheugen volloopt, misschien log ik teveel naar een niet-geroteerd bestand waardoor mijn flash volloopt, .... Dat levert dan wel geen kernel panic op maar zorgt er alsnog voor dat de wekker niet afgaat.

De AVR daarentegen hoeft (waarschijnlijk) maar drie dingen te doen: de tijd bijhouden, een alarm af laten gaan als de tijd overeenkomt met de ingestelde tijd en een strak-gedefinieerd protocol spreken om het geheel in te stellen. De kans dat er daar iets fout aan gaat is vele malen kleiner, omdat de code en afhankelijkheden een heel stuk kleiner zijn.

[ Voor 5% gewijzigd door Sprite_tm op 05-05-2014 15:09 ]

[O88088]

Ik zou willen dat ik zo technisch als jullie was dit is wel een heel gaaf project!

[Damic]

Je kan je avr inschakelen als watchdog en je carambola eventueel rebooten als het nodig moest zijn. Door bvb elke minuut een pin hoog te maken en te luisteren op een andere pin, komt ie niet binnen de 30s = reboot

[sebastius]

Damic schreef op maandag 05 mei 2014 @ 19:31:
Je kan je avr inschakelen als watchdog en je carambola eventueel rebooten als het nodig moest zijn. Door bvb elke minuut een pin hoog te maken en te luisteren op een andere pin, komt ie niet binnen de 30s = reboot

Dan voorkom je niet dat die carambola ook gewoon een flink softwarematig probleem kan hebben en dus braaf elke minuut reset maar dan nog geen drol meer kan

[Dirk J]

Niet vergeten de boel goed dicht te zetten. Voordat je het weet staat je wekker bitcoins te minen

[Fusioxan]

Goh, wat kan ik nog veel leren hier...

Leuk project! Toevallig ben ik zelf ook al een hele tijd bezig met een RPI waar XBMC op draait en een display, waar ik ook over dacht om daar een tijd op te zetten en eventueel een alarm. Nou zit ik alleen te wachten op mijn printplaatjes uit een ver land hier vandaan, maar als ze binnen zijn en ik heb er een aantal gestuct zal ik de vooruitgang hier ook gaan delen.

In ieder geval, deze zal ik zeker gaan volgen!

[Osiris]

sebastius schreef op maandag 05 mei 2014 @ 20:53:
[...]

Dan voorkom je niet dat die carambola ook gewoon een flink softwarematig probleem kan hebben en dus braaf elke minuut reset maar dan nog geen drol meer kan

Je AVR hoeft ook niet compleet achterlijk te zijn: "Hmm, ik heb 'em in 5 minuten nu al 7x gereset.. Da's niet goed.. Weetje, fuck dat kreng, ik ga in fail-safe-mode.."

[Sprite_tm]

Osiris: Dat kan, maar dan moet het kreng wel weten wat 'ie in fail-safe-mode moet doen... en als dat mij op de juiste tijd wakker maken is, betekent dat alsnog dat ik een complete rtc+wekker moet implementeren. Dan kan ik dat net zo goed direct doen

Verder een snelle update: ik heb even snel een klokje in libcairo inelkaargeklust die naar de framebuffer schrijft. Het is allemaal nog wat inefficient, mede omdat de kernel driver gelimiteerd is op 20FPS en nog allerlei debugging-info uitspuugt, maar het effect is te zien. Ik laat trouwens de secondentelling zien omdat daarmee de animatie goed te checken is, dat doet 'ie later alleen met de minuten.

[kELAL]

Sprite_tm schreef op vrijdag 02 mei 2014 @ 21:59:
kELAL: Sensor-armbanden zijn voor mensen die bang zijn voor DIY.

Hoe wil je het dan doen? Als Axel en Boris een indirecte (niet met het lichaam verbonden) meetmethode betrouwbaar genoeg hadden gevonden, dan hadden ze geen sensorarmbandjes gebruikt. Just sayin'.

Dat wil zeggen: Tenzij je van plan bent om je bed te verbouwen, zodat je bedbodem door meerdere loadcells wordt gedragen. Goed, je hebt dan wél meteen een betrouwbare 'ik ben uit bed'-detectie
En de weegschaal in de badkamer is dan ook meteen overbodig geworden

offtopic:
(Alleen zal Mevrouw Sprite daar waarschijnlijk iets minder blij mee zijn...)

[Sprite_tm]

kELAL: Jij mag nooit meer gokken. en een mevrouw Sprite is er nog niet.

[Sprite_tm]

Afgelopen dagen weer flink aan het klussen geweest; zowel aan de hardware- als software-kant. Tijd voor een update'je dus.

Input & RTC

Eerst maar eens het hardware-gedeelte. Hoewel het bijregelen van de wekkerradio via een webpage zeker niet ondoenlijk is, is het toch handig om iets aan input op het apparaat zelf te hebben: als 's nachts je bedenkt dat je er een uur later uitmag wil je dat graag bij kunnen regelen en als je 's ochtends toch nog 10 minuten wilt blijven liggen is een snooze-knop echt wel een eerste vereiste. Daarvoor heb je input nodig, en ik wilde eigenlijk graag alle bestaande knopjes van de wekkerradio recyclen daarvoor. Verder is het natuurlijk niet practisch als een dip in de 220 ervoor zorgt dat zowel je wekkerradio als je adsl/kabelmodem eruitvliegt en dat betekent dat de wekkerradio na opnieuw opstarten de tijd niet meer kan ophalen en je alarm niet af laat gaan. Anyway, er is hardware nodig voor een RTC met battery backup en voor een stel inputs. Ziehier het prototype daarvoor:


Wat je ziet is in de DIP-package een MCP23008 8-poorts I/O expander en in de SOIC8-package een PCF88563 RTC, aangevuld met een CR2032 battery backup. Beide chips hangen met power, ground en een tweedraads i2c-verbinding (en de I/O-expander ook nog met een ongebruikte interrupt-lijn) aan de Carambola vast. De dip-switches zijn stand-in voor knoppen; om ze 'in te drukken' moet ik een dipswitch snel aan- en uitzetten. Ideaal is anders maar je moet iets als je voorraad drukknoppen op blijkt te wezen...

Aan de software-kant hiervoor schijnt Linux weer. Je kan dit soort ICs natuurlijk aanspreken door vanuit je programma moeilijk te doen met I2C-transacties of, godbetere het, direct I/O bitbang-activiteiten. De Linux-kernel is echter voorzien van een gezonde hoeveelheid aanwezige drivers, en de chips die ik gebruikt heb hebben ondanks het feit dat ik ze random uit de rommella getrokken heb netjes drivers in de standaard kernel zitten. Na het toevoegen van een paar regels in de Carambola-kernel wist Linux dus ineens hoe 'ie z'n tijd moest opslaan en onthouden, en met een tweede stel regels was het begrip wat de kernel had over de GPIO-lijnen op dit bordje ineens uitgebreid met de 8 GPIOs op de I/O-expander. Nou kon ik vanuit mijn userspace-programma natuurlijk rechtstreeks die lijnen uit gaan lezen, maar het kan nog makkelijker: met een laatste set goedgemikte regels C-code is Linux wijs te maken dat er knoppen aan de 8 nieuwe I/O-lijnen hangen, en dat deze een toetsenbord met de letters A t/m H erop vormen. Wat spelen met de knoppen levert dan dit beeld op:

De software

En de input aan de kant van de software word dan ineens wel heel makkelijk: ik kan alle nieuwe hardware uitlezen door de standaard Linux-calls voor keyboard-input en clock-interactie te gebruiken. Dat kwam mooi uit, want op mijn laptop had ik de klok-applicatie ondertussen uitgebreid met een optie om voor elke dag van de week een alarm te zetten:

[Djesse8999]

Idee voor het geluid: Een scheepshoorn (of flinke toeter van een auto oid)

je word geheid wakker

[Bikkel70]

Leuk project ! Ik was zelf ook met zoiets begonnen, maar dan met grotere 7segment LED displays ( ik zie anders de tijd niet zonder bril ) die gemultiplexed aangestuurd worden door een avr controller.. De avr controller is dan zelf een i2c slave welke aangestuurd wordt door een raspberrypi . Het is o.a. de bedoeling dat de RPi d.m.v. de NS api gaat kijken of de trein waarmee ik elke dag rijd vertraging heeft, of helemaal niet rijdt. Dit moet me dan gemeld worden via een led i.c.m. een melding op een LCD display ( 44780 )

Anyway... Jouw methode waarmee je de IO inputs als een keyboard ziet vind ik erg interessant. Zou je willen delen hoe je dit "ongeveer "gedaan hebt.. of me in elk geval in de goede richting wijzen ? Ik lees nu nog de inputs uit via de i2c dev interface.

[Sprite_tm]

Ik kan een poging wagen.

Ten eerste: Waar staan de definities van hoe je alles aanelkaarknoopt? Daar zijn ondertussen in Linux twee verschillende methoden voor: de zogenaamde device tree en de platform C-file. Zowel de Carambola die ik gebruik als de RPI die jij wilt gebruiken is de laatste optie degene die we moeten hebben: in mijn geval arch/mips/ralink/rt305x/mach-carambola.c en in jouw geval arch/arm/mach-bcm2708/bcm2708.c

Ten eerste moeten we de GPIO-expander door de kernel laten herkennen als een set generieke GPIOs die net zoals de RPi-pinnen aan te sturen zijn. Dat doe je door een i2c_board_info struct te maken en die te registreren dmv een i2c_register_board_info()-call te registreren. In mijn geval:

C:

static struct i2c_board_info carambola_i2c_board_info[] __initdata = {
        {
                I2C_BOARD_INFO("pcf8563", 0x51),
        },
        {
                I2C_BOARD_INFO("mcp23008", 0x20),
                .platform_data=&mcp23008_data,
//              .irq=gpio_to_irq(RT305X_GPIO_12);
        }
};

en in carambola_init():

C:

        i2c_register_board_info(0, carambola_i2c_board_info,
                        ARRAY_SIZE(carambola_i2c_board_info));

Let wel: ik registreer er ook een pcf8563 bij en mijn mcp23008 heeft een irq-lijn die niet gebruikt is, vandaar de uitgecommentariseerde regel. Mijn mcp23008 leeft op i2c-adres 0x20, dat is met alle adres-lijnen van de chip aan de aarde geknoopt.

Verder heeft de mcp23008-driver nog een stukje info nodig over waar je z'n GPIOs wilt hebben en hoe de pullups initieel moeten staan:

C:

#include <linux/spi/mcp23s08.h>
(...)
static struct mcp23s08_platform_data mcp23008_data = {
        .chip[0] = {
                .pullups = 0x00ff,
        },
        .base = 52, //ToDo: use const instead of magic number
};

Ik heb alle pull-ups hier aanstaan en de gpio-pinnen van de unit beginnen bij nummertje 52 omdat ik op mijn Carambola in /sys/kernel/debug/gpio gezien had dat 51 de laatste GPIO is die de Carambola zelf gebruikt.

Als laatste dien je de MCP23008-support aan te zetten. Omdat deze driver initieel voor de MCP23S08 geschreven is, wat een SPI-device is, vind je 'em als 'mcp23s08' onder 'SPI devices' in de kernel config.

Okay, nu heb je je GPIO. Hoe zorg je ervoor dat knoppen geinterpreteerd worden als knoppen? Dat doe je door de kernel module 'gpio-keys' in de kernel mee te compileren en in je platform-code naast het GPIO-geneuzel wat je er net bijgeedit hebt ook de GPIO-keys-zooi mee te nemen.

Ten eerste moet je de mapping tussen toetsen en GPIOs definieeren. Ik doe dat dmv een veelgebruikt macro'tje:

C:

#define GPIO_KEY(c, g, d) { .code = c, .gpio = g, .desc = d, .active_low = 1 }

static struct gpio_keys_button gpio_buttons[] = {
        GPIO_KEY(KEY_A, 52, "a"),
        GPIO_KEY(KEY_B, 53, "b"),
        GPIO_KEY(KEY_C, 54, "c"),
        GPIO_KEY(KEY_D, 55, "d"),
        GPIO_KEY(KEY_E, 56, "e"),
        GPIO_KEY(KEY_F, 57, "f"),
        GPIO_KEY(KEY_G, 58, "g"),
        GPIO_KEY(KEY_H, 59, "h"),
};

Zie de 52 waar de i2c-io-expander begint te tellen met GPIOs weer terugkomen: deze regels definieeren feitelijk dat de 8 knoppen aan de GPIO-expander de letters a t/m h zijn. De KEY_A-constantes definieren de keys trouwens, zie include/linux/input.h voor alle definities; de "a"-stukjes zijn slechts labels die aan de gpio-pinnetjes gehangen worden.

Dan moet je de platform-data voor de gpio-keys-module opgeven:

C:

static struct gpio_keys_platform_data gpio_key_info = {
        .buttons        = gpio_buttons,
        .nbuttons       = ARRAY_SIZE(gpio_buttons),
        .poll_interval = 100,
};

Ik gebruik hier de gpio-keys-polled dinges omdat ik de interrupt-lijn naar de i2c-IO-expander niet aangesloten heb; deze driver gaat gewoon eens in de 100ms (ik dacht dat het in ms was) die in de poll_interval staat de toetsen langs om te kijken of er iets ingedrukt is. Als je wel werkende interrupts op je GPIOs kan krijgen, kan je dat vervangen door gpio-keys en de poll_interval weglaten.

Rest alleen nog de gpio_keys struct te refereren in je platform data:

C:

static struct platform_device *carambola_devices[] __initdata = {
        &carambola_i2c_gpio,
         &gpio_keys_device,
};

Hierbij heb ik alleen het &gpio_keys_device-regeltje toegevoegd.

En dan zou het moeten werken

[ Voor 4% gewijzigd door Sprite_tm op 13-05-2014 22:36 ]

[Bikkel70]

Bedankt voor je uitgebreide uitleg Er komt meer bij kijken dan ik dacht.
Ik ga er Vrijdag mee aan de slag.

[rick.berge]

Hartstikke gaaf projectje. Bij mij zou het weer mislukken waarschijnlijk heb ik niet genoeg geduld

Overigens kan een telefoon met doek dit ook natuurlijk (wel stuk minder leuk!).

[Sprite_tm]

* Sprite_tm doet een schop geven...

Nu er een hoop andere zaken (zomerkamp, andere projecten, ...) voorbij zijn kan ik weer wat tijd aan dit project geven. Uiteindelijk moet dit geheel redelijk naadloos in de originele wekkerradio komen en zal er dus een net printje gebakken moeten worden om de oorspronkelijke PCB te vervangen.

Ten eerste: het mechanische gedeelte. Te beginnen bij het display:

Hmm, die past niet helemaal. Daar moet ik wat weg gaan snijden.


...en ik ben blijkbaar niet de eerste die dat gedaan heeft: om de oorspronkelijke 7-segments-unit erin te gooien is er blijkbaar ook al gesneden. Typisch en wat onverwacht voor een massaproduct als dit.

We moeten ook een printplaat erinzetten. Het probleem bij deze printplaat is dat de mechanische onderdelen nogal nauw komen: de PCB moet netjes op de plek van de oude passen en alle knopjes moeten op dezelfde plek zitten. Dat betekent veel meten, en zelfs dat is niet allemaal even makkelijk. Eerst dus maar eens een barebones PCB-ontwerp maken met daarop alleen de mechanische onderdelen:


En dan is de vraag: past het ook? Het is een optie om er vertrouwen in te hebben en dit ontwerp direct naar de PCB-bakker te sturen, om daarna eventueel extra revisies nodig te hebben als het niet past... Vroeger zou ik dit ontwerp uitgeprint hebben, de print op een stuk karton geplakt hebben en zelf alle onderdelen eringeprikt hebben. Tegenwoordig heb ik echter een speeltje wat dat veel beter kan doen in een materiaal wat me ook nog eens beter zicht op de problemen geeft:


Een lasercutter die het ontwerp inclusief gaten netjes in een stukje acryl uit kan snijden.


En het kost dan een paar revisies, maar uiteindelijk past alles netjes.


En ook de altijd belangrijke knopjes lijken precies op de bedoelde plek uit te komen.

Verder moet het geheel ook gevoed worden, en daar ben ik eens over gaan denken... Het trafo'tje wat erinzit heeft twee windingen: eentje waar 4VAC uitrolt en een tweede waar 6VAC uitrolt. De 6VAC is gezekerd op 250mA op het originele printje. De 4VAC-winding is niet gezekerd, maar de kortsluitstroom daarop is ongeveer 1.5 keer zo groot als de andere winding; ik gok dat ik er veilig zo'n 400mA uit kan trekken.

Ik heb de volgende spanningen nodig:
• 3.3V, 0.5A voor de Carambola linux-module (1.5W)
• 5V, 0.05A voor de radio-PCB (20mA) en evt USB-support (0.5W)
• 12V, 0.1A? voor het OLED-display. Er staat niet gespecced wat 't ding maximaal eet en ik heb het nog niet kunnen nameten. (1.2W)

Het plan om dat te krijgen is nu:
• 3.3V: de 4V gelijkrichten en afvlakken levert plusminus 5V (ongestabiliseerd) op. Die kunnen we door een buck-converter heentrekken (ik zit aan de el-cheapo MC33063 te denken) om 3.3V te krijgen. Als we uitgaan van 1.5W max en een efficientie van 80% in de buck-converter trekken we dan 0.375mA uit de 4V-lijn. Die is dan vrijwel compleet gebruikt.
• 12V: Door middel van het gelijkrichten dmv een spanningsverdubbelaar van deze spanning kunnen we uit deze winding 15V krijgen. Hier kunnen we dan weer een 7812 oid achter knopen om zo de 12V voor het display te krijgen. Aangenomen dat het display 100mA vreet (ik denk dat het veel minder is), snoept dat ongeveer 200mA (vanwege de spanningsverdubbelaar) uit de 6VAC-lijn.
• 5V: Dit hangt er een beetje vanaf of ik wat aan de USB-lijn wil knopen. Als ik alleen de radio wil aansluiten kan dat waarschijnlijk wel met een 7805 op de 12V-lijn; als ik meer nodig heb ben ik beter af met een buck-converter. Ik heb nog 50mA headroom op de 6VAC-lijn (mits mijn OLED-stroomverbruik is wat ik gok) en dit is ook ongeveer het budget wat ik dan voor de 5V-rail heb.

[B_FORCE]

Poeh, een MC33063, kon je niks meer gedateerd vinden
Tegenwoordig zijn er een hoop "el cheapo" regelaartjes die een stuk efficiënter en beter zijn.
Ook zou ik de spanningsverdubbelaar weglaten en daar een boost converter voor gebruiken.

Maar goed er zijn altijd meer wegen naar Rome.

[Sprite_tm]

Een MC3306 kost geen drol en zie ik overal in embedded zooi nog gebruikt worden, maar als je een beter alternatief hebt hoor ik dat graag Ik moet verder nog eens meten wat dat oled-display nou precies vreet, dan kan ik wat beter kiezen wat ik wil doen. Een switchmode converter voor 1mA is ook weer zo jammer

[B_FORCE]

Alternatieven zat
Maar het hangt van zoveel dingen af, SMD, niet-SMD, max belasting, budget, verkrijgbaarheid enz enz enz.
LM2675/LM2594 etc zijn wel prima. Daar kun je ook 3.3V varianten van krijgen, wat weer in componenten scheelt.

Maar zoals je zelf zegt, soms is een simpel regelaartje met enkel een weerstandje en diode (evt torretje) ook helemaal prima.

[Sprite_tm]

En ik ben weer wat verder

Ten eerste heb ik besloten om de stroom die het OLED-scherm uit de 12V trekt te meten. Dat lijkt uit te komen op zo'n 20 a 30mA; da's dus minder dan waar ik vanuit ging. Mooi.

Wat minder mooi is, is dat mijn prachtige idee om de verschillende wikkelingen van de trafo te gebruiken om verschillende dingen aan te sturen, niet werkt... Het lijkt erop dat de trafo enige interne weerstand heeft, en zodra ik probeer bijvoorbeeld de Carambola van de 6VAC-lijn te voeden (via een bruggelijkrichter en een DC-DC-printje) wil 'ie niet starten.

Mijn idee was dat het waarschijnlijker practischer was om beide spanningen op een grote hoop te gooien en het idee van B_FORCE te gebruiken: flikker er gewoon voor elke spanning een DC-DC-converter tegenaan. Beginnen met een hoge spanning scheelt ook weer qua diode-losses: ik verlies bijvoorbeeld op de 6VAC-lijn in het oorspronkelijke plan zo al 1.4V in de diodes. Da's jammer vermogen.

Dit is dus de uiteindelijke oplossing waar het wel mee werkt:


De 6VAC en de 4VAC-lijnen staan nu in serie en lopen een spanningsverdubbelaar in zodat ik uiteindelijk zo'n 22V overhoud. Hierop staan twee DC-DC-converterprintjes die voor de 12V en de 3.3V zorgen. 5V genereer ik hier nog niet maar dat kan op dezelfde manier. Met deze configuratie start de Carambola netjes op en word de trafo ook niet eens enorm warm.

Verder heb ik nu ook genoeg info om het printje verder te kunnen maken:


Een paar geintjes die ik eringestopt heb:
• MC33063s zijn hier inderdaad misschien niet de beste keuze. Ik ben gegaan voor een AOZ1282CI, een 1.5A switchertje in een 6-pins package die op bijna een halve MHz schakelt.
• Onder de Carambola zit een PCM2912 USB-naar-audio-converter. Ik kon het toch niet laten om de mogelijkheid open te houden om MP3'tjes op mijn wekkerradio te spelen De PCM2912 heeft een uitgang die laag word op het moment dat 'ie data aan het uitspelen is; die gebruik ik om een analoge switch aan te sturen die schakelt tussen de radio en de PCM2912. Op die manier komt er altijd herrie uit de wekkerradio, ook al is mpd gecrashed of is er een share niet beschikbaar oid.
• De RTC is vervangen door een DS3231. Dat is een wat nauwkeuriger chipje dan degene die ik eerst had, en het zetten van een alarm is bij deze chip direct al in de driver ondersteund.
• De IRQ-lijn van de RTC loopt naar een flipflop toe die de radio aanzet. Op die manier gaat de radio altijd aan als het tijd is om wakker te worden, zelfs al is de Carambola zelf hopeloos gecrashed. De Carambola kan de radio weer uitzetten door een lijn te togglen.

Nou is het nog even de PCB nakijken en opsturen. Dan zooi bestellen, solderen en hopen dat de magische rook er niet uitkomt

[B_FORCE]

Ik snap het nog niet helemaal.
Je gaat eerst een spanningverdubbelaar gebruiken om vervolgens alles weer naar lagere spanningen te krijgen?
Kun je dan niet beter een step-up converter gebruiken voor de 12V?
Dat lijkt me een stuk efficiënter, scheelt daarnaast componenten, kosten en ruimte op PCB
De 3,3V en 5V kun je sowieso uit de 6Vac en 4Vac halen

[Sprite_tm]

Het idee is dat ik de diode-losses zo klein mogelijk wil hebben Die zijn met full-wave rectification altijd 1.4V, of dat nou met verdubbelde of 'normale' spanning is. Relatief gezien is het in de spanningsverdubbelende configuratie echter maar de helft van het vermogen Plus ik kan mijn buck-ontwerpen zo gewoon netjes copy-pasten.

Let wel: spanningsverdubbeling klinkt hier erg 'eng', maar het is maar een heel simpele schakeling die voor zover ik kan zien niets danwel niet veel inefficienter is dan de normale brugcel-config.

[B_FORCE]

Ik ken een spanningsverdubbelaar (klas 1 practicum 1?? )
Je kunt trouwens ook shotky diodes gebruiken, dan zijn je verliezen al kleiner.

Met een normale brugcel config heb je overigens lagere rimpel, maar dat is voor zulke elektronica niet echt een issue.
Uiteindelijk maakt het qua absolute efficiëntie niet veel uit volgens mij.
Misschien is het meer het idee.
Eerst je spanning omhoog gooien om vervolgens naar beneden te halen klinkt niet erg efficiënt.
Maar goed zoiets kun je gewoon berekenen en simuleren.
Aan de andere kant, als het werkt, dan werkt het

Die AOZ1282CI is wel een rare trouwens.
Bij de grote leveranciers niet eens te krijgen

[The Eagle]

Je bent nou al 2,5 maand bezig. Hoe wordt jij sinds je begonnen bent wakker?
(En is je hele project dan nog wel nodig?)

[Osiris]

The Eagle schreef op zaterdag 19 juli 2014 @ 14:37:
Je bent nou al 2,5 maand bezig. Hoe wordt jij sinds je begonnen bent wakker?
(En is je hele project dan nog wel nodig?)

Alsof het eindproduct het belangrijkste is Vaak is de weg er naartoe veel interessanter/leuker/belangrijker

[Whatson]

The Eagle schreef op zaterdag 19 juli 2014 @ 14:37:
Je bent nou al 2,5 maand bezig. Hoe wordt jij sinds je begonnen bent wakker?
(En is je hele project dan nog wel nodig?)

Met de wekkerfunctie van zijn telefoon natuurlijk. Daar heeft hij per dag ingesteld hoe laat hij gewekt wil worden.

[Sprite_tm]

B_Force: Digikey heeft 'em en ik ben niet aan het bouwen om productierijp te zijn dus single-source is goed genoeg

En deze wekkerradio is een tweede die ik op Marktplaats gescored heb. Ik ga mijn hoofd-wekker niet slopen voor de andere af is

En de print even laten liggen voor ik 'em opstuur is een goed idee: ik bedenk me net dat ik de intensiteit van het display van het omgevingslicht af wil laten hangen. Leuk, maar dan heb ik daar wel een sensor voor nodig en een plek op de PCB om 'em aan te sluiten

[ Voor 35% gewijzigd door Sprite_tm op 19-07-2014 16:13 ]

[B_FORCE]

Dan kun je bijna nog beter een u-controller voor alles nemen.
Zelfs step-down kun je via een u-controller doen.

Sowieso zou ik dan de mogelijkheid behouden om bv die intensiteit te kunnen tunen.
Simpel potje ertussen en je bent al klaar.
Vaak bedenk je ineens toch, en dan kun je niet meer terug.

[Sprite_tm]

W'rom? Je hebt tegenwoordig hele mooie ambient light sensoren die je direct op de i2c-bus die ik al heb kan drukken. Deze is bijvoorbeeld nog geen euro, en doet meteen aan geintjes als IR-licht-compensatie. Mijn logica kan die uitlezen en dynamisch commando's richting het OLED-scherm sturen om de intensiteit aan te passen. In de software kan je dan ook meteen elke random intensiteits-contrast-curve drukken die je maar kan verzinnen.

[B_FORCE]

Het is meer dat je inmiddels zoveel functies nodig gaat hebben, dat ik me afvroeg waarom niet alles via een centrale ucontroller te doen.

Overigens, is dat ding niet een beetje overkill?
Een LDR of fotodiode werkt ook prima?

[kELAL]

Vraag ik me zomaar af waarom je persé de bestaande trafo wil handhaven. Trafo's <10VA, die geen primaire zekering behoeven, staan nou niet echt bekend als rendementswonder.
Ik zou zeggen: Doe eerst een rendementsmeting voor je verder gaat. Mijn natte vinger zegt dat je met een (EuP / ErP Stage 2 compliant) SMPS makkelijk €3 op jaarbasis bespaart.

edit: En de nazaten van Edward A. Murphy zouden het fijner vinden als niet alleen de RTC, maar ook de radio battery backup had...

[ Voor 21% gewijzigd door kELAL op 20-07-2014 15:49 . Reden: aanvulling ]

[ThinkPad]

Klopt, wekkerradio trekt zo 7-10W SMPS is dan beter lijkt me.

[Sprite_tm]

Da's op zich een punt.... heb ik wel een betrouwbare SMPS nodig die ook nog in het doosje past; een buitenkant die ik helemaal hetzelfde laat en dan een smerige brick of wall-wart vind ik eigenlijk niet echt kunnen.

Jullie nog suggesties voor kleine 12V/5W oid PSUs? En dan het liefst wel dingen die ik een beetje veilig in kan bouwen; een el-cheapo Chinese stekkeradapter ontmantelen is waarschijnlijk een brandgevaar naast mijn bed Ik zit al naar kleine Meanwell blokjes te kijken, maar die zijn stiekem mest prijzig: 12V/5W is EUR15 ofzo.

En kELAL: Dat het geheel me zelfs bij stroomuitval kan wekken bedoel je? Hmja, dat kan wel... maar nu is het plan een cr2032 intern te gooien en daar de komende jaren genoeg aan te hebben. Als ik de RTC ook nog eens actief werkend moet hebben heb ik ws een grotere accu nodig. ik denk dat ik het er maar op gok: ik heb me afgelopen 5 jaar ook nooit door een stroomstoring verslapen.

[B_FORCE]

Ik ken je maten niet precies, maar kijk eens op www.elpro.org. (Netzgeräte)
Tussen de 4 en 9 euro moet wel lukken. (PS-05 of NFM-05 serie ofzo)
Neem aan dat je vast nog wel wat andere donderdelen nodig hebt, kun je die gelijk bestellen

Scheelt je trouwens gelijk weer voedingsdeel achter de trafo, spanningverdubbelaar en regelaar voor de 12V

[ Voor 25% gewijzigd door B_FORCE op 21-07-2014 13:29 ]

[Springuin]

Mornsun LS05 serie: http://nl.rs-online.com/w...er-supplies-smps/7864731/
Moet nog wel een elcotje bij en evt een paar andere randcomponenten en houd wel een vrij behoorlijke ripple over.

[Sprite_tm]

Voordat ik ga designen, misschien eerst eens kijken hoeveel ik hiermee opschiet... Meten dus! Als het geheel idle is meet ik:

Primair: 16.38mA@227V = 3.72W
Secundair: 165mA@7.95V= 1.311W

Da's dus een efficientie van 35%. Hmm, goed is anders. De vraag is echter: Ga ik er veel op vooruit? Stel je voor, ik haal een RAC03-12SC power supply'tje: 12V, 3W. Ding kost zo'n EUR13.50 inc BTW. De datasheet zegt dat ik een efficientie van zo'n 70% kan verwachten. Bij een primaire load van 1.31W is dat ongeveer 1.87W. Dat betekent dat ik zo'n 1.8W bespaar.

Als ik de nieuwe PSU eringooi, kan ik me een aantal onderdelen besparen: de 12V buck-regulator kan eruit en ook de 4 220uF-caps kunnen verkleind of weggelaten worden. Een kleine berekening bepaalt dat dit ongeveer EUR3.50 aan onderdelen scheelt. Betekent dus dat de switched mode power supply EUR10 aan mijn BOM toevoegt. Uitgegaan van de vuistregel dat 1 Watt ongeveer 2 Euro op jaarbasis kost, zou ik dat dus binnen 2.5 jaar terugverdiend hebben. Kan dat uit? Ik denk het wel. Ik ga zo'n SMPS eringooien.

....athans, dat was mijn idee. Ik heb ze eens bekeken, en ze hebben allen een minimale lengte van 37mm. Laat ik op z'n max eens 36mm hebben op de plek waar eerst de transformator zit, en ergens anders kan ik de PSU ook niet lekker kwijt Zelfs die LS05 van Springuin is 37mm lang. Die is theoretisch gezien dan plat genoeg om diagonaal te passen... maar dan gaat het in de hoogte weer niet lukken. Als iemand me nog een niet-onbetaalbare PSU-module kan aanraden die een mm of meer kleiner is houd ik me aanbevolen, maar zoals 't er nu voor staat blijft de originele trafo er gewoon inzitten.

[ThinkPad]

Waarom de PSU eigenlijk niet gewoon extern in de vorm van een adapter?

[Sprite_tm]

Zoals ik een paar posts geleden al opmerkte: ik wil de wekkerradio extern 100% hetzelfde laten.

[B_FORCE]

Je kunt toch wel 1/0.5mm van je printplaat af prutsen + 0.5-1mm van de behuizing afsnoepen?
Welke afmetingen kun je precies kwijt?
Dat zoekt voor ons ook makkelijker.

[Sprite_tm]

Ik wil 'em in het gat van de trafo gooien. Dat is namelijk het veiligst (compleet omringd door plastic) en op de hoofd-printplaat heb ik eigenlijk geen ruimte. Ik kan wel het plastic rond de plek waar de trafo zit wegslopen, maar dan ga ik weer een hoop moeilijkheden krijgen met dat netjes te doen en daarna de print vast te zetten... da's me die 3 euro per jaar niet waard.

De ruimte die ik heb is 36x28x26mm. Niet extreem ruim dus...

[Sprite_tm]

* Sprite_tm geeft het topic een schop... Ik heb een tweetal weekjes terug de laatste hand aan het design van de PCB gelegd en ben toen op vakantie gegaan. In die tijd heeft een goedkope Chinese toko die printjes gefabriceerd en gister kwam het resultaat aan:


Het ontwerp is op een aantal puntjes wat veranderd tov de WiP die ik julie liet zien. De belangrijkste punten: er is een aansluiting voor een light sensor bijgekomen (feitelijk niet meer dan een headertje met 3.3V, i2c en een interrupt-lijntje) en ik heb het ontwerp zo gemaakt dat 'ie in tweeen te breken is en het printje waar het OLED-display op kan onder een hoek van 90 graden op de hoofd-PCB gezet kan worden:

Let niet op het DIP40-ding in de rechterbovenhoek; ik had nog PCB-ruimte over en besloot een extra ontwerpje voor een ander project mee te sneaken

Nou, kijken of het allemaal werkt dan maar! Na wat zagen liep ik echter meteen al tegen het eerste probleem aan: het OLED-PCBtje past niet in de behuizing:

Gelukkig zat er toch niets op die hoek van de PCB en kon het dus veilig weggedremeld worden. Alles lijkt daarna wel te passen.


Daarna gaan we het printje incrementeel opbouwen. De PSU komt eerst: als ik die fout opbouw kan ik 24V op mijn 3.3V-lijn hebben staan en dat wil ik liever niet als er dure zaken achterhangen:

Het printontwerp is stieken een beetje gehaast afgemaakt ondat ik het zaakje op de post wilde doen voor ik op vakantie ging, en het eerste gevolg liet zich hier al zien: blijkbaar had ik een diode er verkeerdom opgezet. Niets wat niet snel te fixen is, en uiteindelijk kreeg ik netjes een stabiele 5V, 12V en 3.3V uit de buck-convertertjes.


Puntje twee: De USB-geluidskaart-chip. Hier ben ik tegen de tweede faal aangelopen: de chip zat 90 graden gedraaid ten opzichte van hoe 'ie moest. Gelukkig is dit chipje vrij degelijk en na desolderen en opnieuw eropkwakken werkte 'ie netjes. Ik test 'em met een USB-lijn naar mijn PC, da's makkelijker dan met de Carambola die 'em uiteindelijk moet aansturen.


En hier is 'ie met de radio aangesloten. Het hele switch-idee werkt prima: als de geluidschip niet actief is speelt gewoon de radio, maar zodra er herrie uit de chip komt schakelt het geheel om en hoor je dat.


Daarna de rest maar opgebouwd. Hier nog een close-up van de verbinding tussen het OLED-scherm en de hoofd-PCB. De verbinding is best stevig en electrisch degelijk; ik ben er stiekem wel blij mee.


Het boot! Maar niet netjes: de USB-geluidskaart word niet herkend en het OLED-scherm houd er halverwege het booten mee op...

En dan kom je erachter dat het echt geen goed idee is om nog onderdelen te verschuiven vlak voor je op vakantie gaat:

Niets wat een bodge wire niet op kan lossen, maar ik moet misschien een volgende keer toch echt eerst schema's tekenen...


Dat leek de grootste problemen wel op te lossen, en zo ziet het resultaat eruit:


Money shot van de nieuwe PCB:


Okay, wat rest er nog? Natuurlijk moet er nog een hoop aan de wekkerradio-software gebeuren: web-besturing moet ingebouwd worden, het ding moet daadwerkelijk alarms kunnen zetten etcetera. Daarnaast moet er nog het een en ander aan de kernel gebeuren: de lijnen naar de knopjes zijn veranderd en de ambient-light-sensor-driver moet nog de juiste data krijgen om te gaan werken. De hardware is echter als het goed is nu 100% af.

[B_FORCE]

Hahaha, top!
Had niet verwacht dat je het ZO serieus ging maken.
Zo te zien kun je er nog een paar verkopen

[Damic]

Bodge draad, ik zou het kristal demonteren dremel nemen en een gleufje slijpen/zagen

[Sprite_tm]

Had ik aan gedacht, maar je zit toch met een redelijk makkelijk te beinvloeden kristal en een lijntje naar het display waar behoorlijk wat data overheen gaat... om ervoor te zorgen dat die elkaar niet door parasitaire capaciteit beinvloeden heb ik toch een bodge wire gepakt

[Sprite_tm]

FYI: Ik heb 'em af

[ThinkPad]

Supertof!

Wat nog een leuke aanvulling zou zijn is een Nixie font: http://dribbble.s3.amazon.../193387/nixie_numbers.jpg dat zou het helemaal awesome maken Moet er met zo'n OLED nog redelijk accuraat zien tov een echte nixie denk ik

Edit: Zoiets is gratis te downloaden: http://www.dafont.com/nixie-one.font?text=13%3A37

[ Voor 32% gewijzigd door ThinkPad op 18-09-2014 21:35 ]

[franssie]

Echt geniaal project, heel erg van de tussenstanden genoten en fantastisch om te zien dat het je gelukt is. Durf bijna niet te vragen hoeveel uur er in zit (zo'n display controller uitvogelen moet volgens mij echt nachten werk zijn), een hobby mag wat kosten

[Anoniem: 187449]

geweldig !

[azerty]

Echt geweldig inderdaad! Petje af!

[Sprite_tm]

franssie schreef op donderdag 18 september 2014 @ 21:49:
Echt geniaal project, heel erg van de tussenstanden genoten en fantastisch om te zien dat het je gelukt is. Durf bijna niet te vragen hoeveel uur er in zit (zo'n display controller uitvogelen moet volgens mij echt nachten werk zijn), een hobby mag wat kosten

Hehe, die display controller was ik redelijk snel achter, vooral omdat dit niet het eerste display was wat ik aangestuurd had; ik kon zowel voor het prototype als de uiteindelijke driver 85% van de code van oude projecten recyclen. De meeste moeite heeft eigenlijk gezeten in het netjes inelkaar draaien van de uiteindelijke wekkerradio-code: voordat je daar alle features in hebt zitten die je wilt en het ook nog eens (hopelijk...) foutvrij draait ben je wel even bezig.

@allen: bedankt voor de complimenten

[B_FORCE]

Zeker weer een leuk en out-off-the-box project (as usual, volgens mij is het je handelsmerk )
Mooi om te zien dat het allemaal nu werkt

[conara]

Heb even gezocht, maar kan niks vinden wat je gebruikt om te verbinden met het wifi netwerk ect. Kan je hierover iets meer vertellen? Erg leuk project en heeft een erg mooi eind resultaat!

[ Voor 17% gewijzigd door conara op 19-09-2014 16:14 ]

[Fusioxan]

Sprite_tm in "[EiP] Wekkerradio++"

Wat ik nog wel had liggen is een Carambola, een iets duurder (EUR22) en iets krachtiger (2x zoveel flash en ram) bordje. Die dus maar gebruiken.

Hij heeft dus een Carambola gebruikt.

OT:
Leuk project geweest! Heb er uitermate van kunnen genieten (brengt je stiekem ook weer op nieuwe ideeen.

[MrMilco]

https://mancave.conrad.nl/wekkerradio-met-linux/

Ook al bij de "Mancave" Van Conrad te zien haha

[Joen]

Ik kom hier dankzij Raven in "wekkerradios lopen ineens te snel storing van iets."
Wat een gave wekker is dit geworden! Als dit los te koop zou zijn en niet te duur zou zijn zou ik het zo kopen! Echt gaaf!

Ik zou er zo een oude wekkerradio voor opofferen, maar ik heb totaal geen verstand PCB's, componenten en daar dan ook nog eens Linux op werkende krijgen.

[Raven]

Sprite_tm schreef op zondag 4 mei 2014 @ 22:54:
Okay, dit weekeind weer wat verder gekomen. Osiris: ik ga er geen Raspberry Pi ingooien, maar onder een Linux-boardje kom ik toch niet uit, if any omdat ze geen drol kosten en het te comfortabel devven is. Ik zou een bordje willen hebben wat in principe maar minimale processing-power en RAM hoeft te hebben, maar onboard WiFi lijkt me dan wel weer handig, en het moet klein genoeg zijn om in de radio te passen.

Na

gezien te hebben (om wat specifieker te zijn: 47m18s) moest ik aan bovenstaande denken.

Een Pi Zero met ingebakken wifi, die speaker-kit en het type display dat jij al had zijn een mooie basis voor een project als dit. Erg verleidelijk om zelf eens te doen