2x interrupt werkt niet

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

Hier niet. Dit is een AtMega op 8 MHz. Die heeft maar 209 cycles per pulse en daarmee moet die 2 interrupts afhandelen. Gaat net.

PS Bovenstaande code was fout, maar is nu aangepast.

ik ga dat testen, maar dat word pas donderdag.

Op 31 maart 2020 21:39:55 schreef deKees:
... Gaat net...

Dan moet hij nog een andere atmega programmeren die gesynchroniseerd is met deze om de ontvangers in te lezen en de gegevens te verzenden.
Er zitten nog enkele zware programmeersessies aan te komen.

Volgens mij werd er veel te weinig nagedacht over dit project, maar dat is mijn mening.

Eén ding is zeker, hij zal veel bijgeleerd hebben en wij?...dat moogt ge zelf invullen

edit: heb nog eens het topic herlezen die Arco hierboven aanhaalt en ik moet zeggen dat de timing van 300µs/led wel heel optimistisch was en die 4ms/led die je nu gebruikt wel heel lang is.

Firmware maken is eerst lang nadenken over hoe 't zo efficient mogelijk kan worden aangepakt.
Zomaar beginnen en dan proberen de boel te 'tweaken' en werkend te maken kan wel werken, maar geeft bijna nooit optimaal werkende firmware.
(je moet overal de boel gaan vertimmeren wat niet goed gaat, omdat de fundering al niet deugde)

Zoiets simpels moet je fluitend met iedere microcontroller werkend kunnen krijgen.
(ik heb zoiets zelfs lang geleden met een 8048 gemaakt op 128 kanalen... )

klopt wel, het is een beetje "trail & error". als je de "fundering" in 1 keer goed wilt maken, zul je wel op voorhand moeten weten hoe alles werkt, en dat is niet het geval. dan zul je je dus vooraf volledig moeten inlezen hoe het dan allemaal in elkaar steekt, zeer veel werk,.....en saai.
ik heb het al vaker aan gehaald, mijn project is zeer goed op te delen in verschillende blokken, waar bij ik 100% zeker ben dat het technisch gezien mogelijk is, het is alleen de vraag of ik dat ook kan, maar wat dit soort dingen aangaat heb ik veel geduld, en doorzettings vermogen, en ik leer graag.
ik probeer het ook te zien als allemaal deel projecten, die samen 1 project vormen.

en ik weet julie hulp, en inzet enorm te waarderen. ik hoop dat ik het nog ooit kan goed maken.

de code van dekees getest, en de 8e LED is nu inderdaad niet meer zo lang.
maar nog wel langer dan de andere, is nu 8 mS i.p.v. 4 mS. ook sluiten de poorten niet "naadloos" op elkaar aan, er zit een gat tussen van c.a. 64 mS (te zien rechts boven in LA)
ik ben nog zoekende, maar ik heb voor als nog geen idee waar dat vandaan komt

nee, klopt wel , dat gat van 64ms is natuurlijk de tijd dat de 2 andere bytes actief zijn,....alleen daar zit de LA niet aan.

in de code heb ik de volgorde v/d poorten in de switch/case veranderd zodat het klopt met de volgorde op de PCB.

edit: de 8e
led heeft nu ook een lengte van 4 mS, kan het even niet verklaren.

nog wat verder getest, en het ziet er niet verkeerd uit. maar ik denk dat ik zo meteen wel een probleem krijg. eerst een printscreen v/d LA. en een foto van mijn test opsteling, omdat foto's altijd leuk zijn natuurlijk.
op de LA zie je op de onderste 8 lijnen de LED aansturing met 2 "meetlijnen" (A & B) om de tijden v/d pulstrein te checken.
de bovenste 8 lijnen zijn de IR ontvangers (TSOP 4838) direkt op de ontvanger gemeten.
LED met rode lijn zit tegen over TSOP met rode lijn
LED met gele lijn zit tegen over TSOP met gele lijn.
enz enz.
de LED's op PINB2 en PINB 4 zijn donker gemaakt met een dopje te zien op de foto. als PINB2 hoog is (oranje) kijk ik straks alleen naar de TSOP met de oranje lijn, die is dan natuurlijk hoog of laag afhankelijk of de TSOP licht of donker is. alle andere TSOP-en zijn hoog omdat deLED met een kegel kijkt.
ik post straks wel mijn vraag.

Indrukwekkend, das zeker.

Ik denk dat ik uw vraag ken

Antwoord:
Je zult geen printen die achter elkaar liggen tegelijkertijd kunnen scannen.

andere vraag dus:

