Search Results

In Bascom musst du den Programmer für Arduino auswählen. Dabei sollte es erst mal keine Rolle spielen, ob der angeschlossen ist oder nicht. Kannst aber auch den Programmer einstecken ohne Bascom zu starten. Taucht dann der Fehler auch auf?

Quote from tschoeatsch: “Unter dmesg werden der AVRISPMKII bzw. der Arduino aufgeführt, oder halt unter der app Hardinfo ” Dort wird mein Programmer auch angezeigt. Trotzdem finde ich den Gerätename nicht im Dateiverzeichnis. Wie heißt der bei dir?

Quote from tschoeatsch: “Ich will die hex von Bascom über den bootloader vom Arduino laden. Also idealerweise so, wie es unter win geht, in bascom unter Programmierer Arduino auswählen, baud einstellen und flashen. ” Ja genau! Bascom starten, Programmer auswählen für den Bootloader Support. Irgendwas mit Arduino. Dann manuell Proggen öffnen. Dort die Hex in den Buffer laden und Buffer auf Chip flashen. In windows musste dazu ein Dummy-Projekt mit dem Controller wie auf dem Arduino angelegt werde…

Du kannst die Hex in Bascom laden und von dort mit dem Atmel AVRISP MKII flashen. Also über den Bootloader. Zeigt es bei dir unter /dev/ ein Gerät an wie ttyUSB* oder ttyACM*, wenn der Programmer eingesteckt wird ?

Ich bin jetzt ganz gewiss nicht der Röhrenspezi. Aber jede Röhre hat eine gewisse Verlustleistung / Spannung / Strom der nicht überschritten werden darf. Was begrenzt nun den Anodenstrom, dass die Röhre nicht unnötig belastet wird vorzeitig verschleißt? Ich denke schon, dass da irgendwo ein Widerstand rein muss.

Schau dir mal diesen Thread an. Da ging es genau um den Programmer. bascomforum.de/index.php?threa…2Bunter%2Blinux#post32597

Hi Zorin OS kenne ich nicht mal vom Namen. Scheint was ganz exotisches zu sein. Wenn du von Windows kommst, kann ich dir Linux Mint Cinnamon ans Herz legen. Das verwende ich schon seit Jahren, bietet guten Support und ist recht weit verbreitet und beliebt. Das schöne ist, es wird wie Windows bedient, sogar die Tastenkürzel gehen. Eine Gerätemanager gibt es zwar in Linux (Mint), der zeigt aber keine Schnittstellen an. Denn in Linux wird alles als Datei verwaltet. Es gibt ein Verzeichnis, in dem w…

Wie wäre es mit einem Step-Up-Wandler? Reichelt.de Oder man macht ein analoges Netzteil für die 18V mit Längsregler und die 5V für den Controller mit einem Step-Down-Regler. Etwas in der Art. Reichelt.de

Schau mal hier: vintelec.com/en/702-dg12h1.html Unten links steht Datasheet. Ich kanns aber nicht anwählen.

Ich finde da auch nichts. Einzige Chance über Jogis Röhrenbude oder Radiomuseum.org

Quote from tschoeatsch: “Muss man bei den Dingern die nicht benutzten Segmente auf gnd ziehen, ” Das hängt vom Zweck des Pins ab. Bei Röhren fliest ja immer der Strom von der Kathode (GND) zur Anode. Ich gehe davon aus, dass die einzelnen Segmente quasi Anoden sind mit einer leuchtenden Substanz. Demnach sollten die Segmente bei "High" leichten und bei Verbindung mit Masse aus sein. Ich suche auch mal, ob ich was finde an Datenblatt. Aber du kannst gerne den Jogi anschreiben und fragen. Der hilf…

Schau mal bei Jogis Röhrenbude vorbei. Der hat so was und bestimmt auch weitere Infos. jogis-roehrenbude.de/Roehren-Geschichtliches/Nixie/DG12H.htm

