Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » Elektronik-Entwicklungen von PS » Themenansicht

Autor

Thread - Seiten: -1-

000
10.05.2013, 11:04 Uhr
P.S.

Mir ist bekannt, dass sich der eine oder andere von Euch auch mit anderen Dingen beschäftigt, als mit historischer ROBOTRON-Technik.
Gerade in den letzten Jahren habe ich einige µC-Entwicklungen auf den Weg gebracht, die Euch vielleicht auch interessieren könnten. Da für die Weiterführung der Entwicklung hemmende Meinungsverschiedenheiten bestehen, wäre ich sehr an Eurer Meinung interessiert, ob es heutzutage noch zeitgemäß und sinnvoll ist, sich mit µC der Serie ATMega zu beschäftigen, oder nur noch auf RasperiPi und solches Zeug zu setzen ist.

Bei meinen Arbeiten mit dem AVR128 empfand ich die umständlichen Randbedingungen der gängigen AVR-IDE immer sehr hinderlich. Die Programmentwicklung mit dem AVR-Studio ist zwar ok, aber wenn externe Hardware einbezogen werden muß, hilft der Simulator wenig. Für das "Einschießen" des Programms in den µC wird ein externer Hardware-Adapter (ISP) benötigt. Soll das Debugging incl. externer Hardware erfolgen, besteht die Möglichkeit, dies über die sog. JTAG-Schnittstelle zu tun. Dazu ist ein anderer Hardware-Adapter (JTAG) notwendig. Letztendlich hat man einen Haufen Kisten und Kabel auf dem Tisch und ist laufend am Umstecken usw.

Das hat mir nicht gefallen und deshalb habe ich mir ein universelles Development-Board für den AVR128 einfallen lassen. Hier die Bilder vom Prototyp:
(1) BasisBoard http://www.ps-blnkd.de/Bilder/AVR128-BasisBoard.jpg und
(2) InterfaceBoard http://www.ps-blnkd.de/Bilder/InterfaceBoard.jpg, sowie die fertige Kombination mit LCD:
http://www.ps-blnkd.de/Bilder/Kombination-Basis_Interface_LCD.jpg
Wie aus der Kurzbeschreibung http://www.ps-blnkd.de/AVR_Development_System.pdf ersichtlich, handelt sich um eine "eierlegende Wollmilchsau", die keinerlei externe Hardware-Adapter mehr benötigt. Weitere Modifikationsvarianten sind auch nicht ausgeschlossen, so z.B. zur XMega-Serie.

Über eine weitere Entwicklung aus meiner Berufstätigkeit möchte ich noch informieren. Trotz aller HighTech-Integration sind manchmal Induktivitäten oder Trafos unumgänglich. Nicht immer kann man auf fertige Industrieprodukte zurückgreifen und Spulenwickeln ist auch nicht jedermanns Sache. Dazu gibt es jetzt "Planarspulen - ein Baukastensystem für Induktivitäten und Trafos": http://www.ps-blnkd.de/Planarspulen-1.pdf.

Bin sehr gespannt auf Eure Statements!

Das Wissen der Menschheit gehört allen Menschen! -
Wissen ist Macht, wer glaubt, der weiß nichts! -
Unwissenheit schützt vor Strafe nicht! -
Gegen die Ausgrenzung von Unwissenden und für ein liberalisiertes Urheber- und Markenrecht!
PS

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
10.05.2013, 18:04 Uhr
u.nickel

Denke schon das es sowohl zeitgemäß, als auch sinnvoll ist sich heutzutage mit "Standard-µC" zu beschäftigen. Die momentan üblichen, hypemäßigen Perversitäten zum Blinken einer LED ein Mini-Linux als Grundlage einer "höheren" Programmiersprache benutzen zu müssen, werden sich auch schnell mal wieder erledigt haben!
Wohlgemerkt: Ich hab auch nen Pi, mich sowohl unter eigenen basteltechnischen, als auch unter pädagogisch-methodischen Gesichtspunkten damit auseinandergesetzt- also bzgl Verbindung Hardwarebastelei und Programmierung - und mein Statement ist genau das Fazit dieser Auseinandersetzung.
Dei Entwicklungsboard sieht gut aus. Was kostet sowas?

