Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Arduino I2C - SoftI2CMaster
#1
Zarad moglo bi se reci delimicno losijeg inicijalnog dizajna\plana (mada ga ne bih tako strogo ocenio jer je inace prvi projekat, no dobro...), gde sam iskoristio defaultne pinove I2C (A4 (SDA), A5 (SCL)), a gde mi sada treba I2C veza, dosao sam u situaciju da uradim dve moguce stvari:

1. Uradim redizajn seme (nije neki veci problem) i modifikujem PCB (sto je malo veci problem).
2. Iskoristim nesto poput SoftI2CMaster-a i uzmem neke druge slobodne pinove za I2C (...i dosta lakse se izmeni PCB).

E sad, moje pitanje je ako bih se odlucio za ovo drugo resenje koje verujem da vecina ne bi preporucila, zanima me da li ima nekih ociglednih downside-a i koji su?

Koliko sam ja video ovo mu dodje slicno kao SoftwareSerial samo za I2C zar ne?
http://playground.arduino.cc/Main/SoftwareI2CLibrary
Reply
#2
Hm, ako sam dobro razumeo, Ti si A4 i A5 iskoristio za nešto drugo, a sad bi neka druga 2 pina da koristiš za I2C vezu?
Ako je tako, zar nije jednostavnije da ta 4 pina "ukrstiš" negde na PCB i da sve dođe na svoje mesto?
Softverske emulacije I2C standarda na nekim drugim pinovima (ne na fabrički predviđenim za to) u principu rade bez problema, ali mogu da imaju problema sa brzinom - upravo zbog softverske emulacije, koja je sporija od hardverskog rešenja sa A4 i A5 pinovima. Dakle, sve zavisi koje periferije ćeš da povežeš na taj Tvoj softverski I2C. Ako nije nešto brzinski zahtevno, onda to može fino da radi, ali ako se biti priključena neka brža periferija, savetujem Ti opciju 1).
Drugim rečima, ako si 100% siguran da će Tvoja softverska emulacija raditi sa nečim ne mnogo zahtevnim po pitanju brzine - opcija 2).
Ako je periferija brza (ili nisi siguran šta će sve u budućnosti biti prikačeno na taj softverski I2C) - opcija 1).
Reply
#3
Najbolje je da koristis hardverski I2C modul i da se koriste funkcije za hardverski I2C, ako ne znas sam da ih napises. Softverski I2C moze da izgura sve standardne brzine i to nije problem nikakav. Najveci problem kod softverskog I2C-a je taj da imas funkciju za generisanje potrebnog kasnjenja radi postizanja zeljene frekvencije I2C-a. To je uglavnom jedna for petlja. Ako niko ne prekida funkciju za softversko generisanje I2C komunikacije, onda ce to da radi. Ako koristis interapte i ako se javi interapt u toku generisanja softverske I2C, onda se kasnjenje koje se generise softverski povecava za vreme koliko dugo je MCU bio u interaptu. Tu komunikacija puca i vise ne moze da se koristi I2C.
Reply
#4
Ako je Arduino master kao sto si rekao, i ako se koristi obicna I2C komunikacija, mislim da kasnjenje nece uticati, bar ne toliko da pukne komunikacija.Master je bog, on salje klok, slusa kada stigne...
Da je u pitanju SMBus npr, onda bi bila druga prica.
Reply
#5
(12-07-2016, 01:13 PM)yugaja Wrote: Ako je Arduino master kao sto si rekao, i ako se koristi obicna I2C komunikacija, mislim da kasnjenje nece uticati, bar ne toliko da pukne komunikacija.Master je bog, on salje klok, slusa kada stigne...
Da je u pitanju SMBus npr, onda bi bila druga prica.

To je tacno samo ako se koristi hardverski I2C. Ako se koristi softverski I2C, onda dolazi do pucanja komunikacije.
Reply
#6
To je neka osobenost arduina, odnosno biblioteke? Msm istu stvar sam radio nebrojeno puta na raznim platformama.... Sve dok je obicna i2c, bez timeouta na strani periferije, radilo je.
Istana je doduse da nisam koristio arduino platformu Smile
Reply
#7
(12-07-2016, 01:38 PM)yugaja Wrote: To je neka osobenost arduina, odnosno biblioteke? Msm istu stvar sam radio nebrojeno puta na raznim platformama.... Sve dok je obicna i2c, bez timeouta na strani periferije, radilo je.
Istana je doduse da nisam koristio arduino platformu Smile

Mora da ispoštuje tajming a to može da bude problem sa situacijom u kojoj se desi interapt, baš kao što Vojin navodi. Uvek idi na hardversko rešenje.
Reply
#8
Moze li detaljnije u cemu je problem ako postoji jitter na clk liniji i kako dovodi do prekida komunikacije kada se ne koristi neka periferija koja ima timeout tj minimalnu frekvenciju za clk?

 Voleo bih da naucim nesto...