nu heb ik voor de ontvanger (TSOP) zijde een pulstrein gemaakt op dezelfde manier als de 4 mS pulstrein van de LED's. wel het 38 kHz gedeelte "er uit gesloopt".
dus nu moet ik binnen de 4 mS dat de LED hoog is kijken of de bijbehorende TSOP hoog of laag is.
en over dat kijken heb ik een vraag, en wel over het moment, en over de lengte v/h kijken.
- als ik op hetzelfde moment kijk dat de LED hoog word, kijk ik mischien te vroeg en zie ik een "0" waar ik eigenlijk een "1" hoor te zien.
- als ik te kort kijk detecteer ik mischien onterecht een dipje.
het lieft zou je natuurlijk ergens in het midden willen kijken voor b.v. 2 mS. en dan beslissen of het een "1" of een "0" is. maar dat zijn een hoop extra bewerkingen.

de vraag is eigenlijk: zou dat allemaal nog mogelijk zijn met de Atmaga16 ?

Op 4 april 2020 17:01:53 schreef MGP:
Je zult geen printen die achter elkaar liggen tegelijkertijd kunnen scannen.

waarom niet ?

of ik begrijp je niet goed.

Ik dacht dat je je meerdere printen na elkaar ging plaatsen om zo aan uw 300 leds te komen, zo had ik dat in ieder geval in mijn geheugen.
Sorry als dat zo niet is.

Op 4 april 2020 17:17:17 schreef trix:
de vraag is eigenlijk: zou dat allemaal nog mogelijk zijn met de Atmaga16 ?

Waarom zou die dat niet kunnen, hij moet geen 38kHz opwekken, enkel 24 poorten op de gepaste tijd inlezen.

dat doe ik ook, wat je op de foto ziet x12. dus 12x LED PCB naast/boven elkaar en 12x ontvanger PCB naast/boven elkaar.
op de foto is de scanner horizontaal geplaatst, maar dat word straks vertikaal.
maar waarschijnlijk denk je dat dan b.v.
IR LED #1 vanpcb #1
ontvanger #1 van PCB #2 belicht.
dat hoop ik op te lossen d.m.v. de gevoeligheid te regelen. en dat wil ik weer doen door v/d 38 kHz weg te regelen.

inderdaad geen 38 kHz, maar ik ben bang dat het lastig word om de boel synchroon te houden met de pulstrein v/d/ led's.