Gruß Uwe

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
10.05.2013, 18:43 Uhr
Micha

Avatar von Micha

Atmel Microcontroller auf der einen Seite, Raspberry Pi auf der anderen Seite sind zwei völlig unterschiedliche Paar Schuhe. Das ist wie Äpfel und Birnen vergleichen. Mit dem einen System kann man von der Pike auf programmieren, Schaltungen ausprobieren, etwas selber entwickeln. Mit dem anderen Ding kann man auf einer komplexeren Ebene experimentieren, z.B. ein Mediacenter zusammenbasteln.

Ehrlich gesagt sehe ich für mich keine Anwendung für Dein "universelles Development Board". Wenn ich was mit Atmels probieren will stöpsel ich die in ein Breadboard, steck dann eben die Pins des Programmierers mit drauf. Mir fällt da grade nur auf Amerikanisch ein: "So What?" - was brauch ich dann noch mehr?

Die meiste Zeit geht sowieso beim Nachdenken und Probieren bezüglich der eigenen Konzepte drauf. Bitte nich krumm nehmen, aber ich sehe aus meiner Sicht keinen Nutzen für ein Atmel-Dev-Board das als eierlegende Wollmilchsau fungiert. Bastler sind immer auch Improvisierer.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
10.05.2013, 19:26 Uhr
drohne235

Na klar ist es sinnvoll, sich noch mit den "normalen" µC's auseinanderzusetzen!

Und da gibt es viele Gesichtspunkte, die für die Einfachheit dieser Technik sprechen:

o Kontrollverlust: Bei den Atmel wirst du bald jedes Bit und Byte kennen, was bei den komplexen Systemen mit tonnenschwerer Software zwischen den Pins und dem User um Größenordnungen schwieriger ist.

o Wenn es Echtzeit sein soll, geht da eh nix bei solchen Sachen wie dem Pi. Oftmals wird dann eh noch ein µC auf den Pi geschnallt, der das dann macht.

o Wenn der Chip defekt ist, kannst du bei DIP-Gehäuse einfach einen neuen in die Fassung stecken, bei den SMD's stehen die Chancen auch sehr gut das selbst mit dem Lötkolben wieder zu richten. Versuch das mal bei einem BGA.

o Wenn man lernen will, dann fängt man einfach an und lässt eine LED nicht durch Megabytes an Bibliotheken in irgendeiner Scriptsprache blinken - wie u.nickel das schon geschrieben hat. Wo ist da der Lerneffekt?

Ich persönlich habe mich momentan auf die Controller von Parallax eingeschossen und verzichte da ganz bewußt sogar auf SMD, aber das spielt letztlich in der gleichen Liga. Der Trugschluss besteht in meinen Augen darin zu denke, das komplexere und (scheinbar) komfortablere Systeme auch besser sind, sind sie aber in den meisten Fällen nicht!

Und schauen dir einfach mal an, was es alles für tolle und smarte kleine Erweiterungen mit µC's für die vielen Retrocomputer gibt: Disketten- und Floppyemulatoren um beispielsweise Diskettenimages direkt von SD-Card zu nutzen, neue Schnittstellen usw.

Und hey, wenn man unbedingt seine LED per Steuerung von einer Webseite blinken lassen will (was ja momentan besonders hip zu sein scheint), dann kann man das auch mit einem winzigen Bruchteil der Ressourcen mit einem µC.

--
"Ob Sie denken, dass Sie es können, oder ob Sie denken, dass Sie es nicht können - in beiden Fällen haben Sie recht." Henry Ford

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
10.05.2013, 20:16 Uhr
holm

Avatar von holm

