Programuje mikroprocesory( a podobnu haved) :: Remember, remember, the velvet November


node:	Programuje mikroprocesory( a podobnu haved)
template:	3
parent:	Programming
owner:	niekt0
viewed by:
created:	30.05.2005 - 23:16:18
updated:	18.11.2008 - 13:15:28

cwbe coordinatez:
101
63540
2076399
1668140

ABSOLUT
KYBERIA

permissions
you:	r,
system:	public
net:	yes

maniac	0
skurva.	0
tom_myto	0
jonas	0
visby	0
ventYl	0
SEBUTw	0
nino	0
egres	0
danger maciak	0
tali	0
toxygen	0
igggy	0
niekt0	0
rawfare	1
CARBON IN DI...	1
e1m1	2
pole	3
tux	3
w	5
mirny	5
soc	6
maaca	6
milon	7
stanley_ptaaach	7
darmozrac	7
Fen	7
mivalko	7
moky	7
dark matter	7
analogrunner	7
linker	8
mzpx	8
kv4736	8
urza	8
cyboff	8
borg	8
stick	8
Joy	8
****	8
cell	8
rastopato	8
icyak	8
fefo	9
Ternac	9
hlsman	9
wern	9
elite.club.o...	9
abandon	11
s7	11
sandi	12
hexo	12
smrtak	14
nacks	14
robo	14
mr gramma	16
Pieter	16
mrkqua	16
jinx	16
acidmilk	16
uz.nebudem.t...	19
neon	20
wwwnick	24
piece_of_IT	33
Ruza	33
P_N_R	34
sansara13	34
Quorthon	36
dudko	40
BlackDeath	42
laykaa	42

Vsetko o programovani mikroprocesorov vsetkych chuti a farieb, programatory, schemy, zariadenia, vlastna tvorba, zaujimave linky, poziciavanie programatorov;) a tak..

hw.cz
atmel.com
gme.cz
elnec
chipcon

Euros OS
Infineon

0000010100063540020763990166814009307825

Zasa raz sa na FIIT spacha OpenCamp. A zasa na nom budem kecat, hned 2x. Oba talky budu relevantne k embedded.

Prvy talk bude o burani roznych sprostosti, ktore si embedaci medzi sebou traduju o testovani. Zacina o desiatej rano, takze ak ho chcete stihnut, v piatok moc nechlascite.

Druhy talk bude poobede a pokecam o Cybersecurity Resilience Act-e, pricom sa zameriam na specificke zalezitosti ohladom embedded, opensource a jeho aplikacie v embedded odvetvi. Tento talk bude makacka, pretoze o CRA sa da kecat hodiny a hodiny.

Kludne posharujte s embeddakmi mimo kyby. Zvlast s tymi, co o CRA este nepoculi.

Shitty life is like radiation. You can sustain it for long time if daily doses are small.

000001010006354002076399016681400930782509308000

Dlho som na takom neprednasal, ani sa nezucastnoval. Mozno pridem.

000001010006354002076399016681400930782509307905

linky mas naopak...

vyzera to zaujimavo, mozno sa dojdem pozriet

00000101000635400207639901668140093078250930790509307981

dik, fixnute

Shitty life is like radiation. You can sustain it for long time if daily doses are small.

0000010100063540020763990166814009294650

Zaciatkom roka som si rozchodil nejake zakladne benchmarky a porovnal skore CMRXu a FreeRTOS. CMRX ma zatial vykon niekde na urovni 30 - 60% toho, co vie FreeRTOS. V niektorych testoch ale celkom prekvapivo uz prekonava Zephyr. To je celkom haluz, lebo su to prave tie testy, ktorych skore zavisi na casti kernelu ktora je uplne najtupejsia a vobec nebola optimalizovana (o tom nizsie).

