Generera IR-signaler med PWM eller UART?

[hanzibal]

...du övertolkar bilden.

I verkligheten är såklart inte IR-signaler så välputsade men jag har som sagt själv syntetiserat en sådan signal med utgångspunkt från denna bild och det funkade bra, t.ex. att byta kanal på TVn o.dyl.

Finns det inget sätt att hantera fysiska register alls??

Nix, man anger period och ON-varaktighet i microsekunder för en cykel, sedan kör den bara - enkelt men oflexibelt:

Kod: Markera allt

        PWM pwm = new PWM(Pins.GPIO_PIN_D5);
 
        const uint period = 3 * 1000;    // 3 ms
        const uint duration = 2 * 1000;  // 2 ms
 
        pwm.SetPulse(period, duration);

> ...att koppla PWM-utgången till en ingång med interrupt...
Å fy fasen vilken lösning...

Blir nog svårt att göra det på annat sätt (se kodexemplet ovan).

> ...STM32F4-rackare i DIL40 på 168Mhz, FPU (!), 1MB Flash och 192kB RAM:

Jahaja, är det alltså typ en sådan plattform som det hela handlar om !?

Är bara på tankestadiet med detta ännu men Cerb40 vore nog som att kavla bulldeg med ångvält

[Icecap]

Moduleringen har egentligen två syften!
1: Identifiera som IR-signal, därav 38 eller 35kHz.
2: Med en duty-cycle på 10% kan IR-sändaren pulsas med högre ström utan att överbelastas, detta ger längre räckvidd.

Behöver man inte maximerat räckvidd kan man köra 50% duty-cycle men för maximal räckvidd gäller 10% eller lägre samtidig som man krämer på med ström i pulserna.

[hanzibal]

Tack, det skall jag komma ihåg när det blir dags. Förstår nu att det nog var detta sodjan menade med att jag övertolkade bilden.

[MiaM]

Nexa är väl dessutom (alltid?) radio och inte IR, så även om man kanske kör samma modulation så är det inte nödvändigt med 10% duty-cycle.


OBS, kolla datablad å sånt för moderna IR-dioder, 10% är nåt som fastnat i huvudet på mig för typ 20 år sen eller nåt sånt, det kan kända att moderna dioder ger bäst signal med lite annan duty-cycle.

[sodjan]

> Förstår nu att det nog var detta sodjan menade med att jag övertolkade bilden.

Ja, ungefär så. Det verkarde som att du läste en schematisk bild av
pulståget som en exakt specifikation av duty cycle. Det är så klart enklast
och tydligast att *rita* det som just 50%, även om det inte är optimalt.
Så det handlade från min sida mest om hur du "läste bilden" och ingenting
egentligen om vad som är bäst eller inte, och 50% fungerar normalt helt OK...

Och att köra en IR-diod över märkströmmen är ju helt enligt spec, se t.ex
den diod som finns med här :
http://www.tradera.com/2st-ir-mottagare ... _158211869
Den är specad som en 100 mA diod, men är OK att köra med upp till 1.5 A
beroende på vilken duty cycle man använder.

[Lennart Aspenryd]

Skall försöka att titta förbi.
och ha en intressant dator med mig!

[blueint]

??

[hanzibal]

Nexa är väl dessutom (alltid?) radio och inte IR...

Ja, jag var lite otydlig där men modulationen är väldigt lik och genom att välja IR-pulståg med omsorg och köra till en TX433 få RF som styr Nexa. Jaga nvände ett PICKit2 för att skapa IR-signalen.

Och att köra en IR-diod över märkströmmen är ju helt enligt spec, se t.ex
den diod som finns med här :
http://www.tradera.com/2st-ir-mottagare ... _158211869
Den är specad som en 100 mA diod, men är OK att köra med upp till 1.5 A
beroende på vilken duty cycle man använder.

Toppen, lade ett bud på dem.

Jag får återkomma när jag testat men tror inte Netduino kan hantera interrupt på 38kHz.

