ARDUNIO-NANO Nachbau kritisch?

    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!

    • ARDUNIO-NANO Nachbau kritisch?

      Hallo!

      Es ist mal wieder soweit, das ich hier nach Rat fragen muss.
      Vor einiger Zeit habe ich mir über eBay einige Ardunio-Nano Nachbauten auch Fernost besorgt.
      Die Teile die dort im 5'er Pack für <<10€ verramscht werden.

      Bislang als Experimentierbauteile für einfache Sachen benutzt, aber nie was ernsthaftes.

      Nun wollte ich mit soeinem Teil eine einfache Klimasteuerung bauen:
      Drei DS18B20 auslesen sowie Minimal- und Maximaltemperaturvorgabe mittels ADC(Spindeltrimmer), sowie ein 16x2-LCD.
      So weit so gut...nur das da nix geht...und zwar wirklich nix.
      Seit zwei Tagen versuche ich zu ergründen ob es an Bascom liegt, am NANO, am LCD, oder zwischen meinen Ohren.

      Eigentlich ist der angehängte Quelltext überflüssig, aber ohne wird hier gerne rumgemosert.

      Der Fehler:
      Irgendwo zwischen Zeile 1 und Zeile 61 bleibt der Programmablauf stecken.
      Erkenne ich darin das nicht einmal der erste Print-Befehl in Zeile 62 ausgeführt wird.

      Falls jetzt jemand meint die Portkonfigurationen zwischen den Zeilen 52-60 sind Schuld: Selbst komplett auskommentiert bleibt es hängen.

      Schmeiße ich da ein anderes Testprogramm drauf, läuft alles: RS232-Ausgaben mit 38400Bd, das LCD initialisiert, alles läuft.
      Bei dem oben eingefügten Quelltext hingegen könnte man fast meinen der Quarz wäre defekt, oder Reset hätte Kurzschluß nach GND.

      Neben den NANO-Nachbauten wäre noch das LCD erwähnenswert. Es handelt sich dabei um das TC1602A-09 (Pollin 120422), Ansteuerung im 4Bit-Mode.
      Mit anderem Programm läuft es auch zuverlässig.

      Saudumme Frage: An den knapp 40 Zeilen Kommentar oben dürfte das doch nicht liegen, oder?
      Die werden doch schließlich nicht mit kompiliert. Fehler werden mir beim Kompilieren auch nicht angezeigt....

      Grüße

      Jürgen
      Dateien
    • Hallo!

      PortC.0 und PortC.1 habe ich in Zeilen 100-103 definiert:

      BASCOM-Quellcode

      1. 'Schaltzustände auf Startbedingungen setzen
      2. Kompressor Alias Portc.0 'Portansteuerung für FET Kompressor
      3. Luefter Alias Portc.1 'Portansteuerung für FET Innenlüfter (option)
      4. Kompressor = 0
      5. Luefter = 0

      DDRb/c/d habe ich schon mehrfach komplett auskommentiert, ohne Effekt.
      Pullups habe ich ebenso schon alles durchprobiert ob da was harkt.

      Was mir schon kurios vorkommt:
      Die Nanos haben vier LED's:
      Eine für RxD, eine für TxD, eine für Vcc, sowie eine an PortB5.

      Die TxD-LED blitzt zuverlässig auf wenn andere Programme auf dem Nano was über die RS232 rausschlieben.
      Setze ich aber den TxD oder RxD via PortD.0 = 1 oder PortD.1 = 1 auf High, leuchten die LED's nicht.

      Achja:
      Den Bootloader der NANOS habe ich runtergeschmissen, da ich dort ausschließlich via ISP dran programmiere.

      Habe gestern ganz Mutig angefangen das bisherige Programm Version 003 komplett neu als 004 hoch zu ziehen, und zeilen- bis Abschnittsweise den Quelltext rüber zu ziehen.
      Zuerst kam noch die erste Print-Meldung raus, aber bereits nach dem einfügen der 40-zeiligen Kommentierung fingen die Probleme mit der LCD-Initialisierung an: Nach 15 mal Resettaster drücken initialisierte das LCD vielleicht zwei mal korrekt.
    • DG7GJ schrieb:

      Eigentlich ist der angehängte Quelltext überflüssig, aber ohne wird hier gerne rumgemosert.
      Mal im Vorraus über's Maul fahren ist aber auch keine Lösung. Und ob der Quelltext überflüssig ist, kannst du doch gar nicht beurteilen, sonst hättest du doch kein Problem? (andere Programme funktionieren ja)

      DG7GJ schrieb:

      Irgendwo zwischen Zeile 1 und Zeile 61 bleibt der Programmablauf stecken.
      Erkenne ich darin das nicht einmal der erste Print-Befehl in Zeile 62 ausgeführt wird.

      Vielleicht schafft der Prozessor gar nicht, das Print auszuführen? Vielleicht hängt er vorher im Reset?
      An PortD und PortB.0 solltest du das DDR gar nicht anfassen, das übernehmen die LCD-Konfiguration und Print automatisch.

      Kommt eine Ausgabe, wenn du das Programm nach Zeile 62 weglässt?

      DG7GJ schrieb:

      Zuerst kam noch die erste Print-Meldung raus, aber bereits nach dem einfügen der 40-zeiligen Kommentierung fingen die Probleme mit der LCD-Initialisierung an: Nach 15 mal Resettaster drücken initialisierte das LCD vielleicht zwei mal korrekt.
      Manch ein LCD braucht Zeit zum Hochfahren. Kein Scherz. Eine Wartezeit vor der Initialisierung von vielleicht 100ms hilft.
    • Hallo Michael!

      Michael schrieb:

      Mal im Vorraus über's Maul fahren ist aber auch keine Lösung. Und ob der Quelltext überflüssig ist, kannst du doch gar nicht beurteilen, sonst hättest du doch kein Problem? (andere Programme funktionieren ja)

      Nunja, falls es in meinem Post nicht deutlich geworden ist, weil nur beiläufig erwähnt um den Fokus meines Beitrages nicht vom Problem abzulenken:

      Ich versperre mich nicht vor "billiger China-Ramschware" wobei ich aber leider auch auf diversen Erfahrungen ein gewisses Misstrauen darauf lege.
      In diesem Punkt: Wenn ein offizieller NANO in Europa gute 18-22€ je Stück kostet, und aus Chian 5 Stück für 6-8€ und kostenlosem Versand, stelle ich erst mal in Frage: Wie robust ist der Quarz? Ist das ein echter Atmel M328P? Wie genau ist der Schaltplan?

      Wie gesagt...einfache Sachen laufen auf den Teilen bisher...halt so bis gefühlt 8% Flash-Auslastung bisher.
      Ind kaum das ich an die 19% komme geht nix mehr. Erinnert mich an berufliche Erfahrungen mit Plagiaten.

      Michael schrieb:


      Vielleicht schafft der Prozessor gar nicht, das Print auszuführen? Vielleicht hängt er vorher im Reset?
      An PortD und PortB.0 solltest du das DDR gar nicht anfassen, das übernehmen die LCD-Konfiguration und Print automatisch.

      Ok, das ist schonmal ein Tip den ich mir merke.
      Bislang habe ich bei allem und jedem was ich bisher unter Bascom gemacht habe alle vorhandenen Ports so vorkonfiguriert.
      Also Inputs nur wo ich brauchte oder es Sinn macht (z.B. RxD), und Outputs da wo es Sinn macht.
      Ich versuche mir das dann mal wieder ab zu gewöhnen..:-)

      Michael schrieb:

      Kommt eine Ausgabe, wenn du das Programm nach Zeile 62 weglässt?

      Ne, selbst wenn ich alles nach Zeile 62 auskommentiere wird der Printbefehl nicht ausgeführt.

      Michael schrieb:

      Manch ein LCD braucht Zeit zum Hochfahren. Kein Scherz. Eine Wartezeit vor der Initialisierung von vielleicht 100ms hilft.

      Ja, das ist klar. Aber dieses Thema ist auch etwas undurchsichtig: Die LCD-Config von Bascom hat ja schon ein weitläufiges Timingschema eingebaut, nur finde ich in der Bascom-Hilfe keine genaue Definition.
      Und genau das kollidiert mit meinen Erfahrungen bisher:
      Teurere LCD's der 16x2-Klasse funktionierten bisher fast immer spontan mit der LCD-Rautine von Bascom. Die wenigen Problemfälle half ein waitms 500 sofort.
      Erstmalig mache ich was mit dem 4,95€-LCD von Pollin, hilft nix mehr mit 500-1000ms Gedenkpause.
      Eher verhält es sich bei sehr kurzen Programmen auf dem NANO direkt so problemlos wie teurere. Sobald aber die Ausgabe schneller wird initialisiert es erst nach zig manuellen Resets oder gelegentliche cls werden verschluckt.
      Dummer weise ging es mir aber weniger um Qualität und Preisklasse, sondern eben um Blau/Weis:
      Das LCD soll etwa in Kniehöhe montiert werden und unabhängig von Lichtverhältnissen problemlos ablesbar sein.

      Grüße

      Jürgen
    • Hallo Leute!

      Soeben noch eine neue Erkentniss bei mir:
      Die von ftelektro editierte BAS in Bascom geladen und auf den NANO geschrieben funktionierte auf Anhieb.
      Diese dann unter einen neuen Dateinamen aus Bascom herraus gespeichert geht schon wieder gar nix mehr.

      Schuld ist die Config welche Bascom beim Anlegen eines neues Projektes produziert:

      Quellcode

      1. [COMPILER-CHIP]
      2. Chip=m328pdef.dat
      3. XRAM=0
      4. Waitstate=0
      5. XA=0
      6. Stacksize=40
      7. Framesize=32
      8. Sstack=16
      9. [COMPILER-OUTPUT]
      10. Report vars=1
      11. Optimize=1
      12. Binary File=1
      13. Hexadecimal File=1
      14. Report File=1
      15. Debug File=1
      16. Error File=1
      17. ASM File=0
      18. LST File=0
      19. OBJ File=1
      20. SWAP File=1
      21. [COMPILER-COMMUNICATION]
      22. Baudrate=38400
      23. Frequency=16000000
      24. [COMPILER-I2C]
      25. Scl=0
      26. Sda=0
      27. [COMPILER-LCD]
      28. DB7=PORTB.0
      29. DB6=PORTD.7
      30. DB5=PORTD.6
      31. DB4=PORTD.5
      32. E=PORTD.4
      33. RS=PORTD.2
      34. LCD=2
      35. BUS mode=0
      36. DATA mode=0
      37. LCD address=C000
      38. LCD-RS=8000
      39. [COMPILER-MISC]
      40. Size Warning=1
      41. 1wire=PORTB.1
      42. [COMPILER-SPI]
      43. HW SPI=1
      44. SPICLOCK=13
      45. SPISS=13
      46. SPIMOSI=14
      47. SPIMISO=15
      Alles anzeigen

      Genau da kollidiert was...nur was?
      Bis auf die I²C-Defaultwerte (nutze ich hier eh nicht) sehe ich dort aber auch keine wirklichen Einträge die Falsch sind.
      Lösche ich diese *cfg vor dem kompilieren führt das zu einer lauffähigen *.bin.
      Mit der *.cfg oben läuft die *.bin nicht auf dem NANO.

      Auf dem µC steht sehr schwach gelasert "MEGA328rAU".

      Definiere ich den Chip als "m328def.dat" schlägt der Programmer alarm, weil der NANO via ISP meldet er sei ein ATMEGA328P.

      So, nun mal in Bascom auch die SPI und die I²C-Ports korrigiert:
      Die *.cfg führt noch immer zu einer kompilierung ohne Fehlermeldungen aber ohne Funktion.
      Lösche ich die *.cfg vor der Kompilierung funktioniert es ?!?
      Irgendwie stehe ich da auf dem Schlauch...

      Grüße

      Jürgen
    • Wenn du eine Datei umbenennst, hakelst du dann auch 'leave cfg' (oder so) an, damit die neu angelegt wird? Sollte man machen (glaube ich).
      Raum für Notizen

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

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