Chcel som vysledky z benchmarkov vykreslit do grafu, aby som videl, ako sa menia v case vzhladom k tomu ako upravujem kernel. Nieco ako ked Phoronix zbehne sadu testov na roznych Linuxovych kerneloch a je vidno, ako sa vykon meni v case. A hej, trocha som sa na ten benchmarking namotal a optimalizovat ma bavi.

Bol s tym ale problem. Niektore testy davaju vysledky v statisicoch, ine v desiatkach alebo stovkach milionov. Ak to vykreslim do jedneho grafu, tie prve budu nerozoznatelne od nuly:

Taky graf moc uzitocny nie je. Mohol by som nahodit logaritmicku skalu na ose Y, to by ale zdeformovalo krivky. Tak som rozmyslal nad inou reprezentaciou dat.

Benchmarky, ktore spustam su benchmarky typu Dhrystone a pod. Procesor robi dookola nejaku monotonnu zataz a zaznamenava sa pocet iteracii, ktore sa stihnu spravit za fixny cas.

Tieto benchmarky su podstatne primitivnejsie nez Dhrystone a su zamerane na to, aby sa zistilo aky je zakladny overhead sluzieb kernelu. Napriklad ako dlho trva systemove volanie, ktore nic nerobi. Alebo ako dlho trva zamknut a odomknut mutex. Skore v benchmarku je teda pocet iteracii za fixny cas.

Mozem teda skore podelit casom a ziskam tak pocet iteracii za sekundu. To ale problem neriesi, pretoze dynamika dat ostane rovnaka. Ja ale viem aj frekvenciu procesora, teda aj pocet taktov za sekundu. Ak pocet taktov podelim poctom iteracii, dostanem "IPC" jedneho opakovania testu - pocet cyklov procesora, ktora jedna iteracia testu trvala. A tu je dynamika podstatne mensia, resp. sa necitatelne stanu tie najnezaujimavejsie data:

V tomto formate uz je mozne mat v jednom grafe data zo vsetkych merani. Zaujimavejsie ale je, ze tu vidno ako dlho trvaju jednotlive operacie.

Zacnime bordovou ciarou uplne na spodku. Ta ukazuje 9.06 taktu na iteraciu a test sa vola "Calibration". Tento test nerobi nic, iba inkrementuje skore. Jeho povodny ucel je zakladne porovnanie toho, ze test je naintegrovany spravne a vsetko funguje +- rovnako napriec operacnymi systemami. Tu sa ale da zistit ze minimalny test, ktory robi toto:

- nacita z pamate premennu s flagom ci test este bezi
- skontroluje flag, ci sa nema ukoncit
- inkrementuje pocitadlo skore
- skoci na zaciatok cyklu

Trva 9 taktov. Vysledok nie je cele cislo, pretoze skore v testoch ovplyvnuje rezia kernelu (o tom tie testy su). Pokial kernel nie je tick-less, tak sa pravidelne spusta obsluha hodin - v tomto pripade 1000x za sekundu, aby skontrolovala ci nie je potrebne prepnut thread, alebo obsluzit nejaky casovac. To pridalo tych 6 stotin k dlzke cyklu navyse.

Zaujimavejsi je napriklad taky prazdny syscall (fialova ciara "System Call Overhead"), ktory je v pripade toho testu volanie get_tid() - read-only syscall, ktory vrati cislo aktualne beziaceho threadu.

Z grafu vyplyva, ze taky syscall trva cca 122 taktov CPU. Systemove volanie v tomto pripade zahrna prechod z userspacu do kernelu cez instrukciu SVC. To automaticky ulozi a opatovne nacita registre. To podla ARMu trva nejakych 12 + 12 taktov. Zvysnych 100 taktov pripada na samotnu obsluhu systemoveho volania. Kedze procesor je ARM, je celkom bezpecne predpokladat, ze 1 takt ~ 1 instrukcia.

