Kan man tidsmäta i PLC kod?

[TomasL]

I2C ACK, NACK, START och STOP skickas inte på vanligt sätt utan det handlar om att lyfta eller sänka Datalinan och klicklinan på rätt sätt i förhållande till varandra. I2C är från början helt implementerat i hårdvara men det går naturligtvis att bitbanga om man har adekvat kontroll över hårdvaran.

[Al_Bundy]

Okej. Tackar för förklaringen

[lillahuset]

Jaja, jag har bitbangat I2C i en PIC för att jag inte lyckades få I2C-periferin att fungera. Och i en STM32F103 för att erratan ställde så löjliga krav för att göra en "workaround" pga buggigt kisel. Snudd på trivialt om man inte har för höga krav på hastighet.

[Icecap]

Och jag gör det i en Renesas RX210, av samma orsak: hårdvaran finns men är snudd på omöjlig att få igång.

[Al_Bundy]

Om jag vill styra 5 volts flygplansservos med PWM, vilket chip kan jag använda då som är lätt att använda, som har SPI?

Jag har tittat på MC33999 men det var AU chip och inte DIP.

Kan man använda 555 timers och shiftregistrers?

Edit : fel av mig. 555 timers och digital pot?

[TomasL]

Jaja, jag har bitbangat I2C i en PIC för att jag inte lyckades få I2C-periferin att fungera. Och i en STM32F103 för att erratan ställde så löjliga krav för att göra en "workaround" pga buggigt kisel. Snudd på trivialt om man inte har för höga krav på hastighet.

Jo, men nu handlar det ju inte om att skriva ett assembler program, utan snarare att skriva något som motsvarar det gamla tolkande BASIC-program för en PC och tro att man kan bitbanga parallellportens individuella pinnar med någon större precision.

Pôjken skall ju skriva det hela i Codesys förmodligen interpreterande scriptspråk.

Naturligtvis är det hyffsat enkelt att fixa till i ASM när du har full kontroll på processorn, och slipper dela den med en massa andra program som genererar interrupt stup i kvarten osv.

[lillahuset]

Om jag inte minns helt fel var Philips demo för I2C och PC skriven i GWBasic, eller vad det hette på den tiden.

När jag bitbangade i STM32F103 tror jag jag hade ett systick på 10ms som körde I2C. En operation per tick. Det gick inte fort men det spelade ingen roll, jag har för mig att det var en termometer eller liknande.

Nej, I2C är trivialt bara man sätter sig ner och tänker till lite. SPI är iofs ännu enklare.

[Al_Bundy]

Det får nog bli spi för mig.

Jag har ännu inte löst hur min paj kan både använda en digital i/o som input och output.

[lillahuset]

Trivialt min käre Watson. Finns massor av info på nätet. Vill du ha riktigt roligt kör du https://www.raspberrypi.org/forums/viewforum.php?f=72

[Al_Bundy]

Fast det är Codesys PLC jag kör och inte python

Men som det låter på er så är det möjligt att bygga eget enkelt i2c på en PLC om man inte bryr sig om hastigheten?

Jag byggde mitt eget SPI som har en hastighet på 5 ms och då läser den 8 analoga kanaler.

Har hittat en MAX7219 7-segmentdrivare med SPI styrning och den tänker jag labba lite med.

[TomasL]

Nej jag tror inte du klarar det med Codesys oavsett hastighet.
Dessutom tror jag knappast att du har kunskaperna att skapa kod som kan bitbanga I2C. Detta eftersom du uppenbarligen inte vet vad I2C är för något.

[Mr Andersson]

Det borde väl gå att skriva en kernelmodul som sköter kommunikationen, och sen ett interface mot codesys? rPI har som jag förstått det hårdvaru-i2c så det kanske redan finns drivrutiner.
Eller om det inte går att göra i kerneln (jag kan ingenting om timing-specifikationerna för i2c eller task-switchingen i linux) kör kommunikationen native på en kärna och linux/codesys på de resterande.

[Icecap]

På en RasPi finns det redan hårdvara för I²C.

Huruvida det är möjligt att använda detta från Codesys vet jag inte och jag struntar helt i det också.

Det ska såklart gå att skriva en PLC-funktion som utför I²C-kommunikation, den måste dock köra lite som dasset beskriver: ett steg åt gången.

De PLC jag har jobbat med har nämligen alla haft det så att först när alla task i programmet är utförda kommer slutregisterna att uppdateras gemensamt, därför kan man inte ha ett task som slår på och av en utgång fler gångar per task, den verkliga ändringen sker nämligen inte förrän task'et är slut.

[Al_Bundy]

Jag har lyckats att tidsmäta i koden nu. Högsta upplösningen är i millisekunder.

[TomasL]

Ja det motsvarar ju eoner, typ.