Reply
#9
Za moj slucaj, ne koristim interrupt, ...bar ne za sad Smile
Reply
#10
Heh ajd kad sam vec krenuo sa pitanjima, evo nesto iz mog iskustva:

I2C komunikaciju sam koristio u bar 30-40 projekata do sada. Bilo je to svacega, ali zbirno uvek je najbolje koristiiti pomoc hardwera ako je moguce. HW TWI ili kako ga vec ko zove je  skoro pa OBAVEZAN ako pravis slave stranu u softweru.

     Medjutim cesto sam bio kao i ti u situaciji da se prosiruje mogucnost nekog davno izgradenog hw-ra koji ima (do) dva GPIO pina izvucena na AUX konektor za ne daj boze.  Onda cupas kako znas.
 Bit bang I2C najcesce radi bez problema jer su periferije neosetljive na tajming (u stvari po prirodi imaju max frekvenciju  - retko koja obradjuje min frekveniju, a ako obradjuju to im je vazan feature - vidi pomenuti SMBus..)

 U jednom projektu sam vozio I2C na ~100Hz.  U putanju je 24cxx eeprom ugradjen u US applikator, a polling sluzi da se otkije da li je applikator tu ili ne. Veca I2C frekvenicja je zbog loseg kabla i preslusavanja sa US generatora  pravila neopisive probleme u vidu false alarma . Ono kad pogledas SDA/SCL linije na skopu to su samo "dve zmijice" prepune suma koje se sporo njisu u ritmu i2ckomunikacije. Svasta bi se tu moglo prigovoriti HW-u i dizajneru, ali u tom trenutku je bilo vadjenje situacije kako god moze... I tu sam radio.. hm recimo oversamling/usrednjavanje SDA linije ono mnogo puta dok ne zakljucim sta je po sredi... Zbog toga je frekvencija sisla dole.
Jednom sam morao da koristim Melexov IR temeraturni senzor - on ima SMBus specifikaciju. Tu sam morao da gasim interrupte kada radim SW I2C komunikaciju.
Reply
#11
Evo primera gde softverski I2C puca. Imas mcu master i neki I2C slave. Master je poslao start bit i slave addr, a slave kada je primio ispravne podatke pokrenuo svoj communication time-out timer. Mcu krenuo da salje podatke i generisao se int gde je cpu potrosio vreme koje je duze od time-out-a. Slave je resetovao sebe i ceka ponovo iniciranje komunikacije. Mcu ne zna sta se desilo na magistrali i nastavi da salje podatke po izlasku iz int. Slave ne reaguje. Sta onda. Mnogo ovakvih situacija i nema komunikacije. Preporuka je da se kod soft i2c uvek iskljuce interapti.
Ako su potrebne vece duzine i brzine, onda se koriste drajveri ili i2c expanderi. Pravi ih NXP.
Reply
#12
Iskreno nikad mi se ovo nije desilo,verovatno zato sto interrupti po pravilu traju minimalno. Koja su kasnjenja potrebna za ovaj efekat msm red velicine posto se ne secam vrednosti iz datasheetova? Hvala
Reply
#13
Interapti moraju da traju sto je moguce krace. Tu si skroz u pravu. Red ovih kasnjenja ne znam. Ona zavise od proizvodjaca I2C periferije. Problem je izrazeniji kada imas firmware sa 5 i vise interapta gde stalno jedan drugog prekidaju. Ova situacija sa time-out-om ne mora da se javi. Moze sve lepo da radi, ali posle npr. mesec dana pojavi se ova situacija i nemas pojma zasto se to desilo. Biblioteke za softverski I2C koje prave proizvodjaci kompajlera su zakljucane i nemas pojma sta se tamo desava. Ja ne koristim Arduino i niti sam ga ikada koristio. Koristim iskljucivo sirovi C kompajler i razvijam svoje biblioteke.
Kada se projektuje nesto sa MCU, onda mora da se projektuje tako da se iskoriste hardverski resursi upotrebljenog MCU-a. Ako MCU ima hardverski implementiran npr. UART, SPI, I2C, tajmere itd., onda totalno glupo koristite softverske biblioteke sa pomenute funkcije. MCU tada totalno gubi smisao i kontrola izvrsavanja programa moze da postane nepredvidljiva. Izvrsava se stofverski I2C i u toku izvrsavanja I2C PC je poslao start bit preko UART-a. MCU ne moze da detektuje start bit, zato sto je MCU bio zakucan u rutini za izvrsavanje I2C-a. Ima milion ovakvih situacija.
Moj prijateljski savet je da se potrosi malo vise vremena kako bi se naucilo prvilno iskoriscenje resursa MCU-a i koriscenje interapta. Oni su ti koji nam daju paralelizam u radu. Sve ostalo nema nikakvog smisla.

