das kommt darauf an... wo steckst du denn fest?
der i2c-bus wurde schon mehrfach erfolgreich auf dem asuro implementiert.
8 mhz ist der systemtakt, kein counter.
.. es dauert zwar länger aber irgendwann findet man was man sucht
https://www.roboternetz.de/wissen/in...nter_%28Avr%29
ich werde den I2C bus einfach mal verwenden und wenn probleme auftauchen.. naja irgendwie wirds schon gehen
bleibt nurnoch die syntaxfrage ...
hat jemand vl einen link der mir vl weiterhilft ?
das kommt darauf an... wo steckst du denn fest?
der i2c-bus wurde schon mehrfach erfolgreich auf dem asuro implementiert.
8 mhz ist der systemtakt, kein counter.
wie schnell ist der I2C bus ?
-> welche frequenz hat er ?
bzw. würde mir schon reichen ..ist der I2C bus schnell genug um in einem timer ohne größere bedenken eine i2c_read zu verwenden?
d.h. ohne prescaler (und ohne vorladen) würde z.b. timer 0 Overflow
mit 8MHz/256 ausgelöst werden ?
sollte ich vor jeder I2C bus kommunikation die interrupts aus und danach wieder einschalten ?
der i2c-bus hat maximal 100 kHz.
8MHz/265=31,25kHz. aber: wahrscheinlich liegt die clock/taktleitung auf maximal 100kHz, dann werden einzelne bits mit dieser geschwindigkeit übertragen. dann sind es 31,25*8(bits pro byte) plus startbedingung und stopbedingung... dann wirds doch zu knapp. müsstest du wohl doch entweder einzeln abfragen. oder du nutzt die i2cmaster lib von peter fleury, wie die meisten hier im forum. die ist
1. schon fertig
2. in assembler, und braucht wenig speicher im flash
3. gut anpassbar
4. alle verzögerungen für den störungsfreien betrieb (inkl. clock stretching und begrenzung auf 100kHz) sind implementiert.
genauere infos zum i2c-bus sind hier:
http://www.robot-electronics.co.uk/h...he_i2c_bus.htm
und such mal im forum nach i2c, da findest du einiges.
ich lasse die interrupts meist an, wobei es an sich nicht schaden könnte die abzuschalten. der interrupt für die sleep-funktion wird 36000mal pro sekunde ausgelöst, und stört die kommunikation trotzdem nicht.
denk dran: ohne interrupts keine sleep/msleep/SerWrite/SerRead/... also immer ans einschalten denken!!
probiers mit eingeschaltet lassen, wenns nicht geht dann mach sie aus.
Hi bloodyDragon,
ich würde für dein Problem (Go und Turn Funktion benutzen und zusätzlich I2C Abfragen) anders vorgehen. Die I2C Abfrage nicht timergesteuert starten , sondern eher die Go und Turn Funktion umschreiben (bzw. neuschreiben) in ein Verhalten.
Das ganze wäre eine von Art Quasi Multitasking. In der Hauptschleife werden nacheinander folgende Funktionen aufgerufen.
Das ganze setzt voraus, dass alle aufgerufenen Funktionen auch in endlicher Zeit fertig werden. Längere Msleep Aufrufe in Funktionen sind deshalb pfui. Wenn eine Funktion in der vorgegeben Zeit nicht fertig wird, muß daraus ein Verhalten programmiert werden.Code:Init(); InitI2C(); InitBehaviour(); // Verhalten initialisieren while(1) { ReadSensors(); // einlesen der Sensoren und I2C RunBehaviour(); // Verhalten ausfuehren SetActors(); // Aktoren setzen SendState(); // evtl. Status an PC senden }
Ein Verhalten ist auch eine Funktion, die aber:
* mehrmals aufgerufen wird,
* ein wenig Verarbeitung macht,
* sich den Verarbeitungsstand merkt,
* und dann mit einer Statusmeldung zurückkehrt .
Programmtechnisch löst man so etwas mit State Machines.
In einer Verhaltensfunktion werden keine Sensoren direkt abgefragt und auch die Aktoren (Motoren) werden nicht direkt gesteuert. Alles geht nur über globale Variablen.
Die ReadSensors Funktion liest die Sensoren und speichert die Werte in den Sensor Variablen.
Die RunBehaviour Funktion verarbeitet die Sensor Variablen ruft die gewünschten Verhaltensfunktionen auf (Go, Turn, FollowLine etc.) und erzeugt die Aktor Variablen.
Die SetActors schließlich nimmt die Aktor Variablen und steuert die Motoren.
Wird diese Hauptschleife in 10-40ms durchlaufen, kann man von Quasi Echtzeit sprechen. Für einen kleinen Roboter ist das aber schnell genug, um auf Ereignisse zu reagieren.
Klingt nach viel Arbeit
ok klingt gut
dann werde ich versuchen dieses prinzip umzusetzen ^^
leider hänge ich momentan bei einer viel einfacheren frage...
ich habe das forum durchsucht aber scheinbar bin ich der einzige der die libary von p.fluery nicht richtig implementieren kann
ich habe die Assembler datei eingebunden
die i2cmaster.h includiert
die ports eingestellt
aber wenn ich meine I2C pins mit einem oszilloskop messe dann sieht keiner der beiden pins wie eine SCL aus !??!
ich weis nicht was
an application can be linked either against the software I2C implementation or the hardware I2C implementation.
and
Eventually adapt the delay routine in the module i2cmaster.S to your target when using the software I2C implementation !
bedeutet ... vl liegts daran ?
Hi,
Hast du die PullUp Widerstände am I2C Bus angeschlossen?
Ansonsten kannst du ja mal das Beispielprojekt aus dem AsuroWiki für die I2CPorterweiterung ausprobieren. Dort wird ADC2 als SCL und ADC3 als SDA verwendet.
http://www.asurowiki.de/pmwiki/uploa.../i2cmaster.zip
Das Funktioniert bei mir und allen anderen, die die LCD Erweiterung darüber betreiben, ganz gut. In der I2C Lib mußten lediglich die Ports angepaßt werden.
genau. du brauchst die pullup widerstände.
ausserdem ist auf der scl nicht immer ein taktsignal, sondern nur, wenn auch daten übertragen werden. du kannst zB das beispielprogramm aus der zip-datei von asurowiki.de mal flashen, dann solltest du einen takt beobachten können.
Ok also der I2C funzt jetzt entlich ^^
bei mir sind die SDA und SCL pins genau umgekehrt wie bei der i2c.S
naja .. hat mich etwas nerven gekostet aber ich habs gefunden ^^
jetzt hab ich leider gleich ein anderes problem...
ich möchte ja int0 verwenden um einen tastendruck zu erkennen
und habe mir dazu ein ganz einfaches programm geschrieben..
das problem..
irgendwie wird der interrupt ständig und über 1000 mal ausgelößt
( hab eine variable die hochzählt und dann FrontLED auf ON setzt eingebaut )
( eine statische )
oder funzt das nur mit volatile ?
naja das seltsamste daran ..
obwohl ich die front led nur auf on schalte leuchtet sie nicht mit voller Leuchtkraft ???
volatile bedeutet nur, dass sich der Wert unvorhergesehen, z.b. per Interrupt, ändern kann.
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
Lesezeichen