Dalej, jeden cyklus synchronizacie (zlta ciara "Synchronization"), co je zamknutie a odomknutie mutexu trva 480 taktov. Jeden taky cyklus spravi dve systemove volania. O tych vieme, ze dokopy stoja minimalne 244 taktov. Takze na samotnu logiku zamykania mutexov ostava 236 taktov (z toho 6 zozerie zakladna rezia testu). Cast z nej je v systemovom volani a cast z nich sa spotrebuje v userspace.

Odoslanie signalu trva 180 taktov (ruzova ciara "Signal Processing"). Odoslanie signalu je tiez syscall. Z toho vyplyva ze cca 120 zo 180 taktov je zakladny overhead systemoveho volania. Odoslanie signalu teda trva dalsich 60 taktov.

To je zaujimava informacia vo vztahu k testu, ktory zistuje vykon preemptivneho planovania threadov (oranzova ciara "Preemptive Scheduling"). Tento test robi v kazdej iteracii odoslanie dvoch signalov. Jeden inemu threadu, ktorym ho zobudza. Druhy posiela sam sebe, ktorym sa zastavuje. Jedno taketo prepnutie threadu trva ~1896 taktov. Z toho 2x 180 = 360 taktov pripada na vrub signalom.

Zvysnych 1530 taktov je overhead kerneloveho planovaca. To je celkom dost ale nie je to prekvapenie. Planovac je jedna z casti kernelu, ktora nebola vobec optimalizovana. Pri kazdom prepnuti threadu sa prehladava cela tabulka threadov, aby sa nasiel dalsi vhodny thread na beh. To je extremne zly a pomaly dizajn.

Trocha zahada je, preco preemptivne prepinanie threadov je skoro 2x pomalsie ako kooperativne. V oboch pripadoch sa vola planovac a v oboch pripadoch robi +- to iste. Meni sa krovie okolo, ale nie dost na to, aby vysvetlilo rozdiel 1000 taktov CPU. Bude zaujimave zistit z akych akcii sa tie testy skladaju. Mozno objavim, ze v jednom z pripadov sa planovac vola viackrat. To bude vela vykonu skoro zadarmo. A fixnuty bug ako bonus :)

Tymto sposobom sa da kernel rozobrat na jednotlive stavebne bloky a zistit, ktora cast je pomala, ktora je rychla a kde sa najviac oplati optimalizovat tak, aby to malo celosystemovy dopad.

Zaroven sa ukazuje, aky velky dopad na vykon ma v tomto meritku usetrenie par instrukcii. Ak sa napriklad systemove volanie zrychli o 10 instrukcii, je to takmer 10% zrychlenie. Zaroven to ale znamena, ze sa usetri 20 instrukcii pri spracovani mutexu - 5% zrychlenie.

Na tie data sa ale da pozriet aj inac. V predoslej verzii trval jeden cyklus zaknutia a odomknutia mutexu nieco malo cez 1000 cyklov. Teraz trva 480 cyklov, To je vyse 2x zrychlenie. Jedna z ciest ako sa toho dosiahlo bolo to, ze som sa pozrel na to, co sa tam vlastne robi.

CMRXove mutexy su v skutocnosti futexy (podobne ako v Linuxe). To znamena ze vacsina ich processingu bezi v userspace a kernel sa vola len ked sa neda inac. Povodna nizkourovnova implementacia mutexov podporovala rekurzivne mutexy, ale verejne API tuto funkciu nespristupnovalo. Ta robota sa ale vzdy vykonavala a to stoji takty CPU.

Zaroven mutexy robili kontrolu, ci nahodou mutex neodomyka niekto iny nez ho zamkol. To je uzitocna funkcia do debug buildu, ale plytva to vykonom v produkcnom prostredi. Zaroven na to, aby sa taka kontrola dala spravit, bolo potrebne urobit jedno dalsie systemove volanie. To je minimalne 122 taktov. Bezne sa odomknutie mutexu niekym inym nez kto ho zamkol povazuje za undefined behavior a neriesi sa to, lebo je to hruba programatorska chyba.

