Ich komme mir von AVR bzw. jetzt Microchip ziemlich verarscht vor. Ist die aktive Entwicklung von Atmega8/16/32 überhaupt noch angedacht? Ich komme mir vor wie in der Steinzeit, wenn ich mir einen JTAGICE3 kaufe und dann avarice scheinbar die einzige Möglichkeit ist damit zu arbeiten. Ich habe genau diese Probleme (und mehr: hällt nicht mal beim Breakpoint an): Beitrag "Alternative zu AVaRICE ?" Und nirgends im Netz ist Hilfe/Dokumentaion zu finden. Meiner Meinung nach ist Unix die einzig ware Umgebung für Entwickler. Habe ich jetzt doch keine Wahl und muss für die Atmels ein AVR Studio 7 aufbringen, damit ich debuggen kann? Grüße Oekel
Gast
#5906841
Das sind doch alles alte Chips. Gibt auch neueres mit Avr und jtag
Wenn man Steinzeit Chips mit propritärer Debug Schnittstelle (die ist nicht öffentlich dokumentiert) kauft, muss man auch mit Steinzeit Werkzeugen arbeiten. Es hat seine Gründe warum selbst Atmel/Microchip ARM Cortex-Mx Chips anbietet...
ok, das war etwas zu weit zurück gegriffen. Hier der Atmega644 (hat jtag) Wird von meinem Programm 20% (speicher) ausgelastet und hat eingentlich schon viel zu viel IOs. Hab ihn nur wegen dem JTAG und nun? Nehme ich avarice und nichts geht.
Gast
#5906870
Hi >Gibt auch neueres mit Avr und jtag ATMega16 und 32 besitzen eine JTAG-Schnittstelle Der ATMega8 hat keine Debugschnittstelle. Kanne aber durch einen pinkompatiblen ATMega88 ersetzt werden. MfG Spess
D a v i d K. schrieb: > st die aktive Entwicklung von Atmega8/16/32 überhaupt noch angedacht? > > Ich komme mir vor wie in der Steinzeit, wenn ich mir einen JTAGICE3 > kaufe und dann avarice scheinbar die einzige Möglichkeit ist damit zu > arbeiten. Hallo, ich arbeite auch gerne unter Linux und mit "freien" Tools und finde es schade, dass Programme wie avarice scheinbar nicht mehr weiter entwickelt werden. Da das aber auf Freiwilligkeit basiert, darf man sich nicht beschweren. Den Internetseiten von microchip nach bietet microchip aber schon proprietäre Lösungen an. "Based on the NetBeans IDE from Oracle, MPLAB X IDE and runs on Windows®, Linux® and Mac OS X®." http://ww1.microchip.com/downloads/en/DeviceDoc/50001894H.pdf MPLAB® Snap In-Circuit Debugger https://www.microchipdirect.com/product/search/all/PG164100 Development Tools https://www.microchip.com/development-tools/
Vor langer Zeit hatte ich mal den Debugger unter Linux mit Eclipse am laufen, aber der Weg dahin war steinig, und die Nutzung schnarchlahm. Mein persönliches Fazit: Das macht wirklich keinen Spass, und heute nutze ich (fast immer) lieber die STM32. Da funktioniert das deutlich besser.
Gast
#5906886
Wenn du nicht wie in der Steinzeit entwickeln willst - warum benutzt du dann überhaupt noch diese prähistorische 8Bit Technologie?
Ich frage mich eigentlich immer was debuggen für einen Sinn bei uCs macht. Meist sind es doch zeitkritische Sachen, die man auf so 8-Bittern erledigen möchte. Notfalls tut es dann halt mal ein Pinwackeln oder eine serielle Ausgabe an geeigneter stelle
Andreas B. schrieb: > Ich frage mich eigentlich immer was debuggen für einen Sinn bei > uCs macht Du hast halt noch nie 8 Stunden am Tag ernsthaft komplexe oder knifflige Sachen entwickelt. Da hat man keine Zeit eine 16 Bit zahl per Morsecode rauszublinken, da möchte man einfach nur schnell den Controller anhalten und direkt reinschauen ohne jedesmal umständliche Instrumentierungen anzubringen und hinterher wieder wegzumachen.
Gast
#5906931
Andreas B. schrieb: > Ich frage mich eigentlich immer... Ja, geht mir ähnlich. Wenn jemand denn schon seit langem mit seinem Lieblings-µC herumwerkt, dann sollte er seinen Chip inzwischen so gut kennen, daß er eigentlich überhaupt nicht mehr debuggen muß, sondern auf sein eigenes Portfolio an bewährten und bereits ausgetesteten Quellen zugreifen kann. W.S.
Gast
#5906944
D a v i d K. schrieb: > ok, das war etwas zu weit zurück gegriffen. Hier der Atmega644 (hat > jtag) > Wird von meinem Programm 20% (speicher) ausgelastet und hat eingentlich > schon viel zu viel IOs. Wenn's unbedingt kleiner sein muss, nimm halt die Chips mit debug wire. Etwas eingeschränkt, aber reicht..
W.S. schrieb: > Andreas B. schrieb: >> Ich frage mich eigentlich immer... > > Ja, geht mir ähnlich. Ja, bei deinen handgeklöppelten I2C-Funktionrn braucht man keinen Debugger. Wenn man hingegen ein System mit TFT, GUI, Touch, komplexen Netzwerk-Protokollen etc. entwickelt ist ein guter Debugger unbezahlbar.
Gast
#5907036
D a v i d K. schrieb: > Ich komme mir von AVR bzw. jetzt Microchip ziemlich verarscht vor. Nun ja, dieses Zeug hat Microchip nicht verbrochen! Die bieten das halt noch an, wer das heute noch für neue Projekte kauft, ist selbst schuld. Bei den AVR war das mit dem Debugging schon immer ein Krampf: Die brauchen nur für das ISP schon sechs Drähte (Microchip sonst fünf) und für das Debugging geht noch ein ganzer Port verloren (Mirochip macht das über dieselben fünf Drähte). Schaue dir mal beispielsweise einen PIC16F1828 an - der ist vergleichbar zum ATmega8. Debugging geht einwandfrei, kostet weniger und ist ebenfalls uralt. Über andere fehlende Funktionalität (interner Oszillator nicht während des Betriebes umschaltbar usw.) sagen wir erst einmal gar nichts.
Michael schrieb: > Über andere fehlende Funktionalität (interner Oszillator nicht während > des Betriebes umschaltbar usw.) sagen wir erst einmal gar nichts. Also jedes neuere Projekt mit einem PIC starten? (ist eine ernste Frage) Ich hab mal ein paar Downvotes oben verteilt ;) Ist ja echt a***tig wie neunmalklug geblinkt wird :P Hier noch meine Erkenntnis des Tages: Beitrag "Anleitung JTAGICE3 Downgrade"
Bernd K. schrieb: > Du hast halt noch nie 8 Stunden am Tag ernsthaft komplexe oder knifflige > Sachen entwickelt. Habe ich schon. Zwar nicht 8h am Tag, da es ein Hobby ist. Aber wie schon erwähnt sind das meist zeitkritische Dinge, die man mit einem 8-bitter erledigt. Da nützt ein Debugger rein gar nichts. W.S. schrieb: > Wenn jemand denn schon seit langem mit seinem Lieblings-µC herumwerkt, > dann sollte er seinen Chip inzwischen so gut kennen, daß er eigentlich > überhaupt nicht mehr debuggen muß, sondern auf sein eigenes Portfolio an > bewährten und bereits ausgetesteten Quellen zugreifen kann. Na, so weit geht es dann doch nicht, daß ich für alles eine lib habe. Ich würde schon mal ganz gerne mal debuggen, aber das nützt alles nichts wenn es um us geht, wo dann irgendein Signal anliegen oder abgefragt werden muß. Harry L. schrieb: > Ja, bei deinen handgeklöppelten I2C-Funktionrn braucht man keinen > Debugger. Schön, daß Du weißt was ich programmiere. ;-) > Wenn man hingegen ein System mit TFT, GUI, Touch, komplexen > Netzwerk-Protokollen etc. entwickelt ist ein guter Debugger unbezahlbar. Mit einem 8-Bit Controller? Aha!
Andreas B. schrieb: > Aber wie > schon erwähnt sind das meist zeitkritische Dinge, die man mit einem > 8-bitter erledigt. Da nützt ein Debugger rein gar nichts. Man muss halt auch mit dem Werkzeug umgehen können.
Gast
#5907204
> Ist die aktive Entwicklung von Atmega8/16/32 überhaupt noch angedacht? Solange die aktuellen Entwicklungstools auf ATmega getrimmt werden, denke ich mal ja. > Also jedes neuere Projekt mit einem PIC starten? (ist eine ernste Frage) Nö. Die Pics haben zum Thema Debugging halt ein besseres "Preis-Leistungsverhältnis". Noch besser ist dies bei bestimmten Cortexen. Vielfalt ist Trumpf. In der Fachpresse war mal ein Vergleich der uC-Hersteller. Microchip war derjenige mit dem einfachstem Ökosystem. Man nehme MPLABX+XCxy+Pickit und oftmals ohne frickeln funktioniert es. Das wurde damals auch von der Konkurrenz bestätigt. Warum du unbedingt mit eclipse + avarice arbeiten willst, ist mir etwas unklar. Tausche die java-ide eclipse durch die java-ide netbeans mit MCHP branding. Und im Jahr 2019 kann man auch mal den 15$-Snap probieren. Habe schon AVR mit MPLABX entwickelt. Läuft durchaus brauchbar. Bin auch unixoid unterwegs.
Gast
#5907224
Ich hatte mich als Anfänger lange darüber geärgert, dass die Debugger von Atmel schweineteuer waren. Dann konnte ich einen Dragon für 45€ kaufen - immer noch teuer aber ich war heiß drauf. Vor allem, weil die Mikrocontrolle mit denen ich groß wurde, keine Debugger Schnittstelle hatten. Den habe ich dann zusammen gerechnet 5 Tage benutzt und bin dann wieder zu Morsecodes und seriellen Ausgaben zurück gewechselt. Denn er war lahmarschig, nicht Linux kompatibel (jedenfalls habe ich das mit avarice nicht hinbekommen), und das Anhalten im Debugger hat die Funktion der Maschinen gestört. Ist nicht so lustig, wenn ein Modellauto gegen die Wand kracht, weil man den PI Regler gerade angehalten hat. Oder wenn die Waschmaschine überläuft während man sich die Messwerte vom Füllstands-Sensor anguckt. Ich hatte mir vorgestellt, dass so ein Debugger ein riesen Gewinn sein würde. War es aber nicht. Inzwischen nutze ich auch STM32 Controller und da ist die Debugger Schnittstelle (obwohl viel schneller und vielseitiger) für mich nur noch ein nettes Gimmik. Ich hätte die STM32 Boards auch ohne diese Schnittstelle gekauft. Wo ich gerade beim Modellauto war: Serielle Ausgaben kann man prima per Bluetooth Modul drahtlos an den PC senden.
Gast
#5907241
> 5 Tage Immerhin. Meiner war schon beim scharfen Angucken kaputt gegangen. Das Austauschexemplar vom Distributor wanderte dann schnurstracks in einen dunklen Karton. Zusammen mit den AVRs. Und wenn sie nicht gestorben sind, dann liegen sie da noch heute. Zusammen mit STK-200 und STK-500. Ist wohl auch besser so. Immerhin kostete der "Spass" dank Sonderaktion (STK-500+Dragon) nur 22 Euro.