HI, ich hab mich langsam mit den ATMega mikrocontrollern angefreundet. nun zeichnet sich ab das ich den kleinen statt als intelligente durchreiche bzw schnittstellenbaugruppe nutzen werde sondern komplexere algorithmen in dem 'kleinen' abarbeiten werde bzw möchte. ich hab bisher mit bascom programmiert. aber meine 40 zeilen quellcode hauen schon 10 prozent von den 16kb des atmega 16 voll. ich glaub nicht dass ich mit basic und nem atmega 128 klar kommen werde. leider kann ich das nicht genau sagen. (bei bedarf kann ich ein paar knackpunkte nennen.) gibt es atmega compatible chips? mit mehr flash und mehr sram? und gleich noch ne frage hat sich jemand von euch schon mit SSI signalen beschäftigt? ich müsste ein solches synchronm serielles interface nachbilden allerdings befürchte ich das das ein atmega nicht shcaffen wird. kennt jemand von euch evtl. ne baugruppe oder nen kleinen dsp mit dem ich sowas recht einfach realisieren könnte? sozusagen als langer arm vom atmega ;) gruß Steffen
Also nur so als Tip, wenn du ernsthaft was programmieren willst, dann trete Basic in die Tonne und beschäftige dich mit C oder Assembler. Du wirst dich wundern, was man mit 16kB alles machen kann. Wenn du mehr RAM brauchst, so bietet ja der ATmega128 ein Businterface an dem du ohne zusätzlichen Aufwand 64kB dran hängen kannst. Übrigens ist es garnicht so schwer, in Assembler oder C reinzukommen. Thorsten
hi, ich muss mich doch wundern, warum soll eine hochsprache zugunsten einer anderen in die tonne getreten werden? ist denn c der bmw und basic der trabbi? und wenn ja, was kannst du mit c machen was mit bascom nicht geht??? früher sprach man mal von dialekten, das trifft den kern der sache doch sehr, der eine spricht so, der andere so aber die message bleibt. oder stammen diese vorurteile aus zeiten in denen basic nur als interpretersprache (wie java etc.) zu bekommen und deshalb grottenlahm war, weil ja jeder befehl erst zum aufrufzeitpunkt kompiliert wurde? bascom ist eine enorm leistungsfähige programmiersprache, übersichlich, komfortabel und man kann, wenn's denn nötig ist, assemblercode implementieren. ob ein programmierer mit ein paar zeilen das flash zuhaut oder nicht liegt an ihm selbst. ich hab in 'nem mega16 eine steuerung laufen, die an 900 zeilen quell-code hat, 96% des flash sind damit zu, passt also. sparsam programmieren ist keine frage der sprache sondern des stil's. wen's interessiert, fast-avr, auch ein basic dialekt, gibt zu jedem geschriebenen befehl den zugehörigen maschinencode mit aus, ein vergleich assembler - fast-avr lässt so manchen alten hasen noch staunen, was in einer sprache steckt, die nach ansicht einiger unwissenden in die tonne gehört. fröhliches proggen noch, gruss, harry p.s. die sprache ist letztenendes nur eine frage des komforts, zitat: ein mega schafft etwas nicht; wenn du alles aus dem mega rausholst was drinnesteckt hast du richtig was geschafft! wenn ein prozessor nicht perfekt läuft liegt es selten an der hardware...
Ja du hast recht, an der Geschichte mit dem Vorurteil ist was dran. Ich kenne BASIC noch aus der Zeit der Homecomputer, und es war wirklich grottenlahm. Seit dem habe ich auch nie wieder was mit BASIC zu tun gehabt und ich wollte es auch nicht. Es ist nur so, daß ich auch durch dieses Forum hier den Eindruck habe, daß man mit Bascom nicht so effektiv programmieren kann wie mit C. Außerdem habe ich in der Industrie noch nie gesehen, daß Software für Mikrocontroller in Basic geschrieben wird. Deshalb sehe ich eigentlich auch keinen Grund, mich damit näher zu beschäftigen. Aber es stimmt schon, der eine spricht so der andere so. Jedem des seine und letztendlich zählt nur, daß ein Problem gelöst wird. Thorsten
Ich weiß ja nicht ob ein Compiler so gut ist, wenn er 2kB Code erzeugt und dasselbe macht was ich in Assembler mit <500Bytes schreibe. Es mag zwar sein, dass ein Vergleich der einzelnen Zeilen Code mit dem erzeugten Assemblercode recht effektiv aussieht, aber dazu kommen noch die ganzen Funkttionen wie printf, Fließkommazahlen, malloc usw. die oftmals mehr Speicher benötigen als das eigentliche Programm. Und Bascom ist halt nunmal nicht das beste (sowohl von der Codegröße und von der Geschwindigkeit). Ich finde manche Compiler schon lustig: Wenn ein einfaches Hello World Programm in C auf dem PC eine 300kB große EXE Datei erzeugt, dann ist der Compiler echt scheiße ! Dasselbe schaffe ich ein Assembler nämlich um den Faktor >1000 kleiner !
Ich kann nur von Computerprogrammierung sprechen, was Basic betrifft. Mit Bascom habe ich mich noch nicht beschäftigt. Mein größtes Manko an Basic ist, dass man hier meines Wissens nicht mit Pointern (Zeigern) arbeiten kann. Die Konstruktion von Klassen ist ebenfalls nicht so möglich, wie in C++. Daher bin ich bei der Computerprogrammierung vor einigen Jahren von Visual Basic auf C++ umgestiegen. Ich denke, dass Bascom auch Probleme mit Pointern haben wird. Viele Grüße Flite
Hi BASCOM hat schon Probleme mit x = a + b + c. Wie soll es da noch mit Pointern klarkommen. Matthias
Hi @All, ich finde Bascom ansich nicht schlecht, - es ist immer die Frage was man machen will!!! Wenn ich ein LCD, eine Tastatur usw. an den AVR packe und dann Lampe ein und aus progge, dann ist Bascom genau richtig oder wenn ich eine PID oder sowas mache, dann ist Bascom auch genau richtig!! Für einfache Datenbank anbindung am PC ist VB auch echt nicht schlecht!! Wenn es jetzt aber um den uC direkt geht, dann ist ASM und C schon der schnellere weg!! - Und die Codegröße eines Programmes hat nichts mit der Speed zu tun!!! Liebe Grüße Tassilo
> BASCOM hat schon Probleme mit x = a + b + c.
Inwiefern?
Hi ich hab mir hier im Forum sagen lassen BASCOM kann solche Ausdrücke nicht auswerten. Immer nur eine Operation pro Quelltextzeile. Also statt x = a + b + c x = a + b x = x + c Matthias
weil bascom nur eine rechenoperation pro auf einmal kann müsstest für a=b+c+d schreiben a=b+c a=a+d aber das ist gewohnheitssache. in assembler kann man sowas auch nicht. tja wenn ich denn wüsste das ich mit 128kb vom atmega128 reichen würd...tja.. dann wär mein problem ja geklärt. das ganze soll n simulationswerkzeug werden. 1. das scahlten von 3 separaten kontaktpaaren nach dem jeweils ersten kontakt muss per timer auf 0,1 ms genau der 2. ausgelöst werden. also z.b. 30,9 ms die kontakauslösungen sind abhängig von wegstrecken. 2.ich muss eine rechteckfrequenz erzeugen. ich dachte da an pwm bereich 0-1000 hz. 3.ich muss ein ssi mit 125 khz bereitstellen. das in 31 bits ne absolute wegposition verpackt. datenübertragung ist gebunden an die steigende flanke des 125 khz taktsignals. 4.ich muss eingänge auslesen. anhand dieser eingänge verändere ich kontinuierlich die absolute wegposition und muss diese in 3. ausgeben 5. ist die eine bestimmte position erreicht muss ich ne kraft mit hilfe der wegposition (tabelle/array) bestimmen und damit über eine formel ne geschwindigkeitsänderung in 2. ausgeben. 6.nebenher müssen die in 1. aufgeführten kontakte ausgelöst werden. und es ist eine serielle kommunitation erforderlich mit einem parameterpc der startwerte an den controller übergibt und es währe wünschenswert den microkontroller in eine bus struktur einzubinden. so dass ich vom parameterpc aus mehrere simulations-mikrocontroller betreuen kann. als bus hatte ich was serielles im auge. vielleicht mit nem simplen ascii protokoll. Modbus zum beispiel. einige sachen können bis nächste woche noch herausfallen. ne kommunikation ginge aauch über externe controller. wenn ihr z-b- ne möglichkeit kennt. kann der max232 serielle busprotokolle?
Bevor der Thread zu weit in Richtung Pc-Programmierung abgleitet ein Beispiel aus meiner uP Praxis: Bei meinem letzten Projekt (Lesegerät für Video-Daten, VPS, WSS und Datenzeile) habe ich für die ersten Tests (die rudimentären Lesefunktionen mit Ausgabe über RS232) einen 2313 in Assembler programmiert (ist bei Signalen mit ca. 250us Bitlänge auch nicht anders möglich). Das fertige Gerät sollte aber noch LCD, Tasten, ein paar LED, OC-Ausgänge für externe Signalisierung und RS232 verwalten. Als uP wählte ich den Mega8 und die "Verwaltung" wollte ich mit BASCOM erstellen. Nach ca. 60% der Funktionen waren 95% Flash voll und ich hatte ein Problem weil die Printplatten schon für den Mega8 fertig waren. Ich habe dann auf c (Codevision) umgesattelt und stehe derzeit bei 95% Funktionen und 60% Flashverbrauch. Ich gebe aber zu dass ich unter c eigene LCD- und RS232-Routinen verwende. Dennoch unterstelle ich BASCOM eine nicht ganz so effiziente Compilierung. Generell gibt es vermutlich keine schlechte Sprache, manche sind halt etwas effizienter, bzw. durch den Programmierer leichter zu adaptieren. Zehn Zeilen assembler liefern 10 Byte Code, wissen aber nichts mit LCD und Fließkoma anzufangen. Zehn Zeilen BASCOM erzeugen zwar 2kByte, initialisieren aber gleich ein LCD und können auch "dividieren". Die Wahrheit liegt vermutlich irgenwo in der Mitte, also vielleicht doch c ;-) grüsse leo9
hi, ich nochmal, wenn c denn um einiges effizienteren maschinencode erzeugt als bascom das macht spricht einiges dafür, weil ja flash im avr eh nicht unendlich bereitsteht. ich tät schon gerne wieder in c einsteigen, hab vor urzeiten auf'm pc alles in c geschrieben und fand das recht einfach, wenn auch am anfang ein wenig gewöhnungsbedürftig. später hab ich dann versucht mit symantec's c++ fürN mac was zu schreiben, da hat mich das kalte gruseln gepackt, man musste erstmal ein projekt anlegen und weissichwasalles, bevor man 'hello world' ausgeben konnte. das war dann mein abschied von c. gibt's für die avr's einen simplen compiler, der den komfort einer kompletten entwicklungsumgebung bietet und mit dem mit wenigen zeilen das 'hello world' beispiel realisiert werden kann? danke, harry
Naja die Sache mit dem Projekt anlegen usw. ist was, daß guckt an sich einmal an und dann is gut. Bisschen flexibel muß man schon sein :)
Hi C++ hat mit C etwa soviel zu tun wie Java mit C. Es ist eine andere Sprache. Man kann zwar mit einem C++ fast jeden C Quellcode übersetzen aber dann ist das immer noch C und nicht C++. @BomberD Ich würde deinen Text wirklich gerne lesen aber nach zwei drei Zeilen verliert sich dank dem fehlen (fast) jeglicher Großbuchstaben bei mir der Lesefluß. Matthias
@matthias sorry aber ich schreibe im Forum und in E-Mails eigendlich grundsätzlich nicht mit Großbuchstaben. Bisher hat das auch noch Niemanden gestört. Gruß Steffen
hier nochmal mit Großbuchstaben damit du deinen Lesefluss nicth verlierst ;) weil Bascom nur eine Rechenoperation pro auf einmal kann müsstest für a=b+c+d schreiben a=b+c a=a+d aber das ist Gewohnheitssache. in Assembler kann man so was auch nicht. tja wenn ich denn wüsste das ich mit 128kb vom atmega128 reichen würd...tja.. dann wäre mein Problem ja geklärt. das ganze soll n Simulationswerkzeug werden. 1. das schalten von 3 separaten kontaktpaaren nach dem jeweils ersten Kontakt muss per Timer auf 0,1 ms genau der 2. ausgelöst werden. also z.b. 30,9 ms die Kontaktauslösungen sind abhängig von wegstrecken. 2.ich muss eine Rechteckfrequenz erzeugen. ich dachte da an PWM bereich 0-1000 Hz. 3.ich muss ein SSI mit 125 kHz bereitstellen. das in 31 Bits ne absolute Wegposition verpackt. Datenübertragung ist gebunden an die steigende flanke des 125 kHz Taktsignals. 4.ich muss Eingänge auslesen. anhand dieser Eingänge verändere ich kontinuierlich die absolute Wegposition und muss diese in 3. ausgeben 5. ist die eine bestimmte Position erreicht muss ich ne kraft mit Hilfe der Wegposition (Tabelle/Array) bestimmen und damit über eine Formel ne Geschwindigkeitsänderung in 2. ausgeben. 6.nebenher müssen die in 1. aufgeführten Kontakte ausgelöst werden. Und es ist eine serielle Kommunikation erforderlich mit einem Parameterpc der startwerte an den Controller übergibt und es währe wünschenswert den Mikrokontroller in eine Busstruktur einzubinden. so dass ich vom Parameterpc aus mehrere Simulations-Mikrocontroller betreuen kann. als Bus hatte ich was serielles im Auge. vielleicht mit nem simplen ASCII Protokoll. Modbus zum Beispiel. Einige Sachen können bis nächste Woche noch herausfallen. ne Kommunikation ginge auch über externe Controller. wenn ihr z-b- ne Möglichkeit kennt. kann der max232 serielle Busprotokolle?
Hi Zur Großschreibung: Besonders am Satzanfang ist es wichtig das da ein Großbuchstabe ist. SOnst wird es echt schwer dem Text zu folgen. Großbuchstaben wurden ja nicht umsosnt erfunden. Ich halte es für eine gewisse Art von Höflichkeit wenn man Hilfe von anderen möchte seine Anfrage auch in einer lesbaren Form zu formulieren. Rechtschreibung ist mir dabei relativ egal solangs lesbar bleibt. Fehlende Großbuchstaben stören den Lesefluß IMHO extrem. Zum eigentlichen Thema: Ich sehe nichts was sich nicht in einen ATMega8 packen ließe. Das einzige kritische ist dieses SSI-Interface. Wird dir der Takt da vorgegeben? Gibt es einen Startimpuls? Oder gibtst du den Takt selber vor? Matthias
Ich bin sozusagen der SSI Signalgeber. Aber mein Empfänger braucht die 125kHz. Es gibt keinen Startimpuls. Die 125 kHz müssen kontinuierlich anliegen. Gruß Steffen
Hi Hast du genauere Infos zum Empfänger? Was hängt da dran? Die Übertragung sollte sich mit dem SPI-Interface erschlagen lassen. Die ein oder andere Gemeinheit kanns aber noch geben. Wie wird der Empfänger denn auf die einzelnen Datenpakete synchronisiert? Matthias
hmm?!?!? Die Synchronisation erfolgt über den Taktkanal. Der läuft die Ganze Zeit. Die Datenübertragung ist soweit ich das verstanden hab an die steigende Flanke des Taktes gebunden. Es gibt ausserdem den Datenkanal noch einmal Negiert. <-- Sicherheit Welchen Aufbau ein Telegram hat kann ich von zu Haus aus nicht sagen.Ich versuch das Morgen nochmal zu erläutern. Ich hab dazu leider nur eine Beschreibung für den Lagegeber selbst. Das internet war nicht allzu freizügig mit Infos. Ich hatte gehofft dass sich hier schon Jemand damit befasst hat. :( gruß Steffen
Ah da hab ich was gefunden: http://www.heise.de/ct/96/06/302/ Aber ich bin nicht sicher ob der Lagegeber auch so ein FSYNC Kanal hat. Wie gesagt das muss ich Morgen klären. Steffen
Bascom ist gut. Codevision ist aber um den Faktor 10 besser. SG Josef
Hallo,zum Thema Bascom oder C fogendes: bitte nicht Äpfel mit Birnen vergleichen! Habe selber viel in Assembler,Bascom u. C AVR'S programmiert.Aber in einem ist Bascom unschlagbar,und zwar wenn es darum geht in kürzester Zeit ein Programm zu entwickeln dass gewisse Aufgaben erfüllt wie z.B. einen DS1820 zu bedienen,über RS232 kommunizieren,I2C,RC5SEND ..........die Liste ist schier unendlich.... Versucht mal in C eine DTMFOUT Routine zu schreiben,oder einen DS1820 auszulesen(mit dem ganzen Timing....) Da opfere ich gerne einige bytes Flash wenn ich Stunden oder Tage an programmierarbeit sparen kann.IMHO. Grüße an alle! Arno
Naja, das liegt dann aber nicht an BASIC oder BASCOM als Sprache, sondern ganz simpel an der Verfügbarkeit fertiger Bibliotheken. Und da dürfte es klar sein das ein Hersteller der Wert auf gute Bibliotheken legt eben sein BASCOM gut verkaufen kann. Generell gibt es aber mehr Libraries in C/Assembler allerderings eben nicht aus einer Hand. Auch viele C Compiler sind nicht das gelbe vom Ei. Ein routinierter Assembler Entwickler schafft es mit Leichtigkeit den gleichen C Source mit ca. 40% weniger an Resourcen zu coden. Denoch ab einer gewissen Projektgröße und Komlexität wollt ich nicht auf eine Hochsprache verzichten wollen ;) Gruß Hagen
Zum SSI, Laut beschreibung im TR Electronic Katalog, wird nach der Übertragung eines Datanpacketes ne pause von weniger als 20 µs gemacht--> das bereits übertragene wort wird dann widerholt. ist die pause >20 und <30 µs wird ein neues datenpacket gesendet. Ich weis nicht warum man über ein industriell standartisiertes Interface so wenig Infos bekommt!! Das ist ja grausam! Anders als im Rtikel der CT' beschrieben weist nix in der beschreibung des SSI-Absolutwertgebers auf das vorhandesnsein eines FSYNC Kanals hin. Ist es denn Überhaupt möglich mit 125kHz ne Datenübertragung synchron zum Referenztakt von 125 kHz mit nem Atmega hinzubekommen?!? Gruß Steffen
Hi Kommt drauf an wie exakt die 125kHz sein müssen. Muß der Takt wirklich 100% stimmen hilft wohl nur etwas externe Hardware. Matthias
Die 125kHz sollten schon sehr genau sein. Große Abweichungen kann man sich da ja eh nicht leisten. Ich denke aber, dass das Wichtigste ist,dass er stabil läuft also nicht einmal mit 130 und das andere mal mit 120. Hättest du denn ne Idee mit welcher Hardware man das in den Griff bekommen kann? Coll wär natürlich n einfacher Schnittstellen Chip, der das einfach mal so bereitstellt.. träum un dich einfach nur den gewünschten Wert in n Puffer von dem Teil schreib. Interessant wirds dabei erst wenn ich den Takt variieren kann. Also auch mit 50 statt 125 kHz oder so. Ich möchte mich da auf das Ziel einstellen können, wenn das relativ einfach möglich ist. Steffen
Hi das Problem sind nicht die 125kHz (die kann man mit einem Timer sehr einfach erzeugen) Das Problem ist die parallele Übertragung von Daten. Wenn das also wirklich so exakt sein muß dann würde ich persönlich ein CPLD nehmen und die Übertragung damit realisieren. Matthias
Naja.. ich brauche ja auch die Timer. Wenn ich alles über Timer mache, dann hab ich sie nicht mehr frei. Einen Timer brauch ich auf jeden Fall für die Kontakte, wenn nicht sogar alle(falls mehrere Kontakte gleichzeitig überrollt werden). Diese CPLD sind frei programmierbare Logikblöcke? Ich hab da über google was zu nem Xilinx Spartan3 starterkit gelesen. Leider hab ich mich damit noch gar nicht weiter beschäftigt. Immer wieder Neuland betret Nochmal was zu den ATMegas. Kann ich da echt 'nur' 8 bit Seriell Empfangen? oder gibts da nen größeren Puffer? Ich würd gern in einem 'Rutsch' ne komplette Parameterliste einlesen. Das ist eigendlich völlig unkritisch, zeitmäßig gesehen. Aber das zusammensetzen der einzelnen Byte find ich an der Stelle nicht so toll. Aber ich hab mich wie gesagt nur mit Bascom beschäftigt und da wurde die übertragung von Strings beipielhaft eben so erklärt. Gruß Steffen
@ BomberD: Dein Problem wird nicht das Flash, sondern die Performance von dem Controller. BASCOM kannst du gleich vergessen, wenn du c wirklich beibringen kannst wie Ints abzuarbeiten sind vielleicht mit c, ich würds in assembler programmieren (zumindestens die zeitkritischen Teile). Nehmen wir mal das 125kHz Signal als Basis: ein tmr overflow Interrupt alle 8us als allgemeine Zeitbasis. Du hast also max. 128 Befehle "Platz" (bei 16MHz Takt). Sind Daten zu übertragen brauchst du zum Datenbit setzen und Sendedaten rollen etwa 20 Befehle. Danach kommt eine Abfrage der Kontakte aus [1] ca. 10 Befehle. Decrementieren von 3 Timern, wenn 0 dann die Kontakte für [1] setzen. ca. 30 Befehle. Im worst case braucht diese Routine etwa 70 Befehle (inkl. Einsprung und reti) also bereits 55% der Rechenzeit (70 von 128). Ein Auftrennen in zwei Zeitbasen für Kontaktpollen und 125kHz halte ich für unmöglich da das Kontakteinlesen sicher 1-2us dauern würde und dann das 125kHz aus dem Tritt kommt. Die Kontakte zu Pollen klingt zwar nach schlechter Programmierung, ich denke aber dass jeder weitere Interrupt die 125kHz Generierung zu sehr stören würde. Das Rechteck aus [2] klappt mit einer freilaufenden PWM. [3] passiert bereits in der Int-Routine. Für [4] wäre halt die Art der Eingänge interessant und wie schnell die Änderungen erfolgen. Ich würde diese in der main loop einlesen, verarbeiten und für [3] bereitstellen. Ebenfalls in dieser Loop erfolgt die Abfrage der erreichten Position und Änderung der PWM-Parameter, kommt halt drauf an welche Reaktionszeiten hierbei gefordert sind. [6] erledigt sich ebenfalls in der int-Routine. für die Konfiguration würde ich ein simples RS485 Protokoll "erfinden": PC sendet und alle Controller verwerten die Bytes die für sie bestimmt sind, Rückantworten nur nach Aufforderung durch den PC. Du solltest die Gesamtfunktion noch genauer definieren, welche Länge haben die Ein-, Ausganskontakte, wie schaeun die Eingangssignale von [4] aus und welche Reaktionszeiten mußt du garantieren. Wie genau sind die 0,1ms einzuhalten bzw. wieviel Jitter ist erlaubt? grüsse leo9
Ich dachte eigendlich es wär klüger mittels PWM die 125 kHz Referenztakt für die Datenübertragung hinzubekommen. Das Rechtecksignal ist mit Hz Frequenz doch viel besser beherrschbar. da macht ein oder 2 Takte mehr kaum was aus. ich kann beim 8mHz quarz alle 8000 takte(Im allerschlimmsten Fall)einfach das Ausgangsbit Toggeln. Oder seh ich das falsch? Die Doppelkontakte(hatte ich erwähnt das es Doppelkontakte sind?) dienen dazu wie die Rechteckfrequenz eine Geschwindigkeit zu errechnen. d.h. Rechteckfrequenz muss mit der Dauer der Doppelkontaktbetätigung übereinstimmen. bsp 10m/s Ich muss ne rechteckfrequenz von etwa 620 Hz ausgeben. das ist sozusagen theoretisch das Maximum. Passend dazu muss bei einer Kontaktüberrollung nach dem auslösen des 1. Kontakts der Doppellkontaktgruppe (die sind 10cm auseinander) auf 0,1 ms genau die 10 ms verstreichen. also zwischen 'Ein' und 'Aus' müssen 9,9-10,1 ms liegen. Das Auslösen der Kontakte gebe ich als Simulation vor. Ich könnte mir da zum beispiel ne Wegeliste vorstellen in der Klar ist bei welchem Wegpunkt welches Doppelkontakt-Pärchen ausgelöst wird. Auf den Weg würde ich kommen wenn ich die Perioden des Rechtecksignals zähle. jede Periode entspricht exakt 1,6cm Weg. gruß Steffen
125kHz sind bei 16MHz Quarz = 128 Zyklen, das ist also zu schaffen. Allerdings fällt einem dabei der Hauptnachteil der AVRs auf die Füße, daß sie nur eine Interruptpriorität haben. D.h. man kommt wohl nicht umhin, allen anderen Interrupts in Software (Assembler) eine geringere Priorität zu verpassen. Für sämtliche Zeitsteuerungen brauchst Du doch nur einen Timer. Z.B. in der Codesammlung ist dafür ein Beispiel (Scheduler). Peter
Hi die 125kHz wirst du nur exakt erzeugen können wenn ein Timer die macht. Sobald Software im Spiel ist wirst du Jitter reinbekommen. Bis auf dieses SSI sollte aber ein Mega8 ausreichen. Für das SSI würde ich einen CPLD oder ein kleines FPGA vorschalgen. Matthias
Waum will denn keiner die 125kHz per PWM machen? Hab ich da irgend nen Haken verpasst?!?! bei der Rechteckfrequenz hätte ich mindestens 8-16tausend takte zwischendurch Zeit. oder versteh ich hier was net? BTW: wenn ich beim Atmega32 ne PWM mache ist doch mein 16 Bit Timer weg oder? Gruß Steffen
Ja das mit dem SSI hab ich eigendlich von Anfang an als das größte Problem gesehen. Das Projekt scheint für jemanden der Grad ganz neu mit MC anfängt n bissel zu extrem zu sein. Ich bekomms nicht mal hin son WinAVR C Projekt zuerstellen. nerv Privat würde das ja noch spass machen. aber auf Arbeit unter Zeitdruck ... ich glaub ich bekomm ne Blockade !!! :( Gruß Steffen
entweder bin ich zu doof oder ich kapiers einfach nicht, je mehr du über die Kontakte schreibst desto weniger Durchblick hab ich. Erst soll ein Kontakt nach einer bestimmten Zeit nach dem ersten Kontakt geschlossen werden, jetzt gehts plötzlich um die Zeit zwischen zwei Kontaktimpulsen. Die 125kHz könntest du auch mit PWM machen, aber irgendwann muss der uP ja auch die Datenleitung setzen, müßte also auf sein selbst generiertes Taktsignal reagieren, da kann er doch gleich beide Signale in einem Timer-Int generieren. grüsse leo9
Physikalisch sinds 2 Kontakte die nacheinander geschaltet werden. technisch sinds Doppelkontakte. Ich habe also nicht 6 Einzel sondern 3 Doppelkontakte. Jeder Doppelkontakt hat also 2 Kontakte. Nachdem der erste Kontakt (Bei diesem Doppelkontakt ;) ) aktiviert wurde muss der 2. Kontakt (Bei diesem Doppelkontakt) geschaltet werden. hier gibts also Zwei Kontaktimpulse, die aber auf die Beiden Einzelkontakte des Doppelkontaktes verteilt sind. Des ist schon ein wenig schwer zu erklären. Finde ich. Ich kann ja mal versuchen ein Bild zu malen :( Stell dir einfach so vor DK1(K1,K2),DK2(K3,K4),DK3(K5,K6) innerhalb der DKx müssen die beiden Kontakte gesachaltet werden. Erst der Erste. Das löse ich einfach mal so aus. Der Zweite aber muss in einer genau vordefinierten Zeit nach dem ersten aktiviert werden. bzw. einmal High-Low Schalten. Ich versuche gerne das gut zu erklären. Aber so einfach ist das nicht. Gruß Steffen
Wenn ich dich jetzt richtig verstehe sind alle Kontakte "Ausgaben" vom uP? Wenn dem so ist hast du (wenn die 125kHz der Grundtakt sind) eine Auflösung von 8us mit ca. 2-3us Jitter. Ob das dann deiner "genau vordefinierten" Zeit entspricht musst du entscheiden. Skizze und Gesamtbeschreibung, wer tut was und soll auf was reagieren, wär schon eine tolle Sache. grüsse leo9
Auf die idee das alles an den 125 KHz aufzuhängen bin ich nicht gekommen. Ich glaub das ist aber schon weiter oben mal erwähnt wurden (irgendwie hab ich das ignoriert) hmm...ich werd mal brüber nachdenken müssen (wie gesagt 0,1 ms brauch ich da wären 15 µs nur besser oder? wenns nebenher einfach so abfällt)... kann ich hier bildchen anfügen? vielleicht kann ich mir mal was ausn fingern saugen. steffen
Ja, Alle Kontakte sind Ausgaben. Eingaben sind nur die noch nicht erwähnten digitalen ventile. davon gibts 6 stück. Anhand derer ich den Wert den ich per SSI verschicke ändere. Gruß Steffen
HI, ichhab was für SSI gefunden (hoffe ich) X-SSI-2 Jetzt ist nur noch die Frage ob der nur empfängt oder auch senden kann!! Die Parameter die ich einstellen kann sind genau die die ich brauche!! Gruß Steffen
hmpf, reingefallen das scheint ne messkarte zu sein. :( Steffen
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.