Odstranil som teda logiku na podporu rekurzivneho zamykania a odomykania a kontrolu na to kto mutex zamkol. Zaroven som odstranil aj jedno systemove volanie. Vysledkom bolo skoro 2x zrychlenie kodu.

To ukazuje, ze nie vzdy ma zmysel optimalizovat kroky, ktore v kode su. Obcas sa staci pozriet na to, ake kroky tam su. Niektore z nich su mozno nadbytocne.

Tak si tak pocitam cykly a snazim sa dobehnut, alebo predbehnut FreeRTOS. Aby som mohol tvrdit, ze mikrokernely zdaleka nie su tak pomale, ako si ludia myslia.

Shitty life is like radiation. You can sustain it for long time if daily doses are small.

0000010100063540020763990166814009289734

1. Aj na FOSDEMe 26 budem mat o CMRXe prednasku. Tentokrat porozpravam o tom, ako moze byt nieco tak male ako RTOSko beziace na niecom tak beznadejne slabom ako je mikrokontroller za euro interne lock-free:

Mala tohtorocna zmena: zahadzujem LibreOffice Impress. Miesto toho sa o prezentaciu postara aplikacia beziaca live v CMRXe hostovanom na Linuxe. I eat my own dog food.

2. Dorazil mi link na videozaznam mojej prednasky z FOSDEMU 25. Minuly rok mal streaming znacne problemy a roznym ludom sa stracali segmenty videi. Z toho mojho chyba niekolko asi 90 sekundovych usekov.

Tieto nevyzadane fast-forwardy z toho robia material fakt len pre silne povahy. Kto sa neboji a ma 15 minut casu, tak link je tu:

https://mirrors.dotsrc.org/fosdem/2025/ub4136/fosdem-2025-4390-cmrx-microkernel-based-rtos-with-memory-isolation-on-mmu-less-architectures.av1.webm

3. "Linux hosted build" je uz outdated nazov. Podarilo sa ho portnut aj na MacOS. To otvara cestu k sebemrskacstvu a portovaniu celej tej creepy show na Widle.

Shitty life is like radiation. You can sustain it for long time if daily doses are small.

000001010006354002076399016681400928973409289842

.. see you in Brussels, maybe .. :)

000001010006354002076399016681400928973409289825

kebyže vieš čo môj pes zere…

000001010006354002076399016681400928973409289759

I know some of these words

0000010100063540020763990166814009278281

Moje RTOSko je z principu portabilne, tak som ho preportoval na dalsiu "architekturu" - na Linuxovy system.

Spravene je to tak, ze thready RTOSka su mapovane 1:1 na POSIXove thready a cez dorucovanie signalov sa jednak thready zastavuju a spustaju a jednak sa do threadov injectuju rozne kontexty podla potreby, aby sa emulovalo chovanie bezneho procesora a preruseni.

Ked sa naimplementovalo toto a par dalsich drobnosti, tak vzniklo viac-menej 1:1 prostredie porovnatelne s tym, co bezi na mikrokontrolleroch. Aj ked thready scheduluje Linux, v skutocnosti ich ovlada jadro CMRXu.

Port pouziva iba POSIXove volania, takze je mozne, ze pobezi aj na Widliach a Masoxe.

Ako stress test som si vytvoril jednoduchy window manager, ktory so zvyskom sveta komunikuje cez RPC a renderuje do emulovaneho framebuffra.

Vytvoril som k tomu minimalisticku kniznicu na emulaciu periferii (demo tu), takze sa v tom daju aj testovat drivery, pripadne sa to da strcit do CI a bezat na tom automaticke testy.

No a neviem, komu by to na co bolo, ale... v zasade sa to da strcti aj do cloudu.

Posledna ficura, ktora nie je na tomto porte implementovana, je ochrana pamate.

Shitty life is like radiation. You can sustain it for long time if daily doses are small.

000001010006354002076399016681400927828109278465

vyborna vec!

000001010006354002076399016681400927828109278381

