[delphi] i2c via lpt1

[Verwijderd]

ik heb een hardware interface gebouwd van lpt1 naar i2c bus, nu moet ik die alleen via software aansturen ik heb SDA uit op pin 14 (auto feed), SDA in op pin 11 (busy), SCL uit op pin 17 (select) en SCL in op pin 15 (error).

Zijn hier bestaande componenten of dll's voor? zoniet, hoe krijg ik die aansturing voor elkaar in win 98 / delphi 5. ik heb op zich wel een devicedriver voor lpt1, maar ik weet niet hoe ik hiermee om moet gaan. Ik kan wel een waarde naar de poort sturen, lezen lukt ook, maar hoe kan je met de goede snelheid bijvoorbeeld een clocksignaal doorgeven die niet moeilijk gaat doen als je aan een window sleept

[Verwijderd]

laatst ben ik dit tegengekomen. Als ik het goed herinner werd er mbv van assembler inn Delphi handmatig de signalen voor SCL en SDA gemaakt.

Morgen zal ik ff kijken of ik eea nog voor je kan vinden. Eerst belangrijke dingen doen...

[Creepy]

Op woensdag 06 februari 2002 20:17 schreef mophor het volgende:
ik heb een hardware interface gebouwd van lpt1 naar i2c bus, nu moet ik die alleen via software aansturen ik heb SDA uit op pin 14 (auto feed), SDA in op pin 11 (busy), SCL uit op pin 17 (select) en SCL in op pin 15 (error).

Zijn hier bestaande componenten of dll's voor? zoniet, hoe krijg ik die aansturing voor elkaar in win 98 / delphi 5. ik heb op zich wel een devicedriver voor lpt1, maar ik weet niet hoe ik hiermee om moet gaan. Ik kan wel een waarde naar de poort sturen, lezen lukt ook, maar hoe kan je met de goede snelheid bijvoorbeeld een clocksignaal doorgeven die niet moeilijk gaat doen als je aan een window sleept

Je kan al rechtstreeks de parallele poort aansturen? Wat is dan nog het probleem?
Een signaal hoogzetten, een bepaalde tijd wachten, signaal weer laag zetten. Als je "perfecte" timing wilt hebben (lijkt me sterk...) dan zul je moeten gaan kijken naar een real-time os. Met pre-emptive multitasking OS (zoals windos schijnt te zijn) weet je nooit precies wanneer jou proggie weer processor tijd krijgt.

[Verwijderd]

Op donderdag 07 februari 2002 09:34 schreef Creepy het volgende:

[..]
Als je "perfecte" timing wilt hebben (lijkt me sterk...)

Hij wil een klok signaal sturen, en dat is een vrij preziese aangelegenheid.

[Verwijderd]

volgens mij was het i2c protocol nogal vergevingsgezind. Als ik me goed herinner mocht het kloksignaal schommelen tussen de 10 en 20 KHz ofzo, niet zo snel dus.

Als ik een highpriority thread maak, en daarin de timing gewoon met een bult nop's doe, zou dat werken. (dit heb ik uit de help van delphi gevist)

heeft iemand hier ervaring mee?

edit:

trouwens, het aanspreken van de hardware gaat in korte "bursts" waar iets van 40 kloktikken in gaan (start commando, 4 bytes, 4 x een ack tik en een stopcommando) binnen die tijd (wat dus ongeveer 4 ms duurt) moet de klokfrequentie tussen die 10 en 20 khz liggen. Is dit door windows bij te houden op de hierboven beschreven manier?

[edit2]
is die highst priority thread in delphi trouwens ook meteen de highest priority task voor heel windows? of kan windows nog hoger gaan zitten?
[/edit2]

[Verwijderd]

via lpt1 komt ook een interruptlijntje binnen. een idee was om een thread daarop te laten letten.
Moet ik die thread dan hoge (om te zorgen dattie de interrupt snel genoeg doorheeft) of een lage prioriteit (om te zorgen dat de performance van de rest van je programma niet omlaag gaat) geven?

[Creepy]

Hmm.. ik zou ff kijken of er snel genoeg op de interrupt wordt gereageerd met een thread op normale prioriteit...

zo nee, dan zo hoog mogelijk gaan zitten..