fischertechnik community forum

Hallo...
Also ich steuere mit RoboPro einen Arduino Uno an (Mein Arduino TX-Light Projekt).
Das läuft auch ganz gut bis auf eine Sache:
Schnelles Zählen von Impulsen
Ich würde mal sagen 90% der ft Modelle laufen, aber mein Ziel ist es den alten Trainingsroboter mit den schwarzen Lichtschranken
am Arduino zum Laufen zu bringen. Die Anzahl der Striche pro Umdrehung ist viel zu groß.
Meine momentane Lösung ist es über ein Zähler IC den Zählerstand parallel auszulesen und über ein parallel-seriel IC das einzulesen.
Ich verliere damit keine Impule aber ein "intelegentes" Anfahren auf bestimmte Werte oder auf 0 ist so nicht möglich (oder nur sehr sehr sehr langsam).
Auch muss das Ganze ja 3 mal aufbebaut werden. Das ist jetzt nicht dass, was ich mir vorgestellt habe.

Jetzt ist die Frage ob man einen weiteren AVR nimmt z.B. einen Mega (Arduino Mega) mit drei Zähleingängen und den die Motoren steuern läßt.
Momentan ist es so das die Motorplatine (Adafruit Motor Shlied 2.0) über I2C angesteuert wird.

Muß nun der Mega als Slave sagen wir mal ein Stop Befehl erst an den Master (Uno) übergeben oder kann der Slave zum Slave daten senden?
Oder muss der Master (Uno) erst den I2C Bus freigeben und der Slave (Mega) auf Master umschalten und dann später wieder auf Slave?

Den Mega nur als Master zu nutzen geht so leider auch nicht. Die Kommunikation über USB alle 20 Millisekunden und die Verarbeitung führt zu einem "Verschlucken" von Impulsen, also man überfährt den Stoppunkt weil der Motortreiber in dieser Zeit nicht abgeschaltet werden kann.

Oder gibt es noch andere Ideen?
Gruß
fishfreind
Holger Howey

Hallo Holger,

fishfriend hat geschrieben: Ich würde mal sagen 90% der ft Modelle laufen, aber mein Ziel ist es den alten Trainingsroboter mit den schwarzen Lichtschranken
am Arduino zum Laufen zu bringen. Die Anzahl der Striche pro Umdrehung ist viel zu groß.

Wieviele Striche/Impulse pro Umdrehung sind das denn? Mehr als die Encodermotoren an Pulsen liefern?

Falls nein: Schau für Anregungen mal, wie MoG die Zähleingänge beim ftduino umgesetzt hat. Das ist auch ein AtMega32, und die Zähler kommen mit den Encodermotoren gut klar.

Hallo...
Sage und schreibe 32 Balken pro Umdrehung, das mal drei Achsen und nur ein Uno.

Mein Ansatz ist ein anderer. Ich lasse den Arduino Uno als TX in RoboPro laufen.
Beim ftduino wird einfach über die IDE und die Taktfrequenz die Abfrage der Counter gemacht.

Der Mega32 hat drei Counter-Eingänge die unabhängig vom der CPU arbeiten.
Die werden, so wie ich das sehe, nicht vom ftduino genutzt, obwohl zwei am dem richtigen Pin hängen.
Wenn man es selber programmiert würde es halt mit 2 von 3 gehen.

Da nun bei meinem Uno der Austausch der Variablen alle 20ms stattfindet (+Verarbeitung) kann in dieser Zeit nicht gezählt werden.
Das ganze Konzept baut auf einem Uno auf, weil die in der(den) Schule(n) vorhanden sind.
Ich muss mal schaun ob ich für diese eine Modell eine Ausnahme mache und nur dafür auf einen Mega umstelle.
Es soll halt fast nichts Kosten und nachbausicher sein. Momentan bin ich für ein fischertechnik Interface bei ca 25€ für alles zusammen mit Uno (Nachbau).
OK da ist nun kein Display dabei aber es ging vorrangig darum die alten ft Computing zum leben zu erwecken.
Mal schaun...
Gruß
fishfriend
Holger Howey

Hallo,

fishfriend hat geschrieben: Sage und schreibe 32 Balken pro Umdrehung, das mal drei Achsen und nur ein Uno.

Das sollte eigentlich funktionieren - die Encoder liefern etwa die doppelte Impulsrate, und da klappt das ja auch noch.

fishfriend hat geschrieben: Mein Ansatz ist ein anderer. Ich lasse den Arduino Uno als TX in RoboPro laufen.

D.h. du hast da einen Sketch drauf der das TX-Protokoll emuliert?

fishfriend hat geschrieben: Beim ftduino wird einfach über die IDE und die Taktfrequenz die Abfrage der Counter gemacht.

Jein. Der ftduino benutzt Interrupts, um das "nebenher" (unabhängig vom laufenden Hauptprogramm) zu machen: Der Atmega32 kann einen Interrupt triggern wenn sich der Status eines Pins ändert, und in der Service-Routine für diesen Interrupt wird dann gezählt. Das Hauptprogramm liest dann einfach den fertigen Zählerstand aus.

Details siehe https://github.com/harbaum/ftduino/blob ... tduino.cpp, such nach "counter_check_pending" und "ext_interrupt_exec" um die interessanten Stellen zu finden.

fishfriend hat geschrieben: Da nun bei meinem Uno der Austausch der Variablen alle 20ms stattfindet (+Verarbeitung) kann in dieser Zeit nicht gezählt werden.

Mit Interrupts sollte das eigentlich hinkommen. Oder ist das TX-Protokoll so zeitkritisch dass du während des Datenaustauschs die IRQs abschalten musst? Kann ich mir aber ehrlich gesagt nicht vorstellen...

Hallo...
Hab es schon mal probiert. Der Uno stößt an seine Grenzen. Leider leider ist das Programm noch nicht ganz fehlerfrei. Ok, also es läuft alles bis auf die Counter und ich hab da noch zwei Baustellen mit dem Tranferbereich. Der Speicher ist fast voll, aber es geht.

Ja, der Sketch auf dem Uno emuliert einen TX und steuert über I2C die Motor Treiber.

Das schöne ist auch das ich über einen HC05 eine Bluetooth-Verbindung habe und Kruzschlüsse nicht in den USB oder PC grillen.
Ich kann nur vermuten das es für den Uno zu Zeitkritisch ist, da RoboPro die Verbindung wegen Zeitüberschreitung beendet.

Ich werd mir mal die Stellen beim ftduino nochmal genauer anschauen.

Alles in allem müßte ich das ganze Konzept ändern um einen (3) IRQ zu nutzen, würde aber gehen..., mal schaun...

Der Gag ist ja das man die Counter auch für ganz andere Dinge gebrauchen: z.B. Datenübertragung in beide Richtungen PC-Uno und in RoboPro auswerten kann.
Ich lasse mir z.B. Werte von Variablen anzeigen um Fehler zu finden. Es gehen aber auch Sensordaten.
Mal schaun ob ich noch mehr Uno Modelle zur Modellschau in Münster dazu zeigen kann.
Gruß
fishfriend
Holger Howey