Malo abstrakcii mame, treba nam dalsie a dalsie?! :)
Takze emulator na testovanie software beziacich na cipoch? Nieco jak qemu?
Ked hej, oslobodis stovky programatorov mission critical/realtime software od zbytocneho vysedavania v labakoch.

00000101000635400207639901668140092782810927838109278383

Ak chces emulator, pouzijes Renode. Ten emuluje procesor aj periferie. Pripadne QEMU, to to vie tiez.

Tento mod predpoklada, ze 2+2=4 bez ohladu na to, na akom procaku to pustis a ak vo svojom softe nezavisis na undefined behavior C-cka (co ale sialene velke mnozstvo softu robi), tak je tomu softu v zasade jedno, ci bezi na realnom cipe v labaku, alebo na kompletne inej architekture na sendvici z jadra RTOSka a Linuxu.

Ked si napriklad taky vyvojar GUIka nejakeho embedded geratu, je ti zhola jedno, ci tvoje GUIko s displejom komunikuje cez cycle-perfect emulaciu SPIcka a ICcka, ktore ovlada displej, alebo proste natvrdo zapisuje do memory-mapped framebuffra, ktory ty potom vidis.

Na to, aby si vedel ten widget posunut o tri pixely viac dolava tu plnu emulaciu SPI a cipu nepotrebujes :)

Shitty life is like radiation. You can sustain it for long time if daily doses are small.

0000010100063540020763990166814009271176

OpenAlt 2025 v Brne buducu nedelu.

https://talks.openalt.cz/openalt-2025/talk/review/9FF8ACUEYCFBKVJ3ECAQKUXRWPLR88WR

Rovnaka tema, ine podanie. Menej budem riesit co som postavil a viac sa skusim zamerat na to, co to ludom prinesie a preco by ich to vobec malo zaujimat.

V zaujme zachovania zdravia mojich ocnych nervov tentokrat slajdy ostanu v anglictine. Tiez sa to hodi z toho dovodu, ze o mesiac neskor ich pouzijem na ESE Kongresse v Nemecku.

Shitty life is like radiation. You can sustain it for long time if daily doses are small.

0000010100063540020763990166814009234609

OpenCamp 2025 v BA tuto sobotu.

CMRX: Mikrokernelový RTOS s ochranou pamäte pre mikrokontrollery

Skoro mi ocny nerv zlomilo, ked som slajdy prekladal do slovenciny.

Shitty life is like radiation. You can sustain it for long time if daily doses are small.

0000010100063540020763990166814009215801

https://fosdem.org/2025/schedule/event/fosdem-2025-4390-cmrx-microkernel-based-rtos-with-memory-isolation-on-mmu-less-architectures/

Ak by ste sa tam nahodou niekto mihli, mozeme pokecat.

Shitty life is like radiation. You can sustain it for long time if daily doses are small.

0000010100063540020763990166814009132337

Experimentalny mikrokernelovy RTOS pre ARMove (ale potencialne aj ine) mikrokontrollery s izolaciou pamate.

https://github.com/ventZl/cmrx

Shitty life is like radiation. You can sustain it for long time if daily doses are small.

000001010006354002076399016681400913233709132639

ventZl pobavil :]

0000010100063540020763990166814008793033

From NAND to Tetris
...a to mi toto nemohl někdo ukázat v roce 2007!
https://www.nand2tetris.org
https://www.youtube.com/channel/UC1BDNANKn483ez62k6Ph2JA/playlists
https://www.nandgame.com
https://www.coursera.org/learn/build-a-computer

0000010100063540020763990166814008414122

zhanam Parallella-16 Embedded, nevala sa niekomu na stole? :)

0000010100063540020763990166814008277951

potreboval by som poradit. potrebujem GPIO pinom na rPi zopnut nejaky spinac (nie vykonovy, riadenie kotla, ale proste to musi byt len zopnutie). kupil som toto; - SOLID STATE RELAY ale ukazalo sa to ako nefungujuce.