Pozdrav
Reply
#14
Jos jedno pitanje, da li na ovaj softverski I2C moze da utice i softverski UART? Tj. da li SoftwareSerial i SoftI2CMaster mogu da rade zajedno bez ometanja?
Reply
#15
Svaki softverski komunikacioni prokotoli mogu da rade nemetajuci jedan drugog. Problem moze da nastane, ako si ti pokrenuo softverski I2C i dok radi I2C, PC ti posalje start bit. Ti neces da registrujes taj start bit, jer ti je MCU zaglavljen u petlji za softverski I2C. Dolazice ti cesto do propusta komunikacije. To se sve lepo resava upotrebom interapta i koriscenjem hardverskih komunikacionih modula.
Reply
#16
Upravo tako kao sto Vojin kaze, HW moduli za te komunikacije rade sve potrebne stvari nezavisno od glavnog procesora, oni cekaju te start/stop bitove i pune interne buffere kada se zavrsi prenos jednog bajta i onda setuju neki flag da daju informaciju glavnom programu da je stigo podatak u buffer i program samo to treba da iscita "kad stigne", ne bavi se sam program seriskim protokolom.

Zato je HW varijanta drasticno pouzdanija i nema nikakvih smetnji ako se koriste interapti u programu.
Reply
#17
Ok, hvala drugari. Nista, znaci preuredjivanje pcb-a ne gine kako bi prevazisli potencijalne nove probleme mozda sa v3 Smile
Reply
#18
Najbolje bi bilo da kazes sta ti tacno treba da se projektuje, pa da zajedno uradimo.
Reply
#19
Kasno se uključujem, evo i mog iskustva... Koristim više godina SHT11, SHT21 senzore (I2C) i komuniciram softverskim (polling) I2C rutinama sa njima.
Na jednom od uređaja imam 4 kanala za ove senzore, koristim interapte, GSM modul, LCD modul, tastatura, LAN komunikacija itd... sve ovo radi odlično. Još jedno odstupanje od "propisa" je da su mi senzori na kablovima i po 20-30m što nije baš tipično za I2C komunikaciju, ali ukoliko je dovoljno spora (oko 10-20kHz CLK) a perifrerija (u mom slučaju senzor) to dozvoljava, onda je izvodljivo Smile

Ukoliko se dobro koncepira kod, nije problem da se realizuje dosta toga u softveru. Ko je radio sa PIC16F84, PIC12F508 ili sa još starijim mikrokontrolerima kao što je AT89C2051 zna o čemu pričam.

Kolege su već savetovale, interapt rutine MORAJU biti optimizovane da rade samo neophodne stvari. Kompleksne matematike i slično zaboraviti u interaptu, ako se želi protočni i optimalan kod. Ovde dolazimo do još jedne potrebe, biblioteke/rutine poželjno je da pišemo sami jer jedino na taj način imamo odličan uvid u kod i po potrebi da ga optimizujemo.

U svakom slučaju savetujem da se koriste HW periferije, ali i od njih ne treba očekivati kompletno otklanjanje problema, jer kod slabijih mikrokontrolera postoje hardverski bufferi ali svega 1By tako da opet dolazimo do potrebe da se kod piše optimalno i protočno...

P.S. Ja sam imao jedan obrnut problem, kada sam sa softverskih rutina prešao na HW periferiju za I2C, javio mi se čudan problem sa spajkovima na linijama, ali o tome nekom drugom prilikom...
Reply
#20
Da prenesem i moje skorasnje iskustvo sa I2C, skoro radio sa nekom RPi postavkom i par I2C periferija na 400kHz BUS-u.

Kao sto @yugaja spomenu, na linija mi se pojavile "zmijice" tj onako fin overshot koje moram priznati da nisu u tom trenutku pravile probleme u kominikaciji, ali sam zbor robustnosti ipak odlucio da to namestim kako treba jer je sprava bila predvidjena za industriske surove uslove.
Tu je potrebno da se stavi JEDAN OTPORNIK REDNO sa komunikacionom linijom reda 100-330R, konkretna vrednost otpornika valjda da se experimentalno nadje kada se prati osciloskopom drugi kraj linije (naravno sa "federom" na vrhu sonde, ne preko GND stipaljke) i to poprilicno lepo smiri signal, malkice se uspori tranzisicja signala ali zato overshot kompletno nestane!

Posle to isto primenio i na 5MHz SPI i RS232 115kbaud, takodje dobio perfektne signale na linijama.

Zakljucak, kada se projektuje neki MCU sklop, valja prakticno staviti na sve njegove nozice (osim za napajanje i oscilator) po jedan SMD otpornik, nece to da skodi nikako, uvek tu moze da se stavi 0R kratkospojnik ali ako zatreba to moze silne probleme da resi i da poveca imunost na spoljasnje smetnje.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)