ZitierenAlso ich sehe da kein Problem da du mit den 100 Takten pro Befehl mehr als pessimistisch bist. Schau dir mal Assembler an, dort braucht ein Befehl 1 bis 3 Takte und um so viel aufgeblasener ist Bascom auch nicht.
Hallo,
ich würde gerne mit Hilfe eines Atmega16 ein elektronisches Nockenschaltwerk basteln. In etwa stelle ich mir das so vor: Vom Inkrementalgeber kommen sekündlich maximal je 350 A und B Impulse rein. Das Programm soll die Impulse einmal über einen Pin ungefiltert weiterreichen (nicht unbedingt erforderlich, aber wünschenswert), die Impulsauflösung auf verschiedene Weise herunterrechnen, so das an einem Pin z.B. sekündlich nur 50 Impulse anliegen und an, sagen wir 8 weiteren Pins vorprogrammierte Nocken (also Impulsbereiche) ausgeben.
Das ganze soll unter Bascom geschehen und ich habe mir mal grob durchgerechnet: bei 8mHz Takt, wenn jeder BASIC-Befehl im Schnitt 100 Takte verbraucht wären ja immer noch 8000 Befehle in Bascom sekündlich drin, was für das Schaltwerk und den Speicherplatz im Chip wohl mehr als genug wären.
Irgendwie klingt die Rechnung aber für mich schon zu gut um war zu sein, was würdet Ihr schätzen - komme ich mit einem 8mHz Atmega16 für diesen Einsatzbereich hin?
p.S.: Ach ja, dummer Denkfehler - ich muss die 8000 ja noch durch die Impulszahl teilen - wusste das es da einen Haken gibt... Aber vielleicht hat ja doch jemand eine Idee, ob und wie das mit dem Atmega realisierbar ist.
Viele Grüße:
Badamtam
Also ich sehe da kein Problem da du mit den 100 Takten pro Befehl mehr als pessimistisch bist. Schau dir mal Assembler an, dort braucht ein Befehl 1 bis 3 Takte und um so viel aufgeblasener ist Bascom auch nicht.
Da hast Du sicher recht. Ich geh bei solchen Kalkulationen sicherheitshalber lieber vom worst case aus. Ausserdem gibt es ja wahrscheinlich viele Bascom-Befehle, die in Assembler viele Zeilen schlucken würden. Zur Zeit habe ich noch keinen blassen Schimmer, wie ich das letztendlich hard- und softwaremäßig abwickle - ich weiß - ist im Prinzip kein großer Akt, aber einige grundsätzliche Fragen sind für mich noch nicht geklärt. Die Ausgabe von Nocken über Pins z.B. finde ich nicht optimal, da halt Ein/Ausgänge knapp sind. Die Codierung der Nocken in Datenwörter die über einen Bus kommuniziert werden, würde mir besser gefallen, da fehlts mir aber wieder an allen Ecken und Enden an Hardware und vor allem noch an Know How. Das wird sich wohl mit der Zeit entwickeln.
Zitat von Hubert.G
Du hast beim Mega16 doch 32 Ports zur Verfügung. Wenn du nur 2 für Input brauchst dann sind das 30 für Output. Wenn du dann alle mit unterschiedlichen Teiler vom INput taktest musst du das schon gut überlegen aber grundsätzliche Probleme sehe ich keine.
Hubert
Das Problem sind leider nicht die Aus- sondern die Eingänge auf der Gegenseite. Auf der Gegenseite habe ich eine SPS mit eingebautem CAN-Bus Interface, der sich meiner Meinung nach am besten zur Weitergabe von Nockendaten eignen würde.
Wenn ich die Nocken in einem 16Bit-Wort kodiere, (8Bit würden ja auch schon für 255 Nocken reichen) hält sich die Buslast, die dabei ensteht ja in Grenzen. Nur habe ich halt noch keine Erfahrung mit CAN-Controllern am Atmega - hier im Forum steht ja das Eine oder Andere darüber, werd mich da mal durchwühlen.
Wenns garnicht klappt, könnte ich 255 Nocken auch auf 8 Pins Kodieren, oder 63 auf 6, aber wie gesagt - übern Bus wärs einfach eleganter.
Ach ja - was den Teiler für den Input betrifft, brauche ich wohl nur einen, der Rest sind Inkrementbreiche, (also die eigentlichen Nocken) die ausgegeben werden sollen. Ich will also die Inkremente 8-16 als Nocken 1 definieren und das dann z.B. als Dezimal 1 in ein Byte kodieren und ausgeben - die 1 liegt dann ab Inkrement 8 solange an, bis Inkrement 17 erreicht ist.
Viele Grüße:
Osaris
Berechtigungen
Lesezeichen