Svenska ElektronikForumet

Hej!
Jag jobbar nu på Min robot
Problemet är just nu IR-kommunikationen. Jag försöker skapa modulerade pulser som ska vara 400-800uS långa.

Jag använder INTOSC 4MHz och har försökt att få till pulserna med NOP instruktioner, men pulserna verkar bli olika långa, ovh vi pratar inte lite olika utan typ 50uS avikelse ibland, så nu undrar jag:

Kan det vara så att INTOSC är så oexakt att pulserna blir fel?

Här menar du alltså ±1%... och då får du kolla i databladet men jag tror inte att du kan förvänta dig bättre.

Dessutom en liten men ganska stor fel: mhz
Menar du mHz som i milliherts? Eller MHz som i MegaHertz?
Det skiljer liksom 10^9...

Hertz förkortas Hz, inte hz.

Jag vet, jag är en gnällspik men någongång kommer det att hända att du skriver m när du menar M och/eller vice-versa och i vissa situationer kan båda värden vara "legala" (alltså vettiga) och då blir det ordentligt fel. Av den anledning är normenklaturen viktig.

Sen är det svårt att svara på utan att veta vad det är du försöker göra.
D.v.s koden...

+-1% verkar mycket rimligt för den, har för mig att det kunde gå upp till +-3% nästan när jag kollade (hadde liknande problem). Mitt tipps är en kristall. (Gärna 20MHz så hinner man tänka mycket )

Mvh

Vad skall pulserna göra? Är det till att styra RC-servon eller liknande? Är det gitter som Du avsermed olika långa, eller långtidsdrift? Gittrar den så kollaatt strömmen håller bra kvalitet. Ser den ut som en taggatrå så fungerar det därefter.

Angående enheter: Slarv! Ändrat det nu.

Pulserna är till för IR-kommunikation med olika långa pulser för 1 0.
Koden kan sägas att den är den enklaste nåfonsin(nästan)

ut_pwm_puls=1 betyder då att dioden pulsas med PWM och inte bara lyser

ut_pwm_puls=1 IR-dioden pulsas med PWM enheten
NOP vänta ett antal NOPs, dvs rätt tid för tex 0
ut_pwm_puls=0 sluta pulsen

Mottagaren ligger bara och väntar på att pinnen med IR-mottagaren på blir 0, som då ger interuppt som väntar tills pinnen blir 1. Då lagras TMR0s värde i en variabel, som sedan skickas till datorn.

Men om ni säger att INTOSC skulle kunna vara problemet så tror jag nog det blir att testa med kristall.
Dock inte än på ett tag, är hos några släktingar över julen, roboten är ca 30-40mil härifrån....

Marta: Tror jag förstår, dvs matningen skulle vara för dålig för att driva dioden?

Nej, inte för dålig för dioden, men för dålig för PIC så att INTOSC gav gitter. Fast det är ju inte det som var Ditt problem tydlien.

För att bara skilja mellan pulser som har ett så stort pulsförhållande så borde INTOSC fungera som det skall. Med 400 och 800µs så skulle ju 50µs gitter inte behöva störa. Det låter dessutom mycket att ha det gittret om allt fungerar.

Är det en interruptrutin eller huvudprogrammet som genererar timingen? Finns det någon interrup igång? Så mycket gitter låter som att det är interruptrelaterat.

Pulserna skapas inte med interuppt utan med NOPs och en loop.

På mottagar sidan används interuppt från TMR0.
När IR-mottagaren sänker inteuppt pinnentill 0 så ges ett interuppt.
först nollställs TMR0 och sedan startar en loop som bara kör en NOP tills pinnen blir logisk 1, dvs IR signalen är slut. Då lagras TMR0s värde i en variablel som sedan skickas till datorn.

I datorn kan man då se att pulserna varierar ganska mycket.
Tex. om pulsen ska vara 600uS ut från sändaren så skickar mottagaren kanske värdet 560uS-660uS till datorn.
Men det är 2st PICar som körs med INTOSC, det kanske blir för oexakt?

"gitter"... menar ni "jitter"? alltså instabilitet...

50µs @ 1MHz cy = 50 instruktioner = inte jitter men närmre en ISR eller liknande precis som Marta skriver.

När jag kommer hem så får jag ta och testa med kristall, först med 4MHz så att den nuvarande koden fungerar, för att sedan optimera till 20MHz.
Vilket blir om ca en vecka...

MEN: Det är Julafton imorn! God Jul!