ked som to meral, tak po zopnuti to ma stale radovo 100ky az 1000ky ohmov odpor (je to vada?) a kotol sa mi nezapne. ked som skusil ten vystup relataka prepojit aj kratkym kablikpom, kotol sa hned zapol. meral som, ake napatie mi da rPi na pine a bolo to okolo 2.7 V. povedal som si, ze moooozno to je nizkym napatim, kedze to relatko ma vstup 3~32V a skusil som tam pripojit 5V z rPi na test. cervena LEDka na relatku svietila silnejsie :) ale inak to stale nefungovalo.

a teda, vedeli by ste mi poradit nejaku suciastku (alebo teda aky typ tranzistora a s akou hodnotou odporu pred nim a strucnym zapojenim) na to mam pouzit, aby som realne urovnou napatia na GPIO pine vedel zopnut nieco "akoby som to prepojit drotom"?

dik

000001010006354002076399016681400827795108277982

aby ti to relatko zoplo, potrebujes
1. dosiahnut napatie na zopnutie relatka. z toho pseudodatasheetu na ebayi vyzera, ze potrebujes aspon 3V
2. vystup musi dodat dostatok prudu na to, aby udrzal kotvu relatka prichytenu (resp. pri solid state relay Gate otvoreny). a toto byva vacsi problem, nez napatie.

takym velmi vzdialenym nastrelom by som povedal, ze budes potrebovat nejaky vykonovy zosilnovac medzi GPIO pin a relatko (riesil som nieco podobne kvoli spinaniu solaru, akurat ja to riadim Atmelom) + by som si dovolil tipnut, ze ak to relatko nie je vysoko citlive, tak si si zaroven odvaril GPIO na raspi (tie asi nemaju protiskratovu ochranu ani ochranu pred nadprudom), preto na nom teraz meras radovo 100 az 1000 ohmov.

Zhanal by som rele Fujitsu JV3S-KT, to ma cievku rated 3V, ale high-sensitive ma "must operate" napatie 2,25V. Pripadne mozes pouzit aj JV5S-KT, kedze niekde v okoli RasPi budes mat k dispozicii 5V napatie. Stoji to par psukov, bezne sa to da zohnat na slovensku v radioamaterovi.

Nic ine ako rele na koncove prepojenie nechces pouzit, pretoze pri comkolvek inom ti hrozi, ze sa ti dostane 230V do 5V okruhu a to nechces. To, ze ti to elektroniku usmazi je to najmenej, horsie je, ze sa mozes dotknut nejakeho obvodu, ze sak je tam len 5V a elektricky prud potrasie ti ud. Teoreticky by si tam vedel urobit izolaciu optoclenom, ale to je vopruz navyse.

Takze zapojenie budes mat asi take, ze vystup z GPIO pozenies cez rezistor na bazu nejakeho spinacieho tranzistora, ja som pouzil BC337. Hodnotu rezistora si zvolis podla datasheetu toho tranzistora tak, aby si pri napati, ktore ti z GPIO lezie dosiahol saturacneho prudu tranzistora a zaroven neprekrocil maximalne zatazenie GPIO pinu. Ak maximalny odoberany prud z GPIO bude mensi ako saturacny prud pre BC337, bude treba pouzit nejaky iny darlington.

Tranzistor pouzijes ako spinaci podla generickej schemy pre spinanie tranzistorom. Jedna vec, na ktoru musis dbat je, ze prechod C-E na tranzistore musis premostit rychlou diodou zapojenou v zavernom smere, inac sa ti po par zopnutiach v tranzistore odpari baza a bude po srande. Je to preto, ze cievka rele tu funguje ako induktivna zataz a ked sa tranzistor rozpoji naindukuje sa velke napatie v opacnom smere, ktore sa natiahne skrz zavrety prechod na tranzistore. A to tranzistory nerady.

Aj by som ti dal schemu tej mojej riadiacej jednotky, ale vznikla zivelne na prototypovacej doske a nemam od nej ziadnu schemu.

