Links zu Entwicklungsumgebungen

[Dirk]

Hier mal einige Links zu Entwicklungsumgebungen für die AVR-Mikrocontrollerfamilie.
(Diese Liste wird noch erweitert)


Atmel Studio 7 IDE
Downloads Archive for AVR and SAM MCUs/MPUs

WinAVR
AVR-GCC Compiler für die AVR-Mikrocontrollerfamilie

BascomAVR
Basic-Entwicklungsumgebung für die AVR-Mikrocontrollerfamilie. Hier empfehle ich das Buch AVR Mikrocontroller-Lehrbuch von Roland Walter. Das Lehrbuch ist komplett online verfügbar.

 

[Matthias]

Portierung

Hallo Dirk,

ich steige gerade erst in die Welt der µC-Programmierung ein.
Ich habe mir ein CC-Pro Application Board von der Fa. Conrad mit einer ATMEL32 Controllerunit gekauft. Beides wollte ich mit in meine Anwender-HW verbauen. Jedoch mit dem Conrad-Compiler und deren Entwicklungsumgebung komme ich nicht klar und möchte deshalb auf eine der bewährten Entwicklungsumgebungen AVR Studio4 oder WinAVR umsteigen ohne die HW zu wechseln. Nun stellt sich mir die grundsätzliche Frage nach Kompatibilität, wie kommen die Programme von einer beliebigen Entwicklungsumgebung in die jeweiligen HW-Systeme?

Bin für jede Hilfe dankbar
Matthias

 

[Dirk]

Hallo Matthias,

mit dem C-Control habe ich noch nicht gearbeitet und kann dir hier somit leider nicht weiterhelfen. Es gibt zum C-Control eine Online-Anleitung.

Wenn du AVR Studio nutzen möchtest, könntest du den Mikrocontroller zum Beispiel mit dem Programmierer AVR ISP programmieren. Alternativ kannst du mal im Internet nach "Ponyprog" suchen. So wie ich das aus der Anleitung heraus lesen konnte, nutzt C-Control einen Bootloader, dieser wird benötigt um den Mikrocontroller vom C-Control-System zu flashen. Wenn du zum Beispiel mit AVR ISP programmierst, kann der Bootloader überschrieben werden oder durch Programmierung der Fuse-Bits ausser Funktion gesetzt werden.

Am einfachsten zu programmieren ist über SPI (Signale: MOSI, MISO, SCK, RESET\), die entsprechenden Pins müssen am Board verfügbar sein und dürfen nicht durch angeschlossene Hardware auf dem Board beeinflusst werden.

Ich hoffe, ich konnte dir ein bisschen weiterhelfen.

Grüße,
Dirk

 

[Matthias]

Hallo Dirk,

ich danke dir für die konstruktiven Hinweise und dafür, dass Du umgehend geantwortet hast. Ich habe deine Nachricht erst jetzt gelesen weil ich gestern außer haus war (Obama Rede live erleben) und heute den ganzen Tag in der Bibliothek Bücher über die Grundlagen von Mikrocontrollersystemen studiert habe.

Ich werde mich über's Wochenende mit den Themen AVR ISP, Fuse und den Signalen MOSI, MISO, SCK, RESET\ beschäftigen und dich dann auf dem laufenden halten.

Du hast mir garantiert schon weitergeholfen.
Viele Grüße
Matthias

PS: Euer Forum finde ich gut strukturiert.

 

[Matthias]

Hallo Dirk,

mittlerweile hat mir der Technische Support von Conrad bestätigt, daß definitiv kein Programm in die von Conrad angebotenen ATMEL-µC-units eingespielt werden kann sofern es nicht auf der Conrad-Entwicklungsumgebung erstellt und von dieser übertragen wird. In einer der mails heißt es wörtlich: "...

Original Herstellerbezeichnungen werden von uns nicht hinterlegt.
Die C-Control Mega 32 beruht auf dem AtMega 32 von Atmel.

Der Chip wird mit zusätzlichen Komponenten bestückt und mit einer Firmware versehen.
Somit entspricht Sie nicht mehr dem reinen Atmel Chip und kann deswegen auch nicht mit den Atmel Tools programmiert werden..."

Da Conrad seine Lösung als Industriestandard im sowohl im Verkaufskatalog als auch in der Hilfedatei vermarktet, ist diese Aussage besonders ärgerlich. Ich werde die gesamte HW zu Conrad zurückbringen.

