Design Tools fuer ATMega, welche?

Programmierhardware: usbasp (Eigenbau), tinyusb (Eigenbau), AVR Dragon. In der Reihenfolge von oft nach selten verwendet.

XL

Am 12.02.2014 20:04, schrieb Joerg:

Notepad++, Cmake, AVR-Toolchain von Atmel, MinGW-make, AVRDude, STK500.

Vielen Dank fuer die zahlreichen informativen Beitraege. Wenn ich mich nicht vertan haben, sieht es so aus, dass AVR Studio in diesem Thread knapp gewonnen hat. Oder mit guter Fuehrungposition, wenn Dragon dazuzaehlt:

AVR Studio : 4 CodeVision AVR : 3 GCC Compiler : 3 AVR Dragon : 2 (setzt aber wohl auf AVR Studio auf) Win AVR Editor : 1

Bei den Programmern liegt offenbar AVR MkII vorn. Ich nehme an, es ist dieser, wo man SPI und JTAG in einem hat:

Das ist doch mal ein Wort. Nochmal vielen Dank.

Joerg schrieb:

Das ist ein von Atmel hergestellter "Programmieradapter" mit USB zum PC.

Der belegt dann wohl nach dem Dragon den zweiten Platz.

Marc

Aha, danke, auch an Eric.

IIUC hatte der Dragon zwei Stimmen, der AVR MkII vier. Aber der Adapter ist nicht so kritisch, solange der nicht diese elende Arduino Methode mit fliegendem Reset Kondensator benutzt. Denn Atmel uC setze ich nicht ein ohne externen POR/BOR/Watchdog, da geht nur der normale externe Pulldown.

Am 13.02.2014 17:05, schrieb Joerg: [...]

sein, ich habe aber mit den Megas nicht viel Erfahrung, da ich fast nur Tiny brauch.

Joerg schrieb:

Marc

Werde ich definitiv machen. Fehlendes Gehaeuse beim Dragon, wie Marc berichtete, ist nicht so schoen, aber bei besserer Eignung kein Hinderungsgrund. Das muessten wir dann nachruesten, weil das ganze auch draussen in der Wildnis eingesetzt wird. Muss Buschpiloten-fest sein :-)

Joerg ( snipped-for-privacy@invalid.invalid):

AVR Studio arbeitet auch mit dem GCC ;-)

Joerg ( snipped-for-privacy@invalid.invalid):

DebugWire und externe Reset-Bausteine, ebenso wie der C von Reset

Debuggen kann man da ja einen Jumper vorsehen. Der Dragon als

AVR JTAG ICE MKIII (USB) AVR AT90 JTAG ICE MKII (RS232) AVR One! (USB)

Deshalb werde ich das vor einer Entscheidung eingehend pruefen, so wie Eric es ja schon schrieb. Ohne externe POR/BOR Chips gibt's von mir kein neues uC Design, ich traue den Dingern dahingehend nicht.

Jumper und alles andere was abfliegen kann, geht in diesem Metier ueberhaupt nicht. U.a. deshalb:

Es wird wohl eher sowas professionelleres. USB ist inzwischen Bedingung, und wenn JTAG plus SPI plus vielleicht sogar Bootloading per RS232/485 moeglich waeren, umso besser. Wobei man fuer letzteres nur einen FTDI Adapter braeuchte (aber ohne DTR an einer Reset Leitung).

auch.

drauf und gut ist.

Am 13.02.2014 18:43, schrieb Thomas 'Tom' Malkus: [...]

ein USB-Kabel anstecken kann.

/ralph

schon sinnvoll sein. Man kann denen aber auch einen ispMKII in die

Ralph Aichinger ( snipped-for-privacy@pangea.at):

Naja, der isp MKII kostet um die 30? Netto. Bei einem Kunden haben alle Monteure einen in der Notebooktasche.

So richtig nicht. Wir machen das lieber am fertigen Exemplar. Sonst sit es muehsam, auch wirklich das ganze Endkonzept zu testen.

Im Feld ist Bootloading sehr sinnvoll. Monteuren gibt man nicht gern einen $xxx Programmer mit, ein $x Pod mit FTDI Chip drin ist da besser.

Wir haben eine Anwendung im Feld, bei dem es gelegentlich ein FW-Update

man einsetzt.

Johannes