Machst du das mit dem Servo-Befehl? Code? Soweit ich weis, ist das mit den 20ms nicht so kritisch, aber alles hat seine Grenzen. Man muss im Hinterkopf behalten, dass bei 8 Kanälen von einer Funke 8x 2ms als längste Pulse ausgegeben werden. Alle nacheinander. Das ergibt dann schon 16ms für 8 Kanäle mit je 2ms Puls. Dann braucht es eine Pause, damit man den Anfang findet von etwas mehr als ein Puls. Daher kommen die 20ms Wiederholrate. Dem Servo dürfte das relativ egal sein (in Grenzen). Der Serv…

Quote from smatjaz: “Ich habe ein 32x14 (P-10) LED-Panel, das einem 64x32 ähnelt Die LED-Anzeige ist monochrom (weiß). Die Kommunikationsschnittstelle ist bei beiden LED-Anzeigen gleich. Ich frage mich, wie ich „RGB64x32.inc“ ändern kann, damit die LED funktioniert? ” Das frage ich mich auch. Ich kenne dein Display nicht (Datenblatt?) Außerdem muss ein Font aktiviert werden, der da verwendet werden soll. Das sehe ich an deinem Code nicht. Vielleicht solltest du mal den ganzen Code einstellen. Un…

Das liegt an dem Print! Der Programmer wartet auf eine Rückantwort beim Programmierversuch. Das zu schnelle Senden mit deinem Print macht es dem Programmer unmöglich einzusteigen. Füge vor der Hauptschleife einfach obligatorisch ein Waitms 500 ein. Dann klappt das auch. Allerdings bekommst du jetzt das neue Programm mit dem Waitms 500 nicht mehr mit Bascom drauf. Du kannst versuchen, den Chip zu löschen in Verbindung mit Reset drücken am Arduino. Sollte das nicht klappen, spiele einfach mit der …

Quote from Mr.MiGu: “Da man die i2c Adresse des SHT41 nicht ändern kann ... gibt es eine Möglichkeit 2 davon an einem Nano ( evtl. mit Zusatzhardware ) zu betreiben ? ” Zwei von den SHT41 nicht. Die haben alle die Adresse 0x44. Aber im Datenblatt sind auch SHT40 und SHT43 erwähnt. Im ersten Fall kann der sogar die Adressen 0x44, 0x45 und 0x46. Wenn es also jetzt nicht explizit der SHT41 sein muss, wäre das eine Option. Details dazu findest du im Datenblatt.

Du musst gar nicht downgraden und auch nicht compilieren. Normalerweise liegt die letzte bin-Datei ja im Ordner. Die sollte eigentlich mit dem Inhalt im Controller übereinstimmen. (Natürlich nur, wenn man danach nichts mehr ändert und wieder compiliert.) In dem Fall musst du nur die Bas-Datei laden und auf Manuell Programmieren gehen. Dort im Fenster gibt es dann den Verify-Button oder auch im Menü Chip den Eintrag Verify auswählen. Dann Verify ausführen lassen. Ist der Buffer (bin-datei auf der…

Ich denke das liegt an deiner Versions_Mode Routine. BASCOM Source Code (20 lines)Bei Zeile 9 - 11 wartest du auf ein Zeichen. Wenn eins da ist, wird es in Zeile 15 im Buffer abgelegt. Hier solltest du B_Udr verwenden und nicht UDR. Das Zeichen wurde ja schon ausgelesen. Und wenn jetzt noch nicht genug Zeichen empfangen wurden, beginnt das wieder bei Zeile 7. Und jetzt wird "read " ausgegeben mit 9600 Baud über Soft-Uart. Das sind 7 Zeichen (incl. CRLF). Und alles was in der Zeit empfangen wird …

Hast du mal das Buf-Array ausgeben lassen ob da überhaupt ein v drin ist? Wenn nicht, liegts wohl am Empfang, wenn doch, dann wohl an der Suchroutine. Aber warum machst du dir so eine Mühe? Wieso benutzt du nicht einfach den SerialIn Buffer? Checken ob was drin ist, wenn ja byte lesen. Ist es v, wenn nicht verwerfen und von vorn. Oder v da, dann die nächsten bytes lesen. Der Buffer leer sich dann von ganz alleine, kannst eigentlich nichts verpassen.

Woran erkennst du, dass es daran nicht liegt?