Nun stehe ich vor der Frage, auf welches application board, development board inklusive Mikrocontroller und welche Entwicklungsumgebung ich setzen soll. Mein embedded system später soll zunächst nur einfache bis durchschnittliche Anforderungen erfüllen, insbesondere die gleichzeitige Pulserfassung von drei Inkrementalgebern sowie ein einfaches LCD- und Eingabepad unterstützten. Könntest du mir hierfür bitte was raten?

Viele Grüße
Matthias

 

[Dirk]

Hallo Matthias,

Nun stehe ich vor der Frage, auf welches application board, development board inklusive Mikrocontroller und welche Entwicklungsumgebung ich setzen soll. Mein embedded system später soll zunächst nur einfache bis durchschnittliche Anforderungen erfüllen, insbesondere die gleichzeitige Pulserfassung von drei Inkrementalgebern sowie ein einfaches LCD- und Eingabepad unterstützten. Könntest du mir hierfür bitte was raten?

wenn du in Assembler oder C programmieren möchtest, nutze AVR-Studio in Verbindung mit WinAVR C-Compiler, beides ist kostenlos. Möchtest du in einer Art Basic programmieren, empfehle ich dir BascomAVR, in unserem Forum gibt es zu BascomAVR viele gute Beispiele (dank Markus und Knickohr!).

Developmentboards gibt´s unterschiedliche mit mehr oder weniger Ausstattung, die dann auch mehr oder weniger konfigurierbar/flexibel sind. (Conrad, Reichelt, myAVR, Atmel...) Ich kenne mich selber nur mit den Atmel-Developmentboards aus. Für die AVR-Familie setze ich das STK600 ein, was allerdings schon recht viel kostet. Die Vorgängerversion ist das STK500 von Atmel, was sehr gerne in Verbindung mit dem Expansion-Modul STK501 für 64-pin AVRs, wie zum Beispiele dem ATmega128, verwendet wird. STK500 besitzt DIP-Sockel für alle 8-, 20-, 28- und 40-poligen AVR Mikrocontroller. (Weiter Infos erhältst du u.a. von der Atmel-Website oder in unserem Shop). STK500 und STK600 besitzen für die Schnittstelle zu deiner Applikation 10polige Stiftleisten, an denen jeweils ein Port des Mikrocontrollers angeschlossen ist. On-board sind Kurzhubtasten und LEDs, diese lassen sich jeweils über Flachbandkabelverbindungen auf einen Port legen.

Je Inkrementalgeber benötigst du zum Beispiel einen externen Interrupt, das ist dann Mikrocontroller-abhängig, weniger abhängig vom Board. Ein alphanumerisches LCD benötigt i.d.R 7 Pins (RW, CS, RS, D0...D3), da reicht also ein Port.

Ich hoffe, ich konnte dir etwas weiterhelfen.

Grüße,
Dirk

 

[Matthias]

Hallo Dirk,

Ich möchte von Anfang an mit möglichst standardisierten Tools arbeiten und lernen.

Die Überlegung ob STK500 plus Extension für zusammen ca 150,-€ oder das STK600 für 209,-€ zu nehmen, sei jetzt mal dahingestellt. Vielmehr rätsel ich an der grundsätzlichen Frage warum man in der µC-Programmierung nicht gleich von der SW-Entwicklungsumgebung, zB AVR Studio, direkt im embedded system programmieren tut sondern über ein Developmentboard das macht?

Was ist der Vorteil eines Developmentboards?
Wahrscheinlich eine echt Laienfrage.

Viele Grüße
Matthias

 

[pcprofi]

Nun - es ist ja beides möglich.

Letzenendes ist das Programmieren im Dev-Board ja auch embedded. Die Development-Boards sind ja dafür gedacht, eine (wie der Name ja sagt) Entwicklungsumgebung zu schaffen. Wenn du ein Gerät baust und direkt auf eine Platine bastelst (ohne einzelne Module beispielsweise) wirst du dich wundern, wie viele Sachen du erstmal übersehen oder vergessen oder als Anfänger schlichtweg nicht gewusst hast.
Hier merkt man dann (mal so btw erwähnt) immer, wie gut man ein Projekt geplant hat...

Deswegen wird dir auch hier immer wieder auffallen, dass auch hier die "Profis" viele ihrer Schaltungen erstmal auf Lochraster-Platinen klöppeln, eben um solche Fehler auszubessern.

Den reinen Programmer für einen Atmel-µC kann man schon für 3-4€ realisieren - aber gerade einem Anfänger kann genau das zum Verhängnis werden, denn auch wenn man es oft hört, ganz so einfach sind die Dinger (µC) dann doch nicht, man muss einiges beachten. Nur ein Beispiel: Entstörung bei Interrupts o.ä. - da ist ausprobiererei gefragt, und die geht auf einer geätzten Schaltung nicht venünftig...

Ich hoffe jetzt mal, dass ich nicht ganz am Thema vorbeigeschrieben habe - bin was im Stress und habs nur überflogen...

Gruß Rainer

 

[Dirk]

Hallo Matthias,

... Vielmehr rätsel ich an der grundsätzlichen Frage warum man in der µC-Programmierung nicht gleich von der SW-Entwicklungsumgebung, zB AVR Studio, direkt im embedded system programmieren tut sondern über ein Developmentboard das macht?

Was ist der Vorteil eines Developmentboards?...

hat man einfachere Projekte, die überschaubar sind, bietet es sich an, direkt ohne ein Developmentboard seine Applikation zu erstellen. Also sofort mit Schaltplan, Layout und Platine oder mit Lochrasterplatine beginnen und dann die Software auf dem fertigen System entwickeln und testen.

Handelt es sich um ein komplexeres Projekt, ist es besser bestimmte einzelne Funktionsmodule oder wenn möglich alle Module auf einem Developmentboard zu entwickeln und zu testen.

Nutzt man öfters Mikrocontroller mit Gehäuse SO, TQFP, QFN oder BGA, fällt die Lochraster-Lösung weg, diese eignet sich nur für DIP. Für Developmentboards gibt es oft ZIF-Adapter für die Gehäuse (zum Beispiel bei STK500 und STK600 Developmentboards).

Um die Software auf das Zielsystem zu bekommen, benötigt man einen Programmer, dieser ist oft auf dem Developmentboard integriert.

Zwei Nachteile für ein Developmentboard gegenüber der der Entwicklung eines fertigen Zielsystems fallen mir ein:

1. Bei Anwendungen mit höheren Frequenzen/Übertragungsraten, kann es vorkommen, dass die Qualität der Signale nicht ausreichend gut genug ist (zum Beispiel USB und zu lange Leitungen).
2. Eine Betrachtung der EMV-Eigenschaften mit Developmentboard ist nicht sinnvoll oder nur eingeschränkt sinnvoll.

ok, noch ein dritter Punkt: die Investition Stellt man aber die Kosten eines Developmentboards den Kosten von vielleicht 3 Prototypplatinen gegenüber, bei denen man vielleicht noch was ändern muss, dann ist das Developmentboard schon raus.

Grüsse,
Dirk

 

[spider2le]

problem mit avrdude !?

ich arbeite seit kurzem mit einem atmega 8.

versuche ihn per avrdude über das programmierkabel ISP zu programmieren (schaltung im anhang)
mit folgendem aufruf:
avrdude -p -atmega8 -P lpt1 -c dapa -U flash:w:main.hex

erhalte ich immerwieder die Meldung:
avrdude: can't open device "giveio"
und
avrdude: failt to open parallel port "lpt1"

hardware funktioniert einwandfrei. ponyprog2000 und bascom funktionieren.
woran kanns liegen?

 

[Knickohr]

Hallo,

mach mal einen 100pf (Pico, nicht Nano) Konndensator zwischen SCK und GND. Steht auch so in der BASCOM-Hilfe beschrieben :

I have been having spurious success with the simple cable programmer from Sample Electronics for the AVR series.

After resorting to hooking up the CRO I have figured it out (I think). When trying to identify the chip, no response on the MISO pin indicates that the Programming Enable command has not been correctly received by the target.

The SCK line Mark/Space times were okay but it looked a bit sad with a slow rise time but a rapid fall time. So I initially tried to improve the rise time with a pull-up. No change ie still could not identify chip. I was about to add some buffers when I came across an Atmel app note for their serial programmer "During this first phase of the programming cycle, keeping the SCK line free from pulses is critical, as pulses will cause the target AVR to loose synchronization with the programmer. When synchronization is lost, the only means of regaining synchronization is to release the RESET line for more than 100ms."

I have added a 100pF cap from SCK to GND and works first time every time now. The SCK rise time is still sad but there must have been enough noise to corrupt the initial command despite using a 600mm shielded cable.

Thomas

 

[Flex]

Hat jemand den Link für das Atmel Studio 6.0 Beta Installer - Full?

 

[LotadaC]

Link schmeiß

 

[Flex]

Seit wann muss man schich bei Atmel anmelden? Die wollen ja die komplette Anschrift haben. Wird da meine Adresse weiter gegeben oder bekomme ich Werbung?

Gruß
Flex

 

[LotadaC]

War AFAIK schon immer so...