Sound parallel zu anderen Aktionen

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Das Martinshorn macht keine Fehler aber auch hier läuft der timer fröhlich durch ohne irgendwas zu bewirken. Zum testen muß ich noch die Hardware schaffen mein bisheriger Programiersockel hat nur 24 Pins. Eigendlich wollt ich nur "mal schnell" die Software dem mega anpassen und das nächste Woche zusammenbauen. Nun hänge ich seit gestern Abend an einer Zeile. Langsam kann ich nachvollziehen warum in Tokio Programmierer aus dem Fenster springen.
      Zunächst mal schönen Dank an alle die sich den Kopf verbrochen haben. Ich denke ich werde morgen mal was zusammenhängen um einen Test zu fahren.
    • hero schrieb:

      Nimm mal so ein abgespecktes Programm wie dieses:
      und wenn man sowas im Simulator laufen lässt, auch mit Option 'sim timer' kann man lange auf das toggel von einem pin (Oc2) warten, auch der Zählerstand vom timer schert sich nicht um das clear timer=1.
      Also hilft nix, muss real probiert werden.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • hero schrieb:

      Hatte ich ja geschrieben, dass die Ausgangspins im Sim nicht reagieren.
      Wo? Da muss ich gerade meine Gurkenscheiben aufgelegt haben, hab' nix gesehen.
      Raum für Notizen

      -----------------------------------------------------------------------------------------------------

      -----------------------------------------------------------------------------------------------------
    • tschoeatsch schrieb:

      Hm, an welcher Stelle jetzt am Monitor,
      Ich würde sagen, links unten. Da schieb ich immer das LCD hin. ^^
      Aber mal im Ernst, ich habe ein Programm, mit dem kann man elektronische Schaltungen simulieren.
      Male ich ein Multivibrator mit gleichen Bauteilen zusammen, schwingt die Simulation nicht an.
      Auf dem Brotbrett ein Störsender vom feinsten !
      Ich lehn mich mal bisschen aus dem Fenster. Simulation ist Theorie, Hardware ist Praxis. a_71_f9c57bbe
      So, jetzt zurück zu Bascom.

      Detlef
      Leichtsinn ist kein Mut, Vorsicht keine Feigheit.
    • Nr. 40

      @Pluto25
      Warum machst du eigentlich den Käse mit dem Config Serialin ... Bytematch=all?
      Bei jedem empfangenen Zeichen wird das Label Serial0bytereceived angesprungen und dort verarbeitest du die Zeichen. Außerdem hantierst du überall in deinem Programm mit den System Variablen _rs232... und clearst den Serialin einfach irgendwo. Das wird die schwer auf die Füße fallen. Würde ich definitiv anders machen.
    • Pluto25 schrieb:

      Das mit dem $ hab ich hier gelernt sollte ich es besser lassen?
      Im Bascomforum hast du es sicher nicht gelernt. Da hätte ich schon was gesagt ;)

      Pluto25 schrieb:

      die Pullups werden nicht mit pin beeinflusst es ist ein reines Leseregister.
      Vorsicht! Neuere Atmegas benutzen das Beschreiben des PIN-Registers zum Toggeln des Pins.

      Toggle_PIN.png

      hero schrieb:

      Das muss irgendwann ergänzt worden sein, früher ging das definitiv auch nicht.
      Ganz früher gingen Timer nie im Simulator, nur mit manuellem Auslösen
    • Die Kurzform - es ist nicht fertig.
      Das ganz durchlebt eine art evulotion. Bisher arbeitet das ganze mit einem tiny44, der ein 2*16 Lcd alle paar Sekunden umschaltet und ununterbrochen über einen Lcd-pin die werte vor sich hin brabbelt als software Usart. Wenn dann mal der PC an ist kann ich sie ansehen ohne zu ihm zu gehen. Er hat keine RX.
      Nun sollen noch andere ihre Werte preisgeben können und damit fällt diese Lösung flach. Komplett flach er hat zu wenig Pins und das Lcd zeigt immer das was ich gerade nicht wissen brauch. daher soll ein 4*16Lcd dran und das braucht eine negative Vo - daher das zappeln.
      Das Serial0bytereceived kommt aus einen 2313 der hat so wenig Speicher das ich seine Variable zur Auswertung nutzen mußte. Die Orginalversion schrieb es in einen String was jedoch so lange dauerte das er ständig Zeichen verlor. Auch bietet der die Möglichkeit jedes Zeichen einzeln zurückzugeben so das der Sender gleich sieht was angekommen ist. Sehr praktisch beim ansprechen über puttytel. Ein input stopt das ganze Programm solange der Satz nicht zu ende ist. (oder ich noch tippe) Und zu einem Totalaufall führt wenn einer gerade ausgeschaltet wird.
    • Pluto25 schrieb:


      Die Orginalversion schrieb es in einen String was jedoch so lange dauerte das er ständig Zeichen verlor. Auch bietet der die Möglichkeit jedes Zeichen einzeln zurückzugeben so das der Sender gleich sieht was angekommen ist. Sehr praktisch beim ansprechen über puttytel. Ein input stopt das ganze Programm solange der Satz nicht zu ende ist. (oder ich noch tippe) Und zu einem Totalaufall führt wenn einer gerade ausgeschaltet wird.
      Ich habe nicht gesagt, du sollst Input nehmen oder einen ganzen String einlesen, aber so wie du es machst, ist es gar nicht gut.
      Und weniger Speicher benötigt das auch nicht. Die System Variable _rs232inbuf muss ja auch alle 16 Byte halten können. Du brauchst halt zusätzlich Zeit, weil erst in einem Interrupt jedes Zeichen eingelesen und gespeichert wird, und dann kommen deine Befehle noch hinterher.
      Es wäre viel sauberer, wenn du das eingehende Byte selber verarbeiten würdest und nicht die Umwege über die vom Compiler erzeugten Routinen und Variablen nehmen würdest.
      Aber wir können dir nur raten, wenn du dabei bleiben willst, kann ich damit gut leben.
    • Ich bin dankbar für jeden Rat selbst ein falscher verbirgt einen Lerneffekt und ein Guter um so besser . Nur ist die Machienenahe umsetzung recht neu für mich so das ich mich noch einarbeite. - Selber verarbeiten? Nun ein int scheind mir zwingend erforderlich da schon einige Zeichen eingegangen sein können bevor eine Lcd-anweisung abgearbeitet ist und damit fällt auch ischarwaiting aus und damit sind meine bisherigen Kenntnisse zu Ende.
      Der Mega hat Speicher satt und wo sie auf dem 2313 funktioniert war das die beste mir bekannte Lösung. Wenn der Mega seinen Job macht finde ich vielleicht eine Lösung dem 23er zu verbessern. Eine Rotine die die ankommenden Zeichen sofort bearbeitet bräuchte gar keinen Speicher mehr muß aber "sauschnell" sein. Ein Zeichen verarbeiten während das nächste schon reinkommt (<1ms) 128Clocks - is ne Herausforderung.
    • Pluto25 schrieb:

      Ein Zeichen verarbeiten während das nächste schon reinkommt (<1ms) 128Clocks - is ne Herausforderung.
      Bei 1MHz Taktfrequenz, die du in deinem letzten Programm benutzt hast, sind das aber 1000 Clocks.
      Btw: Wenn's so eilig ist, dann nimmt man die Hardware, die der AVR bietet.

      P.S.: Welche Geschwindigkeit hat denn deine serielle überhaupt? Ich sehe nichts im Programm eingetragen.
      In deine IDE können wir nicht schauen und wenn du das Programm in einem halben Jahr anschaust, weißt du es auch nicht mehr.
    • Ja die "$baud = 9600" ist irgendwie verlorengegangen. Die Datenabfrage ist im Moment völlig zeitunkritisch aber es schien mir ein geläufiger Wert zu sein und 300Baud scheint mir dann doch etwas langsam. Auch wenn ichs nicht eilig habe so scheint es mir doch irgendwie doof der Fragenden Rotine zu sagen mach nach jedem Byte ne kleine Pause. Aufgefallen ist es erst nachdem ich mit Hterm gearbeitet hatte. Das sand alles bis zum enter mit einem Schlag durch. Was dann erst mal gar nicht ging. Daher der "Stress". Die 1000000 sind werkseinstellung dann brauch ich nicht in die Lock u Fuses bis das Projekt funktionsfähig wird. Danach wird der mindest mögliche Clock gewält. Einmal 128k ein anderes mal 8M (Servos). Die Hardware besteht aus einem shift-register soweit schon toll das ich nicht jeden Spannungswechsel selbst beobachten muß.
    • Pluto25 schrieb:

      Je langsamer der Clock desto stabiler das System
      Die Stabilität hängt davon nicht ab, langsame Systeme haben ein Zeitproblem, Überschneidungen von Ereignissen bringen das System aus dem Tritt, wie man an deinem Problem sieht.

      Pluto25 schrieb:

      Weniger Stromverbrauch /Eigenerwärmung, rubuster gegen Spannugsabfälle.
      Eigenerwärmung bei 16MHz wirst du beim AVR kaum feststellen können. Bei Spannungsabfällen kann das System nicht schnell genug reagieren, wenn der Takt nur 128kHz hat.

      Pluto25 schrieb:

      Das Überschwingen parallel verlegter Leitungen fällt weniger ins Gewicht.
      Schlechte Layouts sind auch bei langsamen Takt ein Problem

      Pluto25 schrieb:

      Der mit den 8Mhz ist das einzige bei dem das Lcd schonmal abschmiert. Muß nicht zusammenhängen,
      Hängt es auch nicht, da bin ich mir sicher.

      Ich denke, du verrennst dich da in ein Problem, das nicht existiert.
      Wenn du verrätst, was es werden soll, kannst du bestimmt hier wertvolle Tips erwarten, wie man es besser löst.
      Ich möchte aber nicht ins Blaue hineinraten, deshalb geb ich dazu auch keine Antwort.