Shitty life is like radiation. You can sustain it for long time if daily doses are small.

000001010006354002076399016681400827795108277958

A ked das na ten vstup normalnu baterku cojaviem 9V ? Rele moze byt aj vadne. A kolko mA potrebuje na zopnutie ? Pin z RPi vie dat strasne maly prud.

00000101000635400207639901668140082779510827795808277976

neviem, nenasiel som tam ray parameter. ale cakal by som, ze to bude velmi maly prud, ved naco inak by som to chcel riesit takymto relatkom, ak nie na zopnutie nejakou logikou bez schopnosti zatazenia? ale mozno sa na to len zle pozeram :)

0000010100063540020763990166814008277951082779580827797608278000

Uz mi je asi jasne preco to nejde. Nespinas s tym jednosmerne napatie ? Ma to totiz spinanie pri prechode nulou. Co pri jednosmernom napati pochopitelne nenastane.

000001010006354002076399016681400827795108277958082779760827800008278310

je to dost mozne, resp. velmi pravdepodobne tym spinam JS. dik.

000001010006354002076399016681400827795108277957

To relatko musi byt chybne. Ved tade moze ist 25A, pricom ak ma 100Ohm tak by to hrialo dľa R. I^2. kilowatmi.
Skus ho "zopnute" zatazit napr.rychlovarnou konvicou, bud zhori alebo sa umudri :)

00000101000635400207639901668140082779510827795708277975

dik za "Pro tip" ;)

0000010100063540020763990166814008037651

https://vimeo.com/142347202

Programovanie Lego Mindstorms v C#

0000010100063540020763990166814007745611

cauko, vedel by mi niekto pomoct s http://www.dx.com/p/vs1003-on-board-microphone-mp3-module-blue-152376#.VFJNmaOHVjt
Kedze absolutne o MCU netusim nic, nemam ani tusaka ako to tam nahrat a nemam k tomu ani zalezitosti, potreboval by som len spravit easy program ktory bude pustat zvuk v stanovenych casoch.
http://www.electrodragon.com/w/index.php?title=VS1003_%281053%29_MP3_Dev._Module
Tento kod len upravit a zmenit tie delay, vedel by niekto ako to tam nahrat, pripadne ked ma k tomu vybavenie tak ze za flasu vinae?

000001010006354002076399016681400774561107751494

co to bude ten mp3 modul ovladat? Arduino?

kod co si napisal link je pre master zariadenie, ktore ovlada ten tvoj modul.

00000101000635400207639901668140077456110775149407753337

No po blizsom prestudovani som prisiel na http://www.dx.com/p/isd1820-audio-sound-recording-module-w-microphone-speaker-deep-blue-281751#.VF3vkqOHVjs
co mi prislo ako lepsia volba, pretoze zvuk si nahram len stlacenim tlacika a potom len pustam cez reprak priamo. Samozrejme ovladalo by to arduino s pripadnym RTC modulom.

Ale pri citani datasheetu som narazil na edge a level activated funkcie, tak ma napadlo ze ci jedna z tych funckii (edge a level activated) neznamena ze ked zaznamena na vstupe zvysene napatie (z 0->3.7V napr) tak zacne prehravat, dako som k tomu nenasiel info.
Ak by to robilo to co si myslim ,ze po vybudeni signalom zacne prehravat, tak mi stacia len dake hodinky ktorym nastavim alarm na cas kedy chcem a namiesto budika vyslu signal do ISD1820. Otazka potom je ze aby sa hodinky dali nastavit nech sa alarm napr po 3 sekundach vypne, pretoze inak by trigger zostal v HIGH a bola by vyssia spotreba z baterky ktoru by bolo ISD1820 nabijane (aspon podla datasheetu kde je to viackrat spomenute)

axone main
axone
axone programming
axone Zaujímavosti
axone Umelecke, magicke a aj zabavne PROGRAMOVANIE
axone forumz