Hallo, ich arbeite derzeit viel mit den kleineren Atmel AVRs rum. Das wäre Attiny13, Attiny24/44/85, Attiny25/45/85, (geplant Attiny841 und Attiny2312), sowie den Atmega328P. Das ganze mache ich in Atmel Studio. Nun gibt es immer mal Probleme, dass ein Code nicht richtig geschrieben wird. Ein Timer läuft nicht so schnell wie gewünscht, weil Prescaler falsch gesetzt sind. Manche Sachen kann man schon mit einer Led ganz gut erkennen. Ua. ob ein Timer Interrupt aufgerufen wird. Die Atmels werden über einen DIAMEX ISP Programmer beschrieben. Von größeren Automatisierungsteuersystemen und deren Software kenne ich das, das man bestimmte Werte überwachen kann, während die Anlage im Betrieb ist. (Bernecker&Rainer). Gibt es sowas auch für Atmel Studio. Wenn möglich, dass es über den Programmer zurückgeführt wird. Die meisten Atmels die ich nutze haben keinen Hardware UART, so kann ich auch kein Bluetooth anschließen, dass wir die Werte an die Konsole überliefert. Ich besitzte zusätzlich 2 FTDI Breakouts. Diese aber mit dranzuklemmen finde ich umständlich und etwas unstabil, da meine Schaltungen auf dem Breadboard stattfinden. Software UART möchte ich vermeiden, falls es geht. Gibt es dazu was passendes oder bin ich mit den Atmels da falsch? Alternativ, gäbe es ein passendes Entwicklungsboard zu empfehlen, welches ggf. den Programmer mitliefert und nur über USB angeschlossen werden muss. Habe mir den STK500 bereits angeschaut. Der wäre vom Aufbau perfekt, da er sehr viele meiner MCUs bereits unterstützt. Attiny84 zB. offizel nicht. Aber da soll es dennoch möglich sein. Vorteil bei einem solchen Entwicklerboard, man hätte alles etwas robuster.
Stefan S. schrieb: > Nun gibt es immer mal Probleme, dass ein Code nicht richtig geschrieben > wird. Ein Timer läuft nicht so schnell wie gewünscht, weil Prescaler > falsch gesetzt sind. In Atmel Studio gibt es den Simulator, mit dem du dir während des Programmablaufs Variablen und Register ansehen kannst. Über Zeitanzeige, Taktzähler und Stopuhr kannst du das Timing genau verfolgen.
Wenn man debuggen möchte sollte man sich schon einen µC aussuchen, der das kann. Oder der auch einen UART für Debuggen noch frei hat. Die PIC's werden mit 2 Drähte programmiert und die haben gute debug Möglichkeiten. Oder größere mit einem ARM Cortex-M3 Kern (STM32 oder LPC1XXX) können schon direkt über USB programmiert werden ohne zusätzliche HW. Die haben auch bis zu 8 UART's drin.
Stefan S. schrieb: > Von größeren Automatisierungsteuersystemen und deren Software kenne ich > das, das man bestimmte Werte überwachen kann, während die Anlage im > Betrieb ist. (Bernecker&Rainer). > > Gibt es sowas auch für Atmel Studio. Wenn möglich, dass es über den > Programmer zurückgeführt wird. Das was du suchst, ist ein JTAG Debugger. JTAG ICE / AvrDragon fallen mir da ein. Bei größeren Projekten würde ich ungern drauf verzichten. Muss natürlich der Controller auch können, belegt halt ein paar pins in der Applikation..
Stefan S. schrieb: > Das wäre Attiny13, Attiny24/44/85, Attiny25/45/85, (geplant Attiny841 > und Attiny2312), sowie den Atmega328P. Diese Controller verfügen alle über Debugwire. Mit JTAGICE, AVR-ICE oder Dragon lassen die sich debuggen. Da hierfür der Reset-Pin verwendet wird, werden auch keine zusätzlichen Pins dafür ver(sch)wendet. mfg.
Stefan S. schrieb: > Nun gibt es immer mal Probleme, dass ein Code nicht richtig geschrieben > wird. Ein Timer läuft nicht so schnell wie gewünscht, weil Prescaler > falsch gesetzt sind. Wie meinst du das? Fehler beim Programmieren oder Fehler im Programm selber? Fehler beim Programmieren sind (fast) unmöglich, weil man einfach nach dem Flashen den Flashinhalt mit der zu schreibenden Datei vergleichen kann. Standardmäßig ist das sogar bei allen Versionen des AVR-/Atmel-Studio so eingestellt. > Von größeren Automatisierungsteuersystemen und deren Software kenne ich > das, das man bestimmte Werte überwachen kann, während die Anlage im > Betrieb ist. (Bernecker&Rainer). Und was hat das mit der Programmierung zu schaffen? > Gibt es sowas auch für Atmel Studio. Wenn möglich, dass es über den > Programmer zurückgeführt wird. Dafür sind die meisten Programmer weder gedacht noch geeignet. > Die meisten Atmels die ich nutze haben keinen Hardware UART Nun, dann macht man halt einen Software-UART drauf. > so kann ich > auch kein Bluetooth anschließen Das kann man dann. > Software UART möchte ich vermeiden, falls es geht. Mit welcher Begründung? Die sollte wirklich sehr gut durchdacht sein, um nicht sofort in der Luft als Scheinargument zerrissen zu werden... Mit Sachen wie "mein Programm nutzt exzessiv _delay(), deshalb geht Soft-UART nicht" gehst du baden. Da kriegst du nur den Tip: Lerne Programmieren.
> Gibt es dazu was passendes oder bin ich mit den Atmels da falsch? Du hast nicht die beste Wahl getroffen. AVRs haben zwar ihre Vorteile, aber die Peripherie gehört nicht dazu. Bei den PICs gibt es eine größere Auswahl an Peripherieeinheiten und besser mit Peripherieeinheiten ausgestattete Controller, und zwar nicht nur unter den alten 8 Bit Architekturen, sondern auch bei den 16 und 32 Bittern. Die 16 Bitter fangen bei 14 Pins an, die kleinsten 32 Bitter haben 28 Pins. Zudem: Die Debuggingfähigkeiten der kleinen AVRs sind nicht sonderlich gut. ISP ist eine reine Programmierschnittstelle, DebugWire ein ziemlicher Krampf. Bei den PICs kannst Du so gut wie alle Typen (auch die kleinen) über das ICSP sowohl programmieren als auch debuggen. Wenn Zeit Geld isst, willst Du nicht darauf verzichten - Du bist dann einfach schneller fertig. fchk
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.