Atmels sind auf 'Grund des DIP Gehäuses der einfacheren CPUs easy zu handhaben, das geht auf einem Steckboard oder auch Lochraster mit CUL Draht.
Ich habe ein STK500 herumliegen, das ich deshalb noch nie benutzt habe, außerdem noch einen Dragon. Beide können über ISP "bare Metal" programmieren, der Dragon beherrscht außerdem das Programmieren und Debuggen über Debugwire und JTAG. Ich habe auch ein JTAG ICE MkII das ISP,JTAG und PDI (ATXmega) unterstützt.

Anders sieht die Sache bei ARMs aus, die kann man nicht so einfach auf Lochraster bügeln, deswegen habe ich da STM32F4-Disovery oder Stellaris Board von TI um dieses Zeug zu erschlagen, beide beinhalten die notwendigen Programmer. Für MSP430 habe ich einen parallel-Port Programmer.

Das Einzige das ich nicht benötige ist eine eierlegende Wollmilchsau, denn die aus der Entwicklung resultierende Anwendung ist entweder ein Eimalding für mich selber (2708 Brenner und27C291/Cy7C291 Brenner, evtl. 1702 oder auch LBL) und wird auf Lochraster gebastelt weil sich eine Platine nicht lohnt, oder geht in Serie und ist damit recht speziell (kleinster Sinnvoller Prozessor, keine unnötige Peripherie, Platine evtl. auch nicht rechteckig oder so..)
öfter macht auch Jemand ganz Anderes die Hardware.. da brauche ich Sowas auch nicht...

Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 10.05.2013 um 20:16 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
12.05.2013, 08:26 Uhr
P.S.

Danke Euch allen für die aufmunternden Worte.

@u.nickel
Die Boards sind noch im Prototypen-Stadium, deshalb undiskutabel teuer. Ziel sollte es aber sein mit dem Basisboard unter 50 Euro und mit dem Interfaceboard nicht auf viel mehr als 100 Euro zu kommen. Dazu sind allerdings wenigstens 100er Stückzahlen notwendig und das bedeutet dann mit mehreren 1000 Euro in Vorleistung zu gehen.

@Micha
Das dabei eine "eierlegende Wollmilchsau" herausgekommen ist, liegt daran, dass das System möglichst universell für alle möglichen Zwecke einsetzbar sein sollte - u.a. auch für programmierbare Steuerungen und als Hardware-Grundlage meines AVRLab, was ich Euch demnächst noch vorstellen werde. Natürlich kann man auch einen adaptierten ATmega128 auf ein Steckbrett setzen und alle mögliche Peripherie darum bauen, aber mit dem dann vorhandenen Drahtverhau macht das nicht mehr wirklich viel Spaß und dann die Probleme mit der Zuverlässigkeit - na ich weiß ja nicht...

@holm
Sicherlich sind die DIL-Varianten der AVRs "easy" zu handhaben und für einfache Zwecke, wie LED-Blinkerein auch völlig ausreichend. Aber versuche doch mal ein komplexeres System, z.B. Master-Slave mit zwei µCs, oder eine GLCD-Adaptierung, wo der/die interne(n) Controller besondere Zeitbedingungen in der Ansteuerung erfordern. Von solchen "HighLights", wie der Ansteuerung von MemoryCards will ich hier gar nicht reden.
Das Programm via ISP auf den µC "schießen" ist i.d.R. einfach (obwohl es auch dabei Probleme geben kann), aber was machst Du, wenn das Programm zwar erfolgreich "gebrannt" wurde, aber nichts, oder nicht das Erwartete passiert. Meßtechnisch da weiter zu kommen, ist kaum möglich, bzw. man hat nicht das dazu erforderliche Equipment (z.B. Logic-Analyser).
Eine Fehlersuche (Debugging) mittels des Studio-Simulators erfaßt nicht die realen Außenbedingungen. Die sind aber bei den o.g. genannten Applikationen von essentieller Bedeutung. Die JTAG-Schnittstelle bietet hierzu die gewünschte Funktionalität, jedoch kann das STK500/600 zwar via JTAG programmieren, aber soweit mir bekannt ist kein Debugging via JTAG. Hierzu geht nur der JTAG ICE MkII (oder dessen Nachfolger) - und das funktioniert nachweislich gut.
Noch schwieriger ist das bei den XMegas mit ihren viel höheren Taktfrequenzen und der noch größeren Funktionsvielfalt. Eigentlich sollte ja so etwas das Ziel sein, aber mit etwas Kleinerem anfangen und damit Erfahrungen sammeln ist sicherlich der bessere Weg...

