Tracer2
Assembler rules!
Iemand ervaring met I²C??? Ik wil via mijn µController een equalizer IC (TEA6360) aansturen met I²C...(daar ik geen andere keuze heb).
Als ik volgens het protocol de adressen en subadressen doorstuur, kan ik de klokfrequentie (SCL) dan vrij kiezen, zolang ik maar niet boven het maximum zit???
Het programma om in te klokken moet ik nog schrijven en dat zal in assembler zijn...
Moet ik rekening houden met de acknowledge van de slave??
je HOEFt geen rekening te houden met de acknoledge, maar als je dat wel doet, weet je wel vrij zeker dat het goed gaat.
Ik ben zelf nu ook aan het hobbyen met I2C (TWI) zie mijn topic op deze site ergens
Maare, ik heb problemen met de snlehied, mijn prescaler moet op2 staan, anders kan mijn master (ATMega 16) GEEN goede bits ontvagen. heb ff de scope erop gezet en blijkt da thet signaal maar 500HZ is, als ik over 1 kHz ga gaat het fout, hij stuurt een ander bitwaarde terug, maar de pulsen zijn op zich wel mooi
Tracer2
Assembler rules!
Ik denk dat ik er toch maar beter rekening mee hou...
Dus ik mag mijn I²C communicatie op bv 1Khz doen?
Henk, uw snelheidsprobleem.... Zijn uw SCL en SCA lijnen voorzien van pullup-weerstanden?
3,4 K zoals voorgeschreven in specs in datasheet van 24c08
de pulsen zien er ook prima uit. trouwens de pull ups in de avr staan ook aan.
Ik snap alleen die snelheidsproblemen niet. Er komt gewoon een hele andere byte uit de EEPROM. Het moet toch wel VEEL sneller kunnen?
Op 4 maart 2004 11:06:57 schreef High met henk:Maare, ik heb problemen met de snlehied, mijn prescaler moet op2 staan, anders kan mijn master (ATMega 16) GEEN goede bits ontvagen. heb ff de scope erop gezet en blijkt da thet signaal maar 500HZ is, als ik over 1 kHz ga gaat het fout, hij stuurt een ander bitwaarde terug, maar de pulsen zijn op zich wel mooi
Welk type Eeprom gebruik je? Ik had ook al gemerkt dat veel I²C dingen nogal traag zijn.
Ik loop ook met I2C plannen rond. Ik wil een inetrface bouwen en software schrijven om met de computer een bastaand I2C netwerk te ontrafelen. En fouten te zoeken.
Of bestaat zoiets al en wil het warm water opnieuw uitvinden.
ik heb hier gistern een deel van het probleem ontrafeld, als ik goed in de datasheet ahd gekeken, had ik het maybe sneller geweten, maar 1 e eeprom ervaring, dus 3 x overheen gelezen. Een EEPROm duurt ff nadat hij zijn ACK geeft, voordat de waarde daawerkelijk op de juiste plaats staat. Als je dus meteen leest, krijg je idd een vage waarde terug, als je ff wacht gaat het weer wel goed.
I2C is best grappig, maar je moet altijd adresseren, dus als evarist een debugger wil bouwen voor I2C, moet hij wel een virj dress gebruiken. Bovendien is het uitlezen van I2C het beste te doen met een goede scope. Met een uC kan ook, maar dan moet je dus het start bit, adress byte, ACk bit, data byte(s) ACKbit(s) en stop bit uit kunnen lezen
evt ook nog een restart bit
Kan natuurlijk wel, maar den snelheid op I2C is een variabele factor, wat het niet echt makkelijk maakt