Hallo Forum, auf der Suche nach Möglichkeiten ein AVR-Netzwerk effektiv debuggen zu können, musste ich feststellen das dieses "Debugwire"-Protokoll offenbar mehr Qual als Feature darstellt. Während in der Welt der Arbeitsrechner Konzerne wie Microsoft seitens der EU (endlich) dazu verdonnert wurden ihre Protokolle offenzulegen und das eigentliche Produkt erst nutzbar zu machen, scheint ATMEL denselben Weg gehen zu wollen und verkauft "Chips ohne Bedienungsanleitung". Das wäre bei einem Sekundärprodukt vielleicht weniger übel, aber gerade bei einem programmierbaren Chip ist das ein mehr als unfairer Handel. Gerade im überbürokratisierten Deutschland wo jede Drahtbrücke im Verkauf technisch dokumentiert werden muss empfinde ich das als inakzeptable Rechtsbrechung, zumal das "Feature" Debug-Fähigkeit offen in der Werbung proklamiert wird. Es geht mir nicht darum an der Preisschraube zu drehen, denn ein 1-Chip-Debugger schwebt mir im Geiste garnicht vor, sondern darum die Funktionsfähigkeit der teuer erstandenen Chips nutzen zu können. Ein Dragon oder ICE-mk2 kommen nicht in Frage da sie aufgrund der maximalen Kabellänge von USB und Rs232 für den Einsatz über weite Distanzen nicht geeignet sind. Das AVRstudio kommt zum Debuggen z.Zt. ebenfalls nicht in Betracht weil es offenbar nur einen Chip in der Kette erlaubt. Somit wäre ein Grund gegeben die Offenlegung des Protokolls zu fordern, um effektive Debugger zu entwickeln, welche das erstandene Feature nutzbar machen - Was es zur Zeit definitiv nicht ist. ( Und damit meine ich nicht nur vernetzte Systeme sondern auch immer wieder auftretende Timing-Probleme während der dw-Sessions ) In Zeiten wo vernetzte Systeme und OOP-Sprachen keine Visionen sondern Alltag sind dürften die angeführten Gründe für sich sprechen. Wozu diese Ausschweifungen ? Wenn es ATMEL nicht schaft ihre Produkte technisch zu dokumentieren .. ( Diese Ausrede las ich mehrmals im Internet - Wenn es nicht stimmt entschuldige ich mich hiermit ) .. vielleicht schafft es ja dieses enthusiastische Forum. Ich vermute wenn erstmal der erste "Freie" Debugger steht werden schnell auch andere Einsatzgebiete gefunden werden. Es soll ja auch kein ICE-MK2 clon sein, sondern (minimal) eine Dokumentation eines bereits bezahlten Feature. Schliesslich hat ATMEL keine Glanzleistung vollbracht, denn (robuste) 1-Wire Lösungen (offen dokumentiert) gibt es en Masse (z.b. im Recher mit dem dieser Beitrag verfaßt wurde) und die JTAG-Lösung ist bereits eine bewährte Technik die eben jene vernetzte Fehlersuche und Steuerung ermöglicht. Ein Gast
Microsoft wird dazu verdonnert, weil sie eine Monopolsituation ausnutzen. Atmel hat kein Monopol und du hast folglich die Freiheit, andere Lösungen zu wählen. Es wäre sicherlich angenehmer, wenn Atmel das Protokoll rausrücken würde, aber zwingen kann man sie dazu nicht.
Bei TI ist es das gleiche in Grün. Die legen ihr komplettes JTAG auch nicht offen. Ok, bei denen kann man eine NDA unterschreiben aber dann muss man alles selbst programmieren ... Was Motolola mit dem BDM gemacht hat oder ARM mit dem ARM-JTAG ist sehr vorbildlich. Daran sollten sich ATMEL, TI und andere mal eine Scheibe abschneiden.
Hallo, @Andreas Kaiser: .. Monopol im Bezug auf AVR´s sicherlich, zumindest ist mir kein anderer Chip mit AVR-Kern bekannt .. @chilipower: .. dafür existieren ja diverse Simulatoren (bzw. Szenarios) in Astudio aber einen Testlauf mit externen Eingabedaten aus mehreren Quellen kann man damit in der Praxis nicht simulieren und gängige Praxis ist es nunmal Maschinen im Betrieb zu testen .. @msp: .. ACK ich denke einfach ATMEL hat gewisse Züge an den Tag gelegt die eine Kooperation bzw. Kompromissbereitschaft bekunden ( scheint im hohen Norden generell ausgeprägter zu sein ) .. das war ja auch der Grund dieser gezügelten Formulierung, ein Mikrocontroller ist nunmal ein programmierbarer Chip und kein Toaster .. mfg Euer Gast
was sich atmel da mit debugwire leistet ist für die tonne da sieht man mal das billig nicht immer besser ist mein tip nimm gleich nen richtigen prozessor grade weil der drache so "billig" ist kann man ahnen was das protokoll taugt lol microsoft passt schon für i2c (was imgrunde auch geklaut) ist abkassieren zu wollen ist typisch redmond gruss gerd
Gast wrote: > auf der Suche nach Möglichkeiten ein AVR-Netzwerk effektiv debuggen zu > können, musste ich feststellen das dieses "Debugwire"-Protokoll offenbar > mehr Qual als Feature darstellt. Das ist erstmal eine Behauptung, zu der du jeglichen Beweis fehlen lässt. > Es geht mir nicht darum an der Preisschraube zu drehen, > denn ein 1-Chip-Debugger schwebt mir im Geiste garnicht vor, > sondern darum die Funktionsfähigkeit der teuer erstandenen Chips nutzen > zu können. Wenn du sie nicht nutzen kannst, dann nerve Atmel mit Bugreports. Solange du diesen Weg nicht ausgeschöpft hast, wirst du sowieso keine anderen juristischen Schritte unternehmen können. Selbst das Recht auf reverse engineering wird dir ja legal nur zugestanden, wenn du anderweitig die entsprechenden Eigenschaften nicht nutzen kannst. > Ein Dragon oder ICE-mk2 kommen nicht in Frage da sie aufgrund der > maximalen Kabellänge von USB und Rs232 für den Einsatz über weite > Distanzen nicht geeignet sind. Was schwebt dir denn so vor? Wie willst du es überhaupt anstellen? Ganz davon abgesehen: du kannst ein embedded Unix als Server für einen AVR Dragon oder ein JTAG ICE mkII benutzen und dann mittels AVaRICE über einen TCP-Port debuggen. Sonderlich schnell ist das nicht, aber möglich -- und AVaRICE selbst implementiert das Ganze mit den bereits vorhandenen Dokumentationen. OK, weitgehend, ohne Rückfragen bei Atmel ging's nicht -- aber prinzipiell ist der gute Wille zu sehen, wenigstens das API von JTAG ICE / Dragon zu dokumentieren. Btw., um mit DebugWire erfolgreich arbeiten zu können, musst du prinzipbedingt das Target power-cyclen können. > Das AVRstudio kommt zum Debuggen z.Zt. ebenfalls nicht in Betracht weil > es offenbar nur einen Chip in der Kette erlaubt. Häh? Worüber reden wir, über JTAG oder über debugWire? Selbst bei JTAG stimmt deine Aussage meines Wissens nicht, da man mehrere AVRs in der JTAG chain debuggen kann (im Gegensatz zu MSP430s, die wohl die ersten in der Kette sein müssen, hat hier mal jemand nach entsprechender Analyse geschrieben). Allerdings kann man wohl nur einen auf einmal debuggen, da man nur ein JTAG ICE in der Kette anbringen kann. > ( Und damit meine ich nicht nur vernetzte Systeme sondern auch immer > wieder auftretende Timing-Probleme während der dw-Sessions ) debugWire ist in der Tat recht fragil. Andererseits erlaubt es halt das Debuggen von Controllern einer Größenordung, die man davor noch gar nicht debuggen konnte. Glaubst du allen Ernstes, dass du bei der bekannten Fragilität des Protokolls (das du ganz sicher nicht von heute auf morgen geändert bekommen wirst -- IC-Entwicklungen ziehen sich über viele Jahre hin) so im Handumdrehen in der Lage wärst, die ICE-Firmware aus dem Stegreif 100 % besser hinzulegen? Sorry. Du hast nichtmal einen Namen (bzw. bist zu feig, ihn zu nennen), geschweige denn einen Namen, dem ich das zutrauen würde. (Ehrlich gesagt: ich würde es nichtmal selbst versuchen wollen. Ich habe mittlerweile ungefähr ein Gefühl dafür, was da wohl abgeht, da ich die entsprechende Implementierung in AVaRICE verbrochen habe.) > In Zeiten wo vernetzte Systeme und OOP-Sprachen keine Visionen sondern > Alltag sind dürften die angeführten Gründe für sich sprechen. Bullshit Bingo Alert!
Hallo Herr Wunsch (..oder wie immer sie heissen mögen ?!) Die wenigen Fakten die ich ihrem Post entnehmen konnte lassen darauf schliessen das sie sich an der Thematik offensichtlich auch schon die Zähne ausgebissen haben.. ..aber wozu aufgeben ? Zum "Vorhaben" Mir schwebt ein simpler "Switch" in AVR-bauweise vor, welcher dw zum jeweiligen Target routet denn dann ist das Protokoll für skalierbare Projekte tatsächlich brauchbar. ( Auch für AVRice wäre das simple zu implementieren mittels Addressprüfung... ) Ferner eine "Robustheit" welche mit I2C konkurieren könnte.. ..denn unter der Siliziumhülle sehe ich da keine grundliegenden Unterschiede. Das Thema "Kabellänge" ist schwer genauer zu spezifizieren.. Was ist daran nicht zu verstehen, daß die Kontrolleinheit auch auf mehere hundert Meter entfernt funktionieren muss ??? ( Stichwort LAN/WLAN-Programmer ) ..und NEIN - Pro Chip einen Dragon halte ich für den absoluten OVERKILL. ( Soviel zum Thema "Embedded Unix..." ) Ein Chip pro Kette.. mhm was passiert denn wohl wenn ich mehrere anschliesse ? ( Ich kann nur immer wieder I2C betonen.. ) ..der Grund AVRstudio anzuführen lag auf der Hand, denn für ATMEL dürfte es ein Kinderspiel sein eine Zieladresse in einer dw-Chain zu implementieren.. ( I2C .. eben ) Das mit der Rechtslage zum "Reverse Engineering" stimmt so nicht ganz, "anderweitig" klingt da sehr weit definiert.. ..tatsächlich ist es ja nunmal so, daß die Register / Funktionen NICHT ohne Zukauf einer proprietären Hardware nutzbar sind.. ( Die Betonung liegt auf proprietär wie "Monopol" .. ) Herr Wunsch, das meine Identität dermassen Gegenstand ihres Interesse ist, ist mir mit Verlaub gesagt schleierhaft.. ? ( Kann es sein das sie Menschen gerne in Schubladen sortieren ? ) In einem Forum in dem diese Art des Postings ermöglicht wird, werde ich auch weiterhin diese angenehme Art und Weise nutzen ohne mich mit Passwörtern o.ä. rumzuschlagen. Der Gast
Stefan May wrote:
> @Gast: Also Du hast schon echt merkwürdige Ansichten.
Er scheint unter Verfolgungswahn zu leiden. Und unter Größenwahn, was
die eigene Leistung betrifft.
...
LOL Nun aber mal halblang, ich fantasiere hier ja nichts zusammen, die Geräte überschwemmen ja längst den Markt LOL Zum Thema Datenschutz scheinen hier manche auch die letzten Wochen verpennt zu haben LOL Aber OK, wenn hier Einige ihre Rechte gerne an der Eingangstür abgeben, wer wär ich denn das ich´s Ihnen verbieten würde ? Mal ne´ andere Theorie.. ..kann es sein das hier ganz einfache "Consultants" ihr Unwesen treiben ? ROFL mfg Euer Gast
Genau "Consultants". Und Du bist der Oberguru. Bisher habe ich nicht den Eindruck, daß Jörg Wunsch, Peter Danegger oder Karl-Heinz Buchegger "einfache Consultants" sind. Um nur einige der kompetenten Diskussionspartner zu nennen. Jedenfalls haben sie im Forum nicht so einen Schmarrn abgegeben wie Du. Ich zitiere mal: "In Zeiten wo vernetzte Systeme und OOP-Sprachen keine Visionen sondern Alltag sind dürften die angeführten Gründe für sich sprechen." Mit solch einem Spruch hast Du Dich selbst disqualifiziert. Zum Thema Datenschutz: Es hat eher etwas mit Höflichkeit zu tun, wenn man sich bei einem Gespräch oder einer Diskussion gegenseitig vorstellt. Bei Dir weiß ich noch nicht einmal, ob sich beim nächsten Post nicht eine andere Person hinter "Gast" verbirgt.
Man kann rummeckern, oder das Problem anpacken. Die Kabellaenge sollte keine Rolle spielen, da muss man eben einen Bus zwischenschalten. Je nach Leitungslaenge sind RS485/RS422 Treiber denkbar. Fuer kuerzere Leitungen LVDS. Multipoint sollte ach machbar sein, wenn man mit Selektroten arbeitet.
Stefan May wrote: > Zum Thema Datenschutz: Es hat eher etwas mit Höflichkeit zu tun, wenn > man sich bei einem Gespräch oder einer Diskussion gegenseitig vorstellt. > Bei Dir weiß ich noch nicht einmal, ob sich beim nächsten Post nicht > eine andere Person hinter "Gast" verbirgt. Richtig. Zusammen mit dem gezeigten Größenwahn (,,Ich weiß sowieso alles viel besser'') und dem hundsmiserabel formatierten Posting, dessen Lesen einfach mal 'ne Zumutung ist, schon von der Form her, hat sich die Diskussion für mich einfach erledigt. Abgehakt als Troll, dieser Gast (Gast) (wie die meisten derartigen Kreaturen).
Für die Nicht-Aufgeber und Nicht-Nörgler hier mal ein paar Tips:
1. Atmel hat die JTAGICE-Kommandoliste sauberst veröffentlicht,
bis AVRstudio mit einem m32 als ICE-mk2 anfing zu quasseln
hat es keine halbe Stunde gedauert..
TIPs:
1. Es gibt eine sehr einfache Firmware/Hardware Nummer
und schon hört das Gezeter mit "Update"-Wünschen auf..
2. Um mit dem Device-Deskriptor-Table nicht in Lethargie zu
verfallen,
sollte man das erste Programmier-Paradigma zu Rate ziehen..
"Nicht alle AVR-Typen auf einmal erschlagen wollen"
(dann ist das ganze Unternehmen sehr einfach und passt auch
in kleinere Chips)
2. Die dw-Seite ist recht simpel zu erobern,
nachdem man sich mit dem Timing angefreundet hat..
..danach ist das Einsteigen in jedweden Modus ein Kinderspiel...
( denn nachdem OCDenable gesetzt wurde befindet man sich nicht dort
wo AVRstudio normalerweise einsteigt.. )
..dafür einfach ein Target mit einem simplen "Blinker" o.ä. füttern
..und ins dw-Nirvana schicken
PS:
Gerade die Error-Codes die zwangsläufig mal auftreten
sind perfekte Wegweiser... einen Oskar braucht man dafür nicht
Fazit
Aufgrund mangelnder Rückendeckung gibt es keine Veröffentlichung,
zum Aufsetzen eines Emu´s ist sowieso nur Hausaufgaben-Niveau nötig,
wer dann tatsächlich einen LAN-Progger basteln will
sollte sich definitiv mal einen ARM anschauen..
..denn dann wird es NICHT langsam.
PSS:
Ein winzig kleiner Tip um das Ganze "robuster" zu machen..
z.b. einen t2313 für 1 EUR an den Reset-Pin des Target zu klemmen..
Dieser könnte bei einer "Kabellänge" im Millimeterbereich
das stark anfällige dw-Protokoll z.b. auf SPI oder UART transformieren..
( Das klappt und ist wesentlich robuster als irgendwelche krummen
Spannungsteiler-Lösungen )
Der Gast,
der die Gastfreundschaft mancher Forenteilnehmer stark infrage stellt ;)
PS: Es ging hier nichtmal ansatzweise um eine Hardware-Debatte, auch wenn manche Kunden das gerne in diese Richtung hätten abschweifen lassen.. ..dann doch lieber die englischen Foren, wo Menschen welche Wörter wie "Troll" verwenden von vornherein nicht beachtet werden..
@Der Gast (Gast) Sag mal, bist du der Gast Gast der im OT immer seine Tiraden ablässt? Das Sozialverhalten deinerseits erinnert mich irgendwie stark daran.
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.