Wenn es interessiert - ich kann noch vieles mehr über das "Warum" und "Wieso" zum AVR-Development-System aufzählen. Dazu wird es zum nächsten Update auf meiner HP eine Zusammenfassung des Entwicklungsberichtes geben.

Hat keiner was zu dem Planarspulen-Baukasten zu sagen?

Das Wissen der Menschheit gehört allen Menschen! -
Wissen ist Macht, wer glaubt, der weiß nichts! -
Unwissenheit schützt vor Strafe nicht! -
Gegen die Ausgrenzung von Unwissenden und für ein liberalisiertes Urheber- und Markenrecht!
PS

Dieser Beitrag wurde am 12.05.2013 um 08:33 Uhr von P.S. editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
12.05.2013, 08:55 Uhr
holm

Avatar von holm

@PS: Mache lieber die Interfaces nur 1x als Module und evtl. dazu verschiedene CPU Module,
LAN, CAN, 7-Seg, alphanum. LCD, Grafik..., AD/DA ähnlich wie diese Arduino Shields..(habe ich nicht) das ist IMHO universeller als ein Brett wo Alles drauf ist.
Die Chinesen bauen auch solches Zeuch (Shields) die gibts auch für kleines Geld in der Bucht
(insofern man Ebay übertölpeln kann und trotz der miesen Suche mit Benachteiligung Deutscher die Artikel findet)

Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Dieser Beitrag wurde am 12.05.2013 um 08:55 Uhr von holm editiert.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
15.05.2013, 08:00 Uhr
P.S.

@holm
Zitat: "@PS: Mache lieber die Interfaces nur 1x als Module und evtl. dazu verschiedene CPU Module..."
Genau so ist es angelegt - ein universelles Interface-Board passend für verschiedene µC-Steckmodule. Ok, LAN und CAN ist (noch) nicht drauf - Platz ist aber noch vorhanden.
Was mich viel mehr interessieren würde, wie die Meinung zum Dual-Channel-USB ist, mit dessen Hilfe eben nur noch eine USB-Verbindung zum PC für Programmierung, Debugging und Kommunikation mit der Applikations-Software notwendig ist und kein JTAG ICE MkII o.ä gebraucht wird.
Das System ist wirklich nur als Entwicklungs- und Lernsystem gedacht, obwohl natürlich für eine konkrete Zielanwendung das betreffende Layout entsprechend angepasst auch wiederverwendet werden kann.

Hat wirklich keiner was zu dem Planarspulen-Baukasten zu sagen?

Das Wissen der Menschheit gehört allen Menschen! -
Wissen ist Macht, wer glaubt, der weiß nichts! -
Unwissenheit schützt vor Strafe nicht! -
Gegen die Ausgrenzung von Unwissenden und für ein liberalisiertes Urheber- und Markenrecht!
PS

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
15.05.2013, 08:34 Uhr
Mario Blunk

Avatar von Mario Blunk

Hallo,

zu dem eigentlichen Thema hab ich nicht viel zu sagen. Bei mir läuft vieles mit Z80 oder FPGAs (welcher Gegensatz :-)).
Aber zu der JTAG-Thematik kann ich Bücher und Bände erzählen. Das Protokoll ist mir bis ins Blut vertraut. Wer da also Hilfe braucht, darf sich vertrauensvoll an mich wenden.

Gruß,

Mario
--
Mein Chef ist ein jüdischer Zimmermann.

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]