Ett förtydligande: .NETMF (.NET micro framework) är inte interpreterande runtime (som jag felaktigt angav innan) utan exekverar en kompilerad mellankod CIL "common intermediate language" mot ett abstraktionslager HAL "hardware abstraction layer". Mellankoden är ett slags generaliserad maskinkod som funkar på alla plattformar som implementerar .NETMF CLR "common language runtime" och även vanliga .NET framework på en Windows burk och omvänt. Man kan t.ex. skriva klassbibliotek etc och förpacka i DLL-filer (assemblies) så att de funkar lika bra under Windows som på en MCU med CLR i firmware.
http://en.wikipedia.org/wiki/Common_Language_Runtime

[sodjan]

> utan exekverar en kompilerad mellankod CIL "common intermediate language"

Nja, bilden är ju lite komplicerad om man kollar vad som händer.
CIL körs av en CLR som du säger, denna gör en JIT kompilering (alltså
vid run-time) av modul för modul allt efter som de anropas. Detta tar
så klart tid, i alla fall en gång. Poängen är att CIL inte kan exekvaras
direkt utan måste bearbetas av en CLR för att skapa native koden.

Det hela liknar en vanlig Java JVM med JIT.

Jag inser fördelarna (d.v.s plattformsoberoendet), men även nackdelarna,
d.v.s ökad kompexitet, potentiella prestandaproblem och svårigheter
att direkt utnyttja plattformsspecifika funktioner. Det förklarar varför
det är lite svårt att hantera PWM modulen direkt.

> Mellankoden är ett slags generaliserad maskinkod...

Om den inte innehåller någon "native" maskinkod så kan den *aldrig* exekveras
direkt av processorn, enbart läsas och tolkas av en runtime-motor d.v.s CLR'en.
Men OK, dock ofta kompletterar man med teknik i stil med inbyggda JIT kompilatorer.

Sen finns ju "Ngen.exe" (som i princip gör det som JIT gör fast i förväg) men den
verkar bara vara tillgänglig för Windows (?).

[MiaM]

När det gäller kod som ändå inte körs direkt från t.ex. usb-sticka i mikrokontrollern så ser jag egentligen ingen fördel med att inte kompilera den direkt till maskinkod åtminstone när den tankas över till mikrokontrollern.

Man kan ju ha en mellankod ändå på filerna innan de skickas till mikrokontrollern, och göra sista kompileringssteget när koden skickas till kontrollern.

[hanzibal]

Det hela liknar en vanlig Java JVM med JIT.

Precis, jag skippade dock JIT-steget i min text för att grundprincipen skulle framgå tydligare.

Om den inte innehåller någon "native" maskinkod så kan den *aldrig* exekveras
direkt av processorn, enbart läsas och tolkas av en runtime-motor d.v.s CLR'en.

Japp och något annat har jag inte påstått.

Största fördelen tycker jag är att man kan koda prototyper i ett najs även om det faktiskt också finns en del slutprodukter som kör .NETMF. Dock inga volymprodukter etersom det nog är svårt att få ekomomi i sådana.

[sodjan]

OK, då är vi i princip överens om hur det fungerar.
Slutbetyget får vi väl när din applikation är klar och fungerar.

[hanzibal]

Ja, tveksam till att Netduino klarar interrup på 38kHz. Därför skulle jag på något sätt vilja använda UART:en för att AND:a ihop med PWM-signalen men det kan nog bli svårt att synka dem. Vi får se.

Tack för hjälpen så här långt, jag återkommer när jag testat lite.

[jesse]

Nu orkar jag inte läsa igenom hela tråden, men reagerar bara på sista inlägget om 38 kHz interrupt:
Är det sända eller ta emot som avses här?

Om jag hade velat göra en IR-sändare så hade jag valt att låta en timer generera frekvensen och sedan sätta på och av genom att sätta någon on/off-bit för timern.

Om det handlar om mottagning så är väl det bästa att använda en färdig mottagare med inbyggd demodulator. Eller vad är du ute efter här?

[sodjan]

> Är det sända eller ta emot som avses här?

Det var nog jag som nämnde det från början. Jag gjorde något
sådant i en fjärr-applikation för att "tajma" signalerna. Jag visste
att jag skulle köra t.ex 10 st 38 KHz pulser och räknade interrupt
via interruptet från timern som styrde PWM modulen. Det var bara
en räknare att räkna ner, 5-10 instruktioner och processorn hade
hade inget annat att göra under sändning i alla fall.