[Bericht gewijzigd door trix op 4 april 2020 18:45:08 (13%)

Om de boel synchroon te houden zullen ze met elkaar moeten "praten", de ene of andere controller moet het startsein geven aan de andere, dat kan door een extra stuur optische verbinding.

Ik heb gisteren nog wat gespeeld met zo'n verbinding en moet zeggen dat die ontvangers heel gevoelig zijn, zelfs als ik op de led een zwart buisje steek dan nog is het belicht oppervlak >10cm diameter.

nog even een verhaaltje wat betreft de gevoeligheid:
ik heb hier de hele tijd lopen te vermelden dat ik een TSOP 4838 gebruikte, en dekees had dat ook keurig geprogrameerd.
nou valt straks mijn oog op het bakje waar ze in zaten, en daar stond TSOP 4836 op..???...krijg nou wat, ik had toch de 38kHz versie besteld, tekst niet te lezen op het component (word echt tijd voor een electronische microscoop) bestelbonnen erbij gezocht,..en inderdaad ik had de 36kHz versie besteld.

dus ik heb de hele tijd een TSOP 4836 met 38kHz belicht. en dat ging goed (wel met een afstand van 18 cm. moet 80-90 cm. worden).
dus toch natuurlijk geprobeerd wat er gebeurt als ik hem wel met de benodigde 36 kHz belicht. nou den werd de TSOP4836 dus veel te veel belicht, en zag je in de nu mooie strakke puls op de LA wat dips. het zwarte afdek dopje op de foto was dus niet toereikend, met mijn hand erboven had ik weer een mooie strakke puls.
dus terug veranderd, en ben ik nu weer een TSOP4836 met 38kHZ aan het belichten. kan natuurlijk zijn dat wanneer ik de afstand verhoog naar de benodigde 80-90 cm. (is nu 18 cm. op de foto) het weer moet aanpassen.

Op 4 april 2020 18:52:03 schreef MGP:
Om de boel synchroon te houden zullen ze met elkaar moeten "praten",

nee, ik stuur vanuit de hoofd PCB (atmega2560) tegelijk een start naar de LED's en een start naar de ontvangers. deze gaan dan beide tegelijk hun eigen pulstrein afwerken.
ik heb dat straks getest, v/d LA 1 kanaal op de 24e led en 1 kanaal op de 24e ontvanger, weet even de exacte tijden niet meer, maar het was in ieder geval geen probleem.

Dan praten ze toch met elkaar maar dan via een andere controller

Waarom je geen gemeenschappelijk 38kHz signaal gebruikt en met een transistor de led aanstuurt begrijp ik nog altijd niet, de controller zou veel tijd over hebben en dan kun je ook de sterkte gemeenschappelijk regelen.
Je zou dan ook de zender controller kunnen gebruiken om de ontvanger controller te sturen.

Een TSOP reageert op minimum 10pulsen van die 38kHz wat neerkomt op 0.3ms, daarmee zou je veel sneller kunnen scannen al gebruik je een veelvoud daarvan.

ik was dat in het begin ook van plan, een extern 38kHz signaal, maar dan met allemaal schuifregisters (74HC595). ik ben daar vanaf gestapt omdat ik er al snel achter kwam dat de ontvangstzijde sowieso een controller moest hebben (om tijdelijk data in op te slaan), anders haalde ik de gewenste snelheid niet. maar vooral om de PCB eenvoudiger te kunnen houden, met een controller heb je alleen een weerstand nodig om de LED aan te sturen. en met een transistor heb je meer componenten nodig, is meer ruimte, meer soldeerwerk.
en als je alles goed teld (soldeer tijd meenemen, al is het hobby) is een controller amper duurder.
ook belangrijk is nu dat mijn PCB voor de LED's en ontvangers hetzelfde zijn.

edit: o ja....ik had die pulstrein van 38 kHz in blokken van 4 mS een beetje onderschat,..ik dacht dat het geen enkel probleem zo zijn.
maar dankzij de programeer kunsten van dekees is dat toch nog goed gekomen.

Je kunt de printen allemaal exact gelijk houden.
Gewoon om en om een ir led en een ir receiver gebruiken. Geeft tevens wat meer afstand tussen 2 receivers.

bedoel je dit ?

led----------->receiver
receiver<-----------Led
led---------->receiver
receiver<-----------Led
enz.
enz.

Ja,

Dan kun je aan beide zijden exact dezelfde print gebruiken.

ik heb nu ook exact dezelfde printen, alleen waar bij de LED een weerstand zit, moet ik bij de ontvanger een draadbrugje plaatsen.
bovendien word met jou methode het programma een stuk complexer.

net de afstand vergroot naar de benodigde 85 cm. en het werkt net zo goed als bij 18 cm.

Wat vraag je dan op als de inputs ingelezen zijn? gewoon de 3 bytes van de portA B C ?

Op 4 april 2020 18:43:31 schreef trix:
...
maar waarschijnlijk denk je dat dan b.v.
IR LED #1 vanpcb #1
ontvanger #1 van PCB #2 belicht.
dat hoop ik op te lossen d.m.v. de gevoeligheid te regelen. en dat wil ik weer doen door v/d 38 kHz weg te regelen..

Dat zal ferm tegenvallen, nog erger dan uw interruptprobleem

Daarom was ik ook zo'n voorstander van een continue belichting, in sterkte geregeld.
Je zou dat nu ook al kunnen testen vooraleer verder te programmeren, eens proberen van bv TSOP#3 uit te lezen met led#4 of led#2 aan en eens zien welke maatregelen je zou moeten nemen.

Op welke afstand passeert dat voorwerp van de TSOP ontvangers?

inderdaad, ik heb de "spreiding" v/d LED eens getest. want in deze opstelling is het natuurlijk niet de bedoeling dat:
LED #1 van PCB 1 ontvanger #1 van PCB2 belicht.
dus ik zet alleen een 38 kHZ pulstrein op LED #1 en ik zet een kanaal v/d LA op ontvanger #24, dan blijft het allemaal op 1 PCB, en als dit gaat dan gaat het met 2 PCB's zeker.
ik heb als uiterste 30 kHz & 50 kHz geprobeerd, de 24e ontvanger blijft gewoon reageren op de 1e LED.
nog eens de stroom door de led bepaald (I=U/R) U=3,39 V en R=180 ohm dus I = bijn 19 mA. die kan nog wat lager denk ik, maar lager als 10 mA lijkt mij niet verstandig (volgens mij heb jij (MGP) dat ook al eens aan gehaald).

edit: het voorwerp paseert in het midden, dus zeg 35-40 cm.

LED is een tsal 6100

bovendien word met jou methode het programma een stuk complexer.

Kwestie van alleen een paar i/o pinnen van functie wisselen...
Dat zou ik er graag voor over hebben als alle printen identiek waren dan...

Op 5 april 2020 11:33:30 schreef trix:
ik heb als uiterste 30 kHz & 50 kHz geprobeerd, de 24e ontvanger blijft gewoon reageren op de 1e LED...

Als je daar nu geen oplossing voor zoekt is het mogelijk dat je daardoor gans uw project moet omgooien of hermaken.
Spelen met de frequentie is niet aan de orde, je hebt dan veel kans dat de TSOP begint te 'oscilleren'...maw de kans dat je verkeerde signalen binnenkrijgt is zeer groot, dat heb ik gemerkt bij mijn testen.

Minder dan 10mA kan ook, ik zou zelf zeggen dat >10mA te fel is.
NB. mijn testen worden ook met een TSAL6100 gedaan, een led met 10° openingshoek.