38 kHz via PCF8574

hallo,

ik probeer in te schatten of het geen wat ik wil doen überhaupt wel mogelijk is.
ik wil met een raspberry pico via een PCF8574 (extended I/O) een infrarood led laten knipperen met 38 kHz.
daarvoor moet ik over I2C met 38kHz de infrarood led aan & uit sturen.
gaat dat qua timing ?

Heel simpel: Nee.

o..........:)

is de I2C dan de beperking ?

gaat het dan wel met b.v. UART of iets dergelijks ?
de raspberry pico heeft simpelweg niet voldoende I/O pinnen.

[Bericht gewijzigd door trix op (24%)]

Dat moet je ook niet willen. Kun je niet extern moduleren?

Nee, 38kHz is een periodetijd van 26,3 micro seconden. Dus je moet een pin toggelen elke 13 microseconden. Standaard I2C klokrates zijn 400kHz en 1Mhz en je moet minimaal 8bits naar die PCF sturen (plus start,stop of restart condities). Dat gaat niet werken. Je Kan wel de 38kHz carrier maken met bijvoorbeeld een 555 (of kan misschien rechtstreeks met de pico (niet bekend met dat geval) en dan alleen de modulatie via de PCF8574.

Op zondag 14 juli 2024 18:39:06 schreef JoWi:
Je Kan wel de 38kHz carrier maken met bijvoorbeeld een 555 (of kan misschien rechtstreeks met de pico (niet bekend met dat geval) en dan alleen de modulatie via de PCF8574.

die zou ik dan b.v. op de kathode van de infrarood led kunnen aanbieden, en de rest (modulatie heet dat blijkbaar) op de anode.

edit: tussen de PCF8574 en de infrarood led zit ook nog een ULN2803.

Maak een vrijlopende oscillator van voldoende stabiliteit (kristal plus delers?) en geef die een "enable" vanuit de PIC.

ik begin me nu toch zorgen te maken en vooral te twijfelen.

die 38kHz is de "draag golf" (word dat zo genoemd?)voor de infrarood led, dat was wel duidelijk.
het betreft 24x een infrarood led die om beurten ieder 4 mSec hoog worden.
is die 4 mSec wel te doen via een PCF8574 ?

de raspberry pico heeft simpelweg niet voldoende I/O pinnen.

Ik zou eerder 2x een pico nemen dan voor tijd kritische zaken een IO expander gebruiken.

In principe kan je de 2de pico ook als een io expander zien die je eventueel via I2C kan aansturen. Maar voor de eenvoudig zou ik denk gewoon de uart gebruiken. Op de 2de pico programmeer je dan de 38kHz en de 4mS pulsen

is wellicht een goed idee :+

ik begin nu ook in te zien dat voor tijd kritische zaken een PCF8574 mischien niet zo handig is.

Je zou eens kunnen kijken naar de i2C Bridge Ic's van NXP. SC16IS760IBS

Die dingen zijn leuk om drukknoppen in te lezen en relais en ledjes aan te sturen die niet tijd kritisch zijn.

Misschien is zelfs een PIC sowieso niet optimaal voor zo'n korte tijden? Ik ken die familie weinig - ik zit eerder in de hoek van Arduino/ESP32/... - maar, zonder het hele verhaal te kennen (dat komt er slechts met brokken en beetjes door) vraag ik me af of dit project niet beter in hardware wordt gerealiseerd.

Is het veel gevraagd om het ruime plaatje te schetsen?

je haalt nu voor de 2e keer pic aan (ik dacht eerst dat het een vergissing was).
maar ik gebruik een raspberry pico :)

ik zal eens wat schetsen.

[Bericht gewijzigd door trix op (11%)]

4 milliseconden is iets heel anders dan 13 microseconden. Die 4ms ga je gemakkelijk halen, de vraag is alleen hoeveel het mag afwijken.

De PCF8574 heeft een maximale clockrate van 100kHz, en een complete transactie is 20 bits, aangenomen dat je de bus tussentijds vrij geeft. Dat geeft een update rate van 5kHz. Als je data blijft sturen, dus niet steeds een nieuwe transactie start, kun je de uitgangen elke 9 bits updaten, dus op ongeveer 11kHz, maar dan kun je dus geen ingangen en uitgangen door elkaar gebruiken.

Ik zou altijd meerdere controllers met verschillende software vermijden als het kan.

Ah, sorry, die PCF leek voor mij duidelijkerwijs een PIC. Mijn fout!
Raspberry is heel wat performanter, maar zelfs een "full-blown" Raspi zal inderdaad niet genoeg i/o hebben.

Daarom blijf ik bij mijn idee: doe meer dingen in hardware.

En om meer i/o-lijnen te maken, eerder 74xx595 gebruiken dan iets met I2C.

[Bericht gewijzigd door Paulinha_B op (14%)]

Op zondag 14 juli 2024 19:56:12 schreef SparkyGSX:
Ik zou altijd meerdere controllers met verschillende software vermijden als het kan.

daar ben ik ook nog niet zo van overtuigd, die 4 mSec komt niet zo heel nauwkeurig.

ik heb dit al werkend gehad met een atmega 32, die heeft 32 I/O pinnen, en dat was net genoeg.
maar ik wil een nieuwere modernere versie maken, en omdat ik al met de raspberry pico bezig ben, wil ik die hiervoor ook graag gebruiken.

edit: ik heb nodig:
- 24x output pin met 38 kHz draag golf
- UART, via een max 485, dus ook een read/write output pin
- 3x led voor controle
- eigenlijk nog 5x input pin voor adressering (dipswitches) die had ik op de atmega 32 niet, adres zat "ingebakken" in de code.

Paulinha_B: een Pi pico is iets compleet anders dan een Raspberry Pi, alleen van dezelfde organisatie. Een RP2040 heeft 30 GPIO pinnen, maar bij de veel boards zijn ze niet allemaal bereikbaar, dus heb je er netto een paar minder.

26 dus, en als het echt moet 27 (de onboard LED gebruiken)

O. Alweer leer ik wat bij. Dank!

paulinha_B heeft me wel aan het denken gezet met die schuifregisters.
eens die schets afmaken (was ik al aan begonnen).

[Bericht gewijzigd door trix op (27%)]

Dat is een goed idee, maar ik ben vooral benieuwd naar het totaalconcept. En ik denk dat ik daar niet alleen mee sta.

Wordt het een olifant met 24 poten? Of een waterkunstwerk met 24 spuitmonden? Drone met 24 motoren/propellers?

En ook: ik dacht direct aan een Arduino met Atmega32, maar toen was ik nog in de waan dat er met PIC gewerkt werd, en dat lijkt toch wel een heel verschillende wereld te zijn. Maar als de Atmega32 goed werkt, blijf daar dan toch bij? "Never change a winning team" wordt er wel eens gezegd. En die processor is nog helemaal niet voorbijgestreefd, evenmin als het Arduinobordje dat erop berust.

Enne, ja, die 38kHz heet "draaggolf" - in een enkel woord, weliswaar - maar in het hoognieuwnederlands is dat nu "carrier" geworden.

[Bericht gewijzigd door Paulinha_B op (54%)]

klinkt ook beter ;)

een snelle schets voor de beeld vorming:

O, het gaat dus over een soort van bewegingsdetectie, wellicht twee- of misschien zelfs driedimensionaal?
De zenders moeten toch enkel gemoduleerd worden in een vast permanent ritme? Dat kan perfect in hardware, waarschijnlijk nog simpeler ook - denk maar eens aan drie stuks 4017 in cascade - maar er is wel synchronisatie nodig met de ontvangers. Het lijkt me eigenlijk dat de ontvangende kant best wat lastiger kan worden dan de zendende.

2D, een schuif register (die jij voorstelde) moet denk ik ook gaan (als dat geen timing beperkingen geeft met de draag golf). dan heb je niet veel pinnen nodig.

edit: je had wat aan je post toegevoegd, synchronistatie zender & ontvanger is geen probleem, ze worden beide gestart vanuit een "hoofd PCB".

[Bericht gewijzigd door trix op (31%)]