mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Debugwire Offenlegung


Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chilipower (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schreib dir einen Softwaredebugger, dann haste das Problem nicht!

Autor: msp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan May (smay4finger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gast: Also Du hast schon echt merkwürdige Ansichten.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

...

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan May (smay4finger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 3354 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Der Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: Der Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: mitgelesen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.