2x interrupt werkt niet

de ontvanger (b.v. #12) weet wel welke LED oplicht, dat kan er maar 1 zijn, namelijk #12.
vandaar aan beide zijde (zender/ontvanger) het "looplicht"

Op 29 maart 2020 19:19:48 schreef trix:
de ontvanger (b.v. #12) weet wel welke LED oplicht, dat kan er maar 1 zijn, namelijk #12....

...weet welke led..?? hoe doe je dat als ze gescheiden opgesteld staan.

Edit: vergeet niet als alle ontvangers één of alle zenders zien zul je een soort kakofonie krijgen.

[Bericht gewijzigd door MGP op zondag 29 maart 2020 19:28:19 (17%)

Is dit een herhaling van dit topic??: https://www.circuitsonline.net/forum/view/143258

herhaling......eerder een voortzetting
zoals eerder gemeld, er lopen meerdere topics die hier verband mee hebben.

dit is een oude foto, hier wou ik nog schuifregisters gebruiken voor de LED's. het zijn er hier ook maar 16 i.p.v. 24.
ik hoop dat dit het wat duidelijker maakt.

hier staat ook nog een post van MGP in:

MGP
Gepost donderdag 6 december 2018 17:30:16 |Quoten
Deze namiddag heb ik enkele testen hierop gedaan, een pic geprogrammeerd op 38kHz met een ir-led en een TSOP4838 en de uitgang volgt alles wat ik doe, zoals ik dacht.

De modulatie werd gemaakt met timers van 20ms tot 2sec en geen enkele keer werd een fout gezien ook niet bij lange werking op dezelfde modulatiefrequentie.
Bv. 3min op 50HZ als 3min op 0.5Hz.

De andere proef was eens handvat van een kleine schroevendraaier zo snel mogelijk door de lichtstraal zonder modulatie geslingerd en ik kon de opstelling niet foppen, telkens werd de beweging gedetecteerd.

Maw, het systeem leent er zich prima toe om te gebruiken als lichtsluis.
Voor verdere proeven moet de TS er zich maar over ontfermen, de componenten kosten maar een euro, daarvoor hoeft hij het niet laten.

Wat ik wel denk is dat zijn systeem niet te maken is wegens het immense werk dat eraan verbonden is.
Niet alleen de opstelling maar nog meer de afscherming van de naburige fotocellen en leds ook al gebruik je industrieel materiaal.
Maar dat zal hij zelf al wel begrepen hebben.

Ik wilde enkel maar sommige beweringen checken

Man man man, had je dat eerder gepost dan hadden we ons 60 posts bespaard.

Probeer nu maar, DeKees heeft u meer dan een handje toegestoken

dat is zeker zo, ben er ook zeer blij mee.

[Bericht gewijzigd door trix op maandag 30 maart 2020 14:46:33 (13%)

hoi,

ik heb de code uitgebreid naar 24 LED's, en dat werkt goed.
nu zit ik met iets wat een probleem kan worden, ik denk dat het in de hardware v/d atmega zit, maar ben daar niet 100% zeker van.
het is namelijk zo dat iedere 8e IR Led (dus PINB7, PINA7 en PINC7) duidelijk feller brand dan de anderen. dit bekijk ik met de camera van een goedkope telefoon. terwijl de timing v/h signaal en de hoogte v/d spanning gelijk is.

ik heb een filmpje gemaakt waarop dit te zien is,
eerst zie je PINC7 dan PINC6 en als laatst weer PINC7

https://youtu.be/U_lPmq6ekaE

Op 29 maart 2020 20:04:45 schreef trix:
....
.

Ik heb mij zondag nog nooit zo idioot gevoeld

Op 30 maart 2020 17:31:28 schreef trix:
..
het is namelijk zo dat iedere 8e IR Led (dus PINB7, PINA7 en PINC7) duidelijk feller brand dan de anderen. ..

Blijft de 8ste led niet branden na het overschakelen naar de andere poort?

Na de laatste 8ste "case" moet je die led ook nog uitschakelen vooraleer aan de 9de te beginnen.

Aan de hardware ligt het zeker niet.

ga ik bekijken, zou zomaar kunnen.

blijkt toch iets anders te zijn, de 8e LED blijft langer hoog.
de switch van de ene naar de andere poort kost tijd.
het (geforceerd) naar "0" sturen v/d LED verandert niets, hij "pakt" gewoon de tijd die hij nodig heeft voor de omschakeling van de ene naar de andere poort

[Bericht gewijzigd door trix op dinsdag 31 maart 2020 16:06:00 (32%)

Ik zie niks in uw ISR staan die de achtste pin nul maakt.

klopt die heb ik er weer uit gehaald, omdat het toch niet werkte.

Die 8e puls duurt 60mS. Dat heeft niets met omschakelen te maken, er is ergens wat grondig mis in de software...

Op 31 maart 2020 16:39:34 schreef trix:
klopt die heb ik er weer uit gehaald, omdat het toch niet werkte.

Waarom post je dan een screenshot? om ons bezig te houden of wat?

Ik zat hier al 10min te kijken waar je iets veranderd had...

Je signature is u op het lijf geschreven.

[Bericht gewijzigd door MGP op dinsdag 31 maart 2020 16:49:56 (31%)

klopt
in de code die je ziet ben ik van 8 naar 24 LED's gegaan.
dat gaf het probleem dat het 8e LED feller brande.
vervolgens word er geopperd dat het 8e LED mischien niet word uit geschakeld, code toegevoegd en dit getest, maar gaf geen verandering op de LA, dus weer verwijderd.
op deze printscreen is duidelijk te zien dat de 8e bit veel langer aan is,....maar gaat wel uit wanneer de volgende poort begint, dan lijkt het mij ook waarschijnlijk dat het toevoegen van een regel om de led "0"te maken geen zin heeft.

een momentje dan voeg ik de gewijzigde code toe die ik getest heb.
nogmaals, dat gaf geen enkele verandering op de LA.

switch(BitCounter++)
      { case   0: PORTC &= ~(1 << PINC7);
                  CopyPortB = (1 << PINB0); break;
        case   1: CopyPortB = (1 << PINB1); break;
        case   2: CopyPortB = (1 << PINB2); break;
        case   3: CopyPortB = (1 << PINB3); break;
        case   4: CopyPortB = (1 << PINB4); break;
	case   5: CopyPortB = (1 << PINB5); break;		        
        case   6: CopyPortB = (1 << PINB6); break;
	case   7: CopyPortB = (1 << PINB7); break;
				
	case   8: PORTB &= ~(1 << PINB7);
                  CopyPortA = (1 << PINA0); break;						  
	case   9: CopyPortA = (1 << PINA1); break;
	case   10: CopyPortA = (1 << PINA2); break;
	case   11: CopyPortA = (1 << PINA3); break;
	case   12: CopyPortA = (1 << PINA4); break;
	case   13: CopyPortA = (1 << PINA5); break;
	case   14: CopyPortA = (1 << PINA6); break;
	case   15: CopyPortA = (1 << PINA7); break;
			
	case   16: PORTA &= ~(1 << PINA7)                              
                   CopyPortC = (1 << PINC0); break;		 
        case   17: CopyPortC = (1 << PINC1); break;
	case   18: CopyPortC = (1 << PINC2); break;
	case   19: CopyPortC = (1 << PINC3); break;
	case   20: CopyPortC = (1 << PINC4); break;
	case   21: CopyPortC = (1 << PINC5); break;
	case   22: CopyPortC = (1 << PINC6); break;
	case   23: CopyPortC = (1 << PINC7); break;
			
	default : BitCounter = 0;
      }

Op 31 maart 2020 16:49:00 schreef Arco:
Die 8e puls duurt 60mS. Dat heeft niets met omschakelen te maken, er is ergens wat grondig mis in de software...

dat is inderdaad wel erg lang.
dat het wat tijd kost lijkt mij wel mogelijk.

Waarom zo'n ingewikkelde uitdrukking om PORTB nul te maken? ben al enige tijd uit de C taal.
Ben je zeker dat de uitdrukking een 0b00000000 is?

Die 60ms zijn 15 uitgangen van 4mS dus zal er wel wat niet juist zijn in de software en telt de ISR wel juist.

dat het wat tijd kost lijkt mij wel mogelijk.

Een beetje microcontroller voert in die tijd miljoenen instructies uit... (port wisselen is een kwestie van nS, hooguit uS)

Op 31 maart 2020 17:22:27 schreef MGP:
Waarom zo'n ingewikkelde uitdrukking om PORTB nul te maken? ben al enige tijd uit de C taal.
Ben je zeker dat de uitdrukking een 0b00000000 is?

nee, die uitdrukking maakt enkel de 7e bit 0 (die andere waren al 0)
maar ik ga wel met je eerdere gedachtegang mee dat ergens nog die 8e pin gereset moet worden.
vind het wel raar, dat een stukje verderop dat wel gebeurd ?

Die 60ms zijn 15 uitgangen van 4mS dus zal er wel wat niet juist zijn in de software en telt de ISR wel juist.

ik kom op 70 mS, niet echt een direkte relatie met 8 bits o.i.d.

ik kom op 70 mS, niet echt een direkte relatie met 8 bits o.i.d.

Dan klopt je screendump zeker niet, want daar loopt de burst van 24 tot 84ms...

nee, die uitdrukking maakt enkel de 7e bit 0 (die andere waren al 0)

Enkel de shift left is dan al genoeg.

Op 31 maart 2020 17:41:59 schreef trix:

vind het wel raar, dat een stukje verderop dat wel gebeurd ?

Dat komt omdat de ISR perfect zijn werk doet, als de 24 leds zijn afgelopen begint hij opnieuw.
Dus die 8ste bit blijft hoog door uw schuld om het cru te zeggen.

en aub "poke" een 0x00 in die poort(en) dan ze we ervan af

Op 31 maart 2020 17:53:20 schreef Arco:
Enkel de shift left is dan al genoeg.

Niet doen, dat is veel te moeilijk

arco,.....niet om mijn gelijk te halen, maar het is toch echt 70 mS.
start inderdaad bij 24 maar stopt bij c.a. 94. de schaalverdeling is wat raar maar elk streepje is 3,2 mS.

ja ik moet nog eens proberen met het "0" maken van dat 8e bitje. ik wou mijn methode om dat te doen ook in de simmulator testen, maar daar zag ik geen enkele bit hoog of laag worden, wellicht was dat al een teken aan de wand.

ik ben er al wel over uit (dank zij julie tips) dat wanneer je van poortA naar poortB gaat PINA7 niet word gereset, die blijft dan hoog totdat poort A weer aan de beurt is.
dus PINA7 moet ik laag maken wanneer PINB1 hoog word, dat had ik wel goed in mijn correctie, en ik ben er ook zeker van dat PORTA &= ~(1 << PINA1);
de juiste schrijfwijze is. maar waarom dat vandaag dan niet lukte

edit: die 94 mS van mij klopt wel ongeveer want 1 poort duurt 8x4 = 32 mS.
PINA7 komt 1x voor in de cyclus van 3 poorten. 3x32 = 96 mS

Als je de 3 poorten allemaal volledig gebruikt, dan kun je met schuiven ook wel iets doen.

Dan kun je gewoon alles uitzetten in de COMPB interrupt.

Probeer zo maar:

-- Verbeterde versie

#define F_CPU 8000000UL // 8 MHz clock speed

#include <stdio.h>
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>


ISR(TIMER1_COMPA_vect) // 38 khz
{
   static uint8_t PulseCounter = 150;
   static uint8_t BitCounter   = 0;
   static uint8_t CopyPortA = 0;
   static uint8_t CopyPortB = 0;
   static uint8_t CopyPortC = 0;

   if(PulseCounter == 0)
   {  
      PulseCounter = 150;

      switch(BitCounter++)
      {  case 0 :
         {  CopyPortB = 0b00000001;
            CopyPortC = 0;
            CopyPortA = 0;
            break;
         }
         case 8 :
         {  CopyPortB = 0;
            CopyPortC = 0b00000001;
            CopyPortA = 0;
            break;
         }
         case 16 :   
         {  CopyPortB = 0;
            CopyPortC = 0;
            CopyPortA = 0b00000001;
            break;
         }
         default :
         {  CopyPortA <<= 1;
            CopyPortB <<= 1;
            CopyPortC <<= 1;
            break;
         }
         case 24 :
         {  BitCounter = 0;
            break;
         }
      }
   }
   else
   {  PulseCounter -= 1;
   }
   
   PORTB = CopyPortB;
   PORTA = CopyPortA;
   PORTC = CopyPortC;
}

ISR(TIMER1_COMPB_vect) // 38 khz
{  PORTB = 0;
   PORTA = 0;
   PORTC = 0;
}

int main(void)
{
   DDRA = 0xFF;
   DDRB = 0xFF;
   DDRC = 0xFF;

   TCCR1B |= (1 << WGM12); // CTC-mode,
   TCCR1B |= (1 << CS10); // start timer with prescaler = 0

   TIMSK  |= (1 << OCIE1A)
           | (1 << OCIE1B) ; // timer1 A & B compare match interrupt enabled

   OCR1A = 209;
   OCR1B = 100;

   sei();

   for(;;)
   {
   }
}

Om een 38kHz pulstrein te krijgen zal de interrupt toch op 76kHz moeten lopen...

OCR1A bepaalt de frequentie :
8MHz / 209 = 38.2 KHz

OCR1B bepaalt de puls breedte.