Hey Ho mal wieder von mir. Mein letztes Projekt "LED's-(RGB)-Ansteuerung mittels C8051" hab ich im kleinen Laboraufbau fertiggestellt. Nachdem ich jede einzelne Farbe und resultierende Mischfarbe darstellen kann und diese in einer Blink-, Lauflicht-Funktion ebenfalls ausführbar sind wollte ich nun zum Feintuning übergehen. Dies besteht darin, dass ich die darstellbaren Mischfarben durch gezieltes Ansteuern per PWM erweitern möchte. Also durch gezieltes dimmen bzw. ausleuchten sanftere Übergänge und mehr darstellbare Farben erzeugen. Für diesen Zweck hab ich mir nun überlegt vom älteren C8051 auf eine neuere Entwicklungsumgebung zu gehen. Zum ANLIEGEN: Hab mir nun drei verschiedene Boards in die engere Wahl genommen und würde gerne eure Meinung bzw. harte Infos bezüglich Für/Wider als Feedback bekommen. a.) AT32UC3C-EK b.) Atmel AVR STK600 c.) EVK1100 Was ich noch nicht so ganz verstehe ist, wenn ich ein Entwicklungsboard habe und auf dem meine gewünschten Datenverarbeitungen laufen, wie bekomme ich die dann auf einen Einzelnen µC, den ich dann in einen direkt selbst angefertigten Aufbau intergriere? Die Boards haben ja einen fest eingebauten Chip und kein Wechselhalter. Gleiche Problem hatte ich auch bei meinem C8051-DK Board von SiLabs. Ich möchte nur ungern ein komplettes DK-/EK Board i-wo verbauen. Vielen Dank im Voraus für eure Beiträge ;-)
:
Bearbeitet durch User
Marcel M. schrieb: > wie > bekomme ich die dann auf einen Einzelnen µC In deiner Schaltung führst du die Pins vom µC, die für ISP oder JTAG sind, auf Headerleisten. Dann nimmst du dir einen Programmer, z.B. das AVR-Dragon-Board, verbindest beides und bügelst so deinen Code auf den µC. PC --> AVR-Dragon --> µC Nur eine von mehreren Möglichkeiten. Grüße
Ah, ok. Demnach könnt ich doch dann auch gleich mit Kablen vom EK-Board abgehen und den jungfräulichen µC direkt damit verbinden. Heißt, wenn ich dem EK-Board das draufspiele, wird just in Time auch der einzelne Chip beschrieben. Richtig oder, nix da weil geht so nicht? Welches Board (von den dreien) würdet ihr denn bevorzugen??? Hatte ne Zeit lang auch das MK2-Plus in Augenschein genommen. Dies ist aber noch auf 8-Bit und nicht wie die anderen mit neuerem 32-Bit.
Ich kann nur sagen, wie das bei den 8Bit-Systemen ist, aber bei 32Bit sollte das ähnlich sein. Bei ISP ist das so, dass sich der zu beschreibende uC in einer Schaltung befinden muss (heißt ja nicht umsonst InSystemProgramming). Der uC muss also schon eine Spannungsversorgung haben (jedenfalls bei meinem MK2-Programmer). Du brauchst also eigentlich kein Board, sondern ein Programmer, wenn du die uC-Schaltung eh komplett selbst bauen willst. Das STK600 beispielsweise ist zwar ein Board, wird aber in dem Fall als Programmer genutzt. Das heisst, du wählst in deiner Entwicklungsumgebung den Zielprozessor aus, schreibst für diesen dein Programm und wählst als Programmiergerät das STK600 aus. Das musst du dann nur noch per ISP mit deiner Schaltung verbinden und die IDE lädt das Hex-File über den Programmer auf deinen uC. Ergo: Wenn du deine uC-Schaltungen komplett aufbaust und auf die Vorzüge eines Boards (beispielsweise zum Testen, ohne eine komplette Schaltung aufbauen zu müssen) verzichten kannst, brauchst du nur ein Programmer und kein Board)...
Danke schön. Also bei meinem letzten Projekt habe ich ein Development-Kit von SiLabs benutzt. Auf diesem Board waren zu 4+4 - I/O-Ports, ADC/DAC, Tempsensor, extern Speicher sowie Oszillator usw. mit drauf. Nun habe ich mir eine kleine Platine genommen verschiedenfarbige LED's samt Vorwiderstände und externer 12V Spannungsversorgung (eigenes Netzteil von 230V) drauf gebaut und mit kleinen Darlington-Transistoren verbunden (Masse-durchschleifend). Mittels 4 Flachbandkabeln habe ich das DK mit meinem Laboraufbau verbunden und Leuchtszenarien programmiert. Der Laboraufbau ist aber eigentlich ein Kleinmaßstab zu meiner Kfz-Kofferraumbeleuchtung. Um diese nun per µC anzusteuern brauch ich ja nur den µC in die schon vorhandene Schaltung integrieren und mit dem Programm zu bespielen. Würde ich jetzt das DK dort einfach zwischen hängen hätte ich ja nur die Digitalports in Benutzung und der Rest der Möglichkeiten ungenutzt. Problem ist also, ich habe zu meist kleine Projekte im Kopf (step by Step), die während der Programmierphase eher bescheiden am Ort durchzuführen sind und würde die eben gerne am Schreibtisch erarbeiten und testen. Wenn die Programme so laufen wie ich es mir vorgestellt habe, möchte ich anschließend ein µC beschreiben und in eine zu meist vorhandene Schaltung intergrieren. Anschließend kann ich mit dem Komplett-Board wieder neue Sachen erlernen und ausprobieren. - DAS war so mein Gedanke, also eine mehr oder minder komplette Entwicklungsumgebung zum Probieren und Testen am Tisch im kleinen und wenn die Programme stimmig sind jungfreuliche µC's beschreiben und in ein "Groß"-Projekt (Schaltung) integrieren. Gibt es eine kleine Platine mit aufgebrachten Wechselhalter, die ich dann mit einem leeren µC bestücke und diesen dann ans EK/DK-Board hänge um es dort drauf zu spielen??? Sorry für soviel Geschwafel, aber das wären meine Gedanken und deswegen viel die Wahl vorerst auf einer der Drei: a.) AT32UC3C-EK b.) Atmel AVR STK600 c.) EVK1100 Das MK2 hatte ich auch schon intensiver in Auge gefasst, da dies auch als Paket mit Handbüchern gibt. Jedoch weiß ich nicht so ganz ob ich bei 8-Bit bleibe oder doch eher auf 32-Bit umsteige mit dem fernen Ziel zur Bedienung von Touch-Slidern (per Finger ziehen Lautstärke regulieren etc.)
Wie das beim STK600 läuft weiss ich nicht. Das STK500 hatte freie Sockel für alle möglichen AVRs in DIP-Gehäusen, in die man dann seinen uC einstecken konnte. Ich habe mit einem einem selbst gebauten Board und MK2 angefangen. Wenn man erst einmal bei 8Bit bleibt kann man als Testboard auch gut einen Arduino nehmen. Das gibt es auch mit Mega328P DIL-uC, den du austauschen kannst. Theoretisch prauchst du dann nicht mal einen Programmer, weil der uC einen Bootloader drauf hat und du die Hex-Datei direkt über den USB-Anschluss aufspielen kannst. Setzt aber voraus, dass alle uCs, die du benutzt, eben schon den Bootloader drauf haben. Da ist ein ISP-Programmer deutlich komfortabler... Wenn du nicht sicher bist, ob du später 32Bit nehmen willst, besorg dir statt MK2 nen AVR-Dragon. Der ist für seine Ausstattung echt günstig und kann dann nicht nur ISP sondern auch JTAG, HV und Debugging und unterstützt auch 32Bit-uCs. Ist aber ein bisschen empfindlich gegenüber Überspannung...
Jo vielen Dank. Nach deiner Aussage zum STK500 habe ich mich noch mal bei gemacht und im Bereich "Artikel" Einzelheiten zum STK600 eingeholt die ich auf der Atmel Seite nicht so einsehen konnte. Die Entscheidung ist nun gefallen, es wird das STK600! Denn mit den Erweiterungs-Sockel-Boards sind die 8-Bit als auch die 32-Bit µC programmierbar und ich kann somit ein leeren µC einfach wechseln. Danke!
Vision schrieb: > Wie das beim STK600 läuft weiss ich nicht. Das STK500 hatte freie Sockel > für alle möglichen AVRs in DIP-Gehäusen, in die man dann seinen uC > einstecken konnte. Das STK600 ist eine verbesserter Vesion des STK500, unter aderen z.B. direkte anschluss an PC über USB, CAN on Board, Zif Sockel für µC in DIP Gehäuse usw. es ist ein Entwicklungsboard und Programmiertgerät. Nachteil ist natürlich der Preis. Wenn du µC in DIP Gehäuse programmieren willst muss du dazu das DIP-Package kaufen.
Im Prinzip kommt man auch ohne DevKits oder EvalKits aus. Einfach den µC der Wahl kaufen, auf ein Steckbrett packen und ein bisschen Testhardware (Buttons. LEDs, etc) drum herum garnieren. Was man auf jeden Fall braucht ist irgendeine Art Programmieradapter. Die Lösungen sind hier vielfältig. Von proprietären ISP-Lösungen (AVR ISP, PDI, TPI) über proprietäre Lösungen mit vielen Pins wo man das Target also am besten in eine Programmierfassung steckt hin zu halb- oder gar nicht proprietärem JTAG. DK/EK bringen einen solchen Adapter typischerweise mit. Und oft kann man den dann auch extern nutzen. Also eine eigene Platine per Kabel zum programmieren/debuggen anschließen. Viele DK/EK sind mit Hardware zugepflastert, weil sie eher als Marketinginstrument denn als Entwicklerprodukt angesehen werden. Diese Teile empfinde ich als Verschwendung. Andererseits gibt es auch viele kleine Platinen, die nur den µC, Takt- und Reset-Versorgung und evtl. den Programmer enthalten. Z.B. die LPCXpresso von NXP. Das ist dann im Prinzip ein Breakout-Board für den Controller (den man so trotz LQFP Gehäuse aufs Steckbrett bringt) und abtrennbar ein JTAG Programmer/Debugger. So ist das sinnvoll. Den Programmieradapter braucht man ja pro Zielplattform nur einmal. Und dann ist es nett, wenn das ein Platinchen in Briefmarkengröße ist und kein Trum wie das STK500. XL
Ähm...häää ;-) Also zum STK600 hab ich mir zzgl noch das SC03 ausgesucht. Wenn ich jetzt richtig bin sollte das ein Wechselhalter für die TQFP 100Pin Chips sein. Auf diesen lässt sich demnach auch der auf dem STK600er befindlcihen ATmega2560 (8-Bit) draufpacken, als auch ein AT32UC3 (32-Bit). Damit könnte ich ja in (-Bit weiterhin arbeiten und in ferner Zukunft auch auf 32-Bit wechseln ohne die Entwicklungsumgebung tauchen zu müssen. Ergo: STK600 + STK600-SC03 wird es wohl werden. Bei den anderen zur Wahl stehenden wären zwar noch Display bzw Touch-Sensor mit bei gewesen, aber die sollte ich nachträglich ja auch noch an das STK600 verbinden können :-D
Marcel M. schrieb: > Auf diesen lässt sich demnach auch der auf dem STK600er > befindlcihen ATmega2560 Der Atmega2560 dass, mit dem STK600 kommt lässt sich ohne weiteres am STK600 Programmieren, die "Kits" für DIP oder TQFP ist für µC in DIP oder TQFP Gehäuse.
Marcel M. schrieb: > Auf diesen lässt sich demnach auch der auf dem STK600er befindlcihen > ATmega2560 (8-Bit) draufpacken Nein. Der bereits im Kit befindliche STK600 weicht von der normalerweise beim STK600 benutzten Konfiguration (ein "routing board", obendrauf ein "socket board") dahingehend ab, dass er als preiswerte Version ohne Fassung direkt mit dem Board auf den STK600 montiert werden kann. Der Chip ist da bereits aufgelötet. Das ist gewissermaßen die "Starthilfe", damit du mit dem reinen (ja nicht ganz billigen) STK600 direkt loslegen kannst, egal, welchen Satz von Fassungen und Adapterkarten du dann endgültig nehmen willst.
Sorry, ich denke ich hab mich nicht ganz verständlich ausgedrückt. Das auf dem STK600 ein ATmega2560 schon fest-vorinstalliert ist war mir bewusst. Dass ich an diesem Programme schreiben und mit den vorhandenen Tastern und LED's testen kann auch. Ich habe nun für mich ein Programm fertig und will das, so wie es ist (also auch zugehörig zum Atmega2560) in meiner "Groß"-Anwendung intergrieren. Dann würde ich z.B. gleich einen weiteren ATmega2560 auf das Socket-Board stecken, dieses mit dem STK600 verbinden und dann das Programm überspielen. Also ich habe nicht vorgehabt den vorhanden auszulöten und in das Socket-Board zu stecken. Frage: Da hier gerade von SC's und RC's geschrieben wird. Hier im Bereich Artikel steht nur das STK600-TQFP100. Dieses wollte ich nun ja dazu beziehen, jedoch gibt es das so als Kit nicht mehr. Ich möge mir bitte ein RC und/oder SC aussuchen. Was ist denn da nun was??? - das Socket-board ist demnach nur der µC-Halter(schwarzer Chip-Aufnehmer) - das Routing-board ist dann demnach die grüne Platine auf der die einzelnen Leiterbahnen entsprechend für die Kontaktierung des STK600 (dessen Kontaktplätzen) und dem gewünschten Socket-Board (in meinem Fall in TQFP100-Bauweise) platziert/angefertigt sind Richtig??? Wenn ja, kann ich davon ausgehen dass zum SC03 (sollte das TQFP100 sein) auch ein RC03??? Ich habe folgende RC's zur Auswahl bekommen "RC06, RC02, RC12, RC05, RC17, RC09", doch leider kann ich die nicht finden. Andersherum. War denn das STK600-TQFP100 ein voll KIT mit allen Routing-Cards und einer TQFP100-Socket-Card??? Denn im Artikel sind dazu recht viele µC's als unterstützt angegeben und bei Atmel sind die nun immer nur für ein einzigen. Ist dem so richtig??? Danke
Marcel M. schrieb: > - das Socket-board ist demnach nur der µC-Halter(schwarzer > Chip-Aufnehmer) > - das Routing-board ist dann demnach die grüne Platine auf der die > einzelnen Leiterbahnen entsprechend für die Kontaktierung des STK600 > (dessen Kontaktplätzen) und dem gewünschten Socket-Board (in meinem Fall > in TQFP100-Bauweise) platziert/angefertigt sind Ja. > Wenn ja, kann ich davon ausgehen dass zum SC03 (sollte das TQFP100 sein) > auch ein RC03??? Nein, die RCs heißen anders. Hier ist die Liste der RCs, wie ich sie mal ins AVRDUDE eingepflegt habe (dienen dort nur der Statusanzeige):
1 | static const struct carddata routing_cards[] = |
2 | {
|
3 | { 0x01, "STK600-RC020T-1" }, |
4 | { 0x03, "STK600-RC028T-3" }, |
5 | { 0x05, "STK600-RC040M-5" }, |
6 | { 0x08, "STK600-RC020T-8" }, |
7 | { 0x0A, "STK600-RC040M-4" }, |
8 | { 0x0C, "STK600-RC008T-2" }, |
9 | { 0x0D, "STK600-RC028M-6" }, |
10 | { 0x10, "STK600-RC064M-10" }, |
11 | { 0x11, "STK600-RC100M-11" }, |
12 | { 0x13, "STK600-RC100X-13" }, |
13 | { 0x15, "STK600-RC044X-15" }, |
14 | { 0x18, "STK600-RC100M-18" }, |
15 | { 0x19, "STK600-RCPWM-19" }, |
16 | { 0x1A, "STK600-RC064X-14" }, |
17 | { 0x1B, "STK600-RC032U-20" }, |
18 | { 0x1C, "STK600-RC014T-12" }, |
19 | { 0x1E, "STK600-RC064U-17" }, |
20 | { 0x1F, "STK600-RCuC3B0-21" }, |
21 | { 0x20, "STK600-RCPWM-22" }, |
22 | { 0x21, "STK600-RC020T-23" }, |
23 | { 0x22, "STK600-RC044M-24" }, |
24 | { 0x23, "STK600-RC044U-25" }, |
25 | { 0x24, "STK600-RCPWM-26" }, |
26 | { 0x25, "STK600-RCuC3B48-27" }, |
27 | { 0x27, "STK600-RC032M-29" }, |
28 | { 0x28, "STK600-RC044M-30" }, |
29 | { 0x29, "STK600-RC044M-31" }, |
30 | { 0x2A, "STK600-RC014T-42" }, |
31 | { 0x2B, "STK600-RC020T-43" }, |
32 | { 0x30, "STK600-RCUC3A144-32" }, |
33 | { 0x34, "STK600-RCUC3L0-34" }, |
34 | { 0x38, "STK600-RCUC3C0-36" }, |
35 | { 0x3B, "STK600-RCUC3C0-37" }, |
36 | { 0x3E, "STK600-RCUC3A144-33" }, |
37 | { 0x46, "STK600-RCuC3A100-28" }, |
38 | { 0x55, "STK600-RC064M-9" }, |
39 | { 0x88, "STK600-RCUC3C1-38" }, |
40 | { 0x8B, "STK600-RCUC3C1-39" }, |
41 | { 0xA0, "STK600-RC008T-7" }, |
42 | { 0xB8, "STK600-RCUC3C2-40" }, |
43 | { 0xBB, "STK600-RCUC3C2-41" }, |
44 | };
|
Das war mal aus den XML-Dateien extrahiert, noch zu AVR-Studio-4-Zeiten. Könnten also inzwischen weitere hinzu gekommen sein. Für den ATmega2560 brauchst du die "STK600-RC100M-11" (habe ich mir zumindest auf meine drauf geschrieben ;-). > Andersherum. War denn das STK600-TQFP100 ein voll KIT mit allen > Routing-Cards und einer TQFP100-Socket-Card? Ja, so war es. Wie das jetzt verkauft wird, hab' ich keine Ahnung.
Alles klar. So langsam wird es ja doch mit mir :-D ...Dank an euch! Werd wohl demnach das: - SC03 - RC100M-11 (auch für einen ATmega2560) - RC100M-18 (für weitere mega-Baureihen) - RC100X-13 (vllt. Probe mit der xmega-Baureihe) - RCuC3C1-38 (für die besseren/letzten 100-Pin 32-Bits Chip) nehmen, also zzgl. zum STK600 ;-)
Marcel M. schrieb: > - RC100M-18 (für weitere mega-Baureihen) Brauchste nicht. Das ist für die ATmega6490 und so. Ziemliche Exoten heutzutage.
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.