Warum Renesas R8C Murks ist
Olaf Kaluza
Ich hab jetzt mal ein bisschen mit dem R8C/15 rumgespielt. Eigentlich
ja ganz nett. Ich bin jetzt soweit das ich auf ein angeschlossenes
I2C LCD einen Text ausgeben kann.
Aber die Programmiersoftware von dem Laden ist ein gerade zu
bemerkenswerter kranker Murks. Selbst einer drei Personen Firma waere
dieses Tool schon peinlich.
Zum einen muss man jedesmal beim reinladen eines Programmes angeben wo
sich denn das S-Record-File befindet. Das ist schon schlimm genug.
Dann muss man noch jedesmal eine aus sieben 2Byte Hexziffern bestehende
ID eingeben. Beim erstenmal kann man sich diese ID aussuchen, danach
muss man immer dieselbe eingeben. Bei mir war das 7x 0xff.
Stimmt diese ID nicht, kann man nichts mit dem Prozessor machen, auch
nicht loeschen!
Man fragt sich natuerlich was der Scheiss soll, aber eigentlich kann
da ja nichts schief gehen. Da man ja auch die ID haben muss um den
Prozessor zu loeschen kann man danach auch immer sein neues Programm
einbrennen.
Da bedeutet auch das man selber diese ID auch garnicht mehr aendern
kann es sei denn man schreibt sich extra ein Programm das im Prozessor
laeuft, laedt dieses mit der alten ID rein und dieses Programm aendert
spaeter im internen Flashrom die ID um. Aber das muss man natuerlich
bewusst machen.
Da aber diese Programm zum flashen der ALLERLETZTE Murks ist, ist da
wohl irgendwas schief gelaufen. Obwohl ich das teil schon so 20-30 mal
gebrannt habe geht es auf einmal nicht mehr. Er behauptet meine ID sei
falsch. Jetzt kann ich das Kit an die Wand nageln.
Es sei denn jemand kennt noch einen Trick auf den ich bis jetzt noch
nicht gekommen bin.
Olaf
Steffen Koepf
> Da aber diese Programm zum flashen der ALLERLETZTE Murks ist, ist da
> wohl irgendwas schief gelaufen. Obwohl ich das teil schon so 20-30 mal
> gebrannt habe geht es auf einmal nicht mehr. Er behauptet meine ID sei
> falsch. Jetzt kann ich das Kit an die Wand nageln.
Halbwertszeit: 1 Tag?
scnr,
Steffen
Rafael Deliano
auf dem MC68HC908GP32 auch:
FLASH ist kapriziös, die Schreibroutine
kann abstürzen und Firmwareteil
mitnehmen.
Zudem gibt es im Kleingedruckten
des Datenblatts Angaben zum FLASH
bezüglich wie oft Schreiben/Löschen
die man nach 2x Lesen nicht verstanden
hat und die einem nach nochmaligem Lesen
verdächtig vorkommen. Der "Memory-Effekt"
bei Akkus kommt einem da harmlos vor.
> Jetzt kann ich das Kit an die Wand nageln.
Ein Monitor/System auf dem Chip zur Entwicklung
ist eine feine Sache solange er tut. Aber
man braucht Sicherheitskopie der Firmware
und ein Programmiergerät um Mass-Erase und
Neuladen durchführen zu können.
MfG JRD
Olaf Kaluza
>Ein Monitor/System auf dem Chip zur Entwicklung
>ist eine feine Sache solange er tut. Aber
>man braucht Sicherheitskopie der Firmware
>und ein Programmiergerät um Mass-Erase und
>Neuladen durchführen zu können.
Das ist natuerlich fuer mich privat nicht akzetabel. Aber auch als Ing
in der Firma hilft mir das bei einem aufgeloeteten SMD nicht soviel
weiter. Ausserdem stelle ich mir gerade vor einem von unseren
Servicetechnikern wuerde beim Kunden soetwas passieren.
Da sind die Atmels doch besser. Auch da kann man sich die Tuer vor der
Nase zuschlagen indem man sich den Oszillator wegdefiniert oder den
Reset abklemmt, aber das ist dann wenigstens ein bewusster Akt von
Bloedheit und man weiss das man selber schuld ist.
Ganz nebenbei fuehrt das natuerlich auch dazu das der begabte Bastler
von morgen sich keine R8C CPUs aus alten Sachen ausschlachten kann.
Olaf
p.s: Ich glaub ich frag mal bei Pollin an ob die nicht einen tollen
Controller zum testen ihres 16Segment LCDs brauchen das alle Segmente
einschaltet. :-)
Andreas Ruetten
> Rafael Deliano <Rafael_...@t-online.de> wrote:
>
>
> >Ein Monitor/System auf dem Chip zur Entwicklung
> >ist eine feine Sache solange er tut. Aber
> >man braucht Sicherheitskopie der Firmware
> >und ein Programmiergerät um Mass-Erase und
> >Neuladen durchführen zu können.
>
> Das ist natuerlich fuer mich privat nicht akzetabel. Aber auch als Ing
> in der Firma hilft mir das bei einem aufgeloeteten SMD nicht soviel
> weiter. Ausserdem stelle ich mir gerade vor einem von unseren
> Servicetechnikern wuerde beim Kunden soetwas passieren.
>
> Da sind die Atmels doch besser. Auch da kann man sich die Tuer vor der
> Nase zuschlagen indem man sich den Oszillator wegdefiniert oder den
> Reset abklemmt, aber das ist dann wenigstens ein bewusster Akt von
> Bloedheit und man weiss das man selber schuld ist.
Naja,
so vollkommen bescheuert wie manche Atmel programmer die Fuses anzeigen,
doppelte Invertierung und so.
Und Außerdem was soll der ganze scheiß mit den Fuses ?
Warum nicht immer mit 1Mhz internen Oszillator hochfahren und die
Software entscheiden lassen was sein soll. Oder hat da Cygnal / Silabs
ein Patent drauf.
Atmel treibt es sogar so bunt, das man einen AVR kaufen kann, in dem der
externe Oszillator voreingstellt ist, und somit ein Takt außen angelegt
werden muß( Zum Fuses setzen ), wenn mann den internen Oszi verwenden
will. Hab mich schon deswegen schwarz geärgert(100Stück so eingestellt )
Und es scheint nur generell nur eine Entwicklerbude für µC Tools zu geben.
Denn alle sind gleich scheiße. Alle die die serielle benutzen verkacken
ständig, oder ziehen einfach alle Processorleistung an sich.
ICE MPLAB ICE2000 Mikrochip. Ich hatte eines der ersten, ich habe mich
so geärgert, das ich nie mehr was mit PIC's gemacht habe. ( war auch
noch scheisse teuer )
Silabs IDE mit ECE2. Zieht auf einem 3Ghz P4 80% Processorzeit um die
serielle mit max. 115200 anzusteuern !!!!!
ACEx von Fairchildsemi -> serielle verkackt so , das Rechneustart
fällig ist -> Schrott
µPSD von ST , auch probleme mit serieller.
MSP430 mit IAR kennt nur eine Fehlermeldung abort -> und weg.
AVR mit Studio und Jtag Adapter(seriell) gibt wenig Probleme.
AVR mit Studio und JtagICE2 Adapter(USB) gibt keinen Grund zum klagen.
Ich glaube nicht das alles an mir liegt, und ich habe auch schon einige
Rechnergenerationen verschlissen, es war also nicht nur ein PC/
Betriebssystem.
Sorry,
aber der Frust mußte mal raus ...
Dirk Ruth
"
>
>Ich hab jetzt mal ein bisschen mit dem R8C/15 rumgespielt. Eigentlich
>ja ganz nett. Ich bin jetzt soweit das ich auf ein angeschlossenes
>I2C LCD einen Text ausgeben kann.
>
>Aber die Programmiersoftware von dem Laden ist ein gerade zu
>bemerkenswerter kranker Murks. Selbst einer drei Personen Firma waere
>dieses Tool schon peinlich.
>
>Zum einen muss man jedesmal beim reinladen eines Programmes angeben wo
>sich denn das S-Record-File befindet. Das ist schon schlimm genug.
>
Das ist leider sehr schade.
>Dann muss man noch jedesmal eine aus sieben 2Byte Hexziffern bestehende
>ID eingeben. Beim erstenmal kann man sich diese ID aussuchen, danach
>muss man immer dieselbe eingeben. Bei mir war das 7x 0xff.
Warum hast Du die denn gesetzt?????
Das ist der Softwareschutz, damit niemand über die serielle andocken
und Deine Software auslesen kann. Die ändert man erst vor dem
Verpacken und Ausliefern. Bist Du schon soweit??
>
>Stimmt diese ID nicht, kann man nichts mit dem Prozessor machen, auch
>nicht loeschen!
Halt ebend Softwareschutz.
>
>Man fragt sich natuerlich was der Scheiss soll, aber eigentlich kann
>da ja nichts schief gehen. Da man ja auch die ID haben muss um den
>Prozessor zu loeschen kann man danach auch immer sein neues Programm
>einbrennen.
>Da bedeutet auch das man selber diese ID auch garnicht mehr aendern
>kann es sei denn man schreibt sich extra ein Programm das im Prozessor
>laeuft, laedt dieses mit der alten ID rein und dieses Programm aendert
>spaeter im internen Flashrom die ID um. Aber das muss man natuerlich
>bewusst machen.
Wenn Du die alte ID hast (bei Auslieferung immer 000...), dann kannst
Du auch eine Neue setzen. Nur wenn Du nicht die richtige ID hast, dann
reagiert der Controller nicht auf Deine Befehle am seriellen Port.
>
>Da aber diese Programm zum flashen der ALLERLETZTE Murks ist, ist da
>wohl irgendwas schief gelaufen. Obwohl ich das teil schon so 20-30 mal
>gebrannt habe geht es auf einmal nicht mehr. Er behauptet meine ID sei
>falsch. Jetzt kann ich das Kit an die Wand nageln.
>
Wieso hast Du denn den Controller komplett geflasht????
Normalerweise flasht man nur den Monitor nur ein einziges mal mit dem
Flashtool.
Das war's!!!
Ein neues Programm zum testen lädt man über den KD30 in den
Controller. Erst vor Auslieferung wirft man den Monitor wieder raus
und flasht die Applikation ohne den Monitor.
>
>Es sei denn jemand kennt noch einen Trick auf den ich bis jetzt noch
>nicht gekommen bin.
Wenn Du keine ID mehr hast, dann kannst Du nur noch mit einem
Parallel-Adapter flashen, wenn Du da nicht auch noch den Schutz
eingeschaltet hast. Der kostet aber mehr wie ein neuer Controller.
Dirk
Rafael Deliano
> SMD nicht soviel weiter.
incircuit-programmiert. Also ist es nachladbar und im
Feld updatefähig.
Um die Boards zu testen ( Testsoftware ins RAM laden,
oder in der Firmware vorsehen ) bzw. um Rückläufer
zu untersuchen braucht man den Zugriff incircuit in
den Controller rein ja auch.
In der M&T ist mal bei Diskussionsrunde zu automotive
der Begriff "Alzheimer-FLASH" gefallen. Aber Rückfrage
des Journalisten was das genau sei hat bei den
Vertriebsleuten zu eisernem Schweigen geführt.
> R8C CPUs
Ich würde annehmen die kann man auch incircuit programmieren.
Das Board muß aber entsprechend ausgelegt sein.
Bei Freescale z.B. muß man IRQ-Pin auf 8V anheben.
Muß den PA0-Pin hochohmig bekommen sodaß er bidirektional
halbduplex die V24 macht. Andere PIns auf GND oder 5V ziehen.
Muß alles in der Entwicklung der Hardware berücksichtigt
sein, sonst hat man mit eingelötetem FLASH keine Freude.
Man kann bei den Motorola/Freescale auch
Bereiche irreversibel ( d.h. nur MassErase
hilft ) schreibschützen. Damit verbaut man sich in
einem Monitor/FORTH aber die Möglichkeit einfach in der
Firmware rumpatchen zu können.
MfG JRD
Dirk Ruth
"
>
>Ich hab jetzt mal ein bisschen mit dem R8C/15 rumgespielt. Eigentlich
>ja ganz nett. Ich bin jetzt soweit das ich auf ein angeschlossenes
>I2C LCD einen Text ausgeben kann.
>
>Aber die Programmiersoftware von dem Laden ist ein gerade zu
>bemerkenswerter kranker Murks. Selbst einer drei Personen Firma waere
>dieses Tool schon peinlich.
>
>Zum einen muss man jedesmal beim reinladen eines Programmes angeben wo
>sich denn das S-Record-File befindet. Das ist schon schlimm genug.
>
Das ist leider sehr schade.
>Dann muss man noch jedesmal eine aus sieben 2Byte Hexziffern bestehende
>ID eingeben. Beim erstenmal kann man sich diese ID aussuchen, danach
>muss man immer dieselbe eingeben. Bei mir war das 7x 0xff.
Warum hast Du die denn gesetzt?????
Das ist der Softwareschutz, damit niemand über die serielle andocken
und Deine Software auslesen kann. Die ändert man erst vor dem
Verpacken und Ausliefern. Bist Du schon soweit??
>
>Stimmt diese ID nicht, kann man nichts mit dem Prozessor machen, auch
>nicht loeschen!
Halt ebend Softwareschutz.
>
>Man fragt sich natuerlich was der Scheiss soll, aber eigentlich kann
>da ja nichts schief gehen. Da man ja auch die ID haben muss um den
>Prozessor zu loeschen kann man danach auch immer sein neues Programm
>einbrennen.
>Da bedeutet auch das man selber diese ID auch garnicht mehr aendern
>kann es sei denn man schreibt sich extra ein Programm das im Prozessor
>laeuft, laedt dieses mit der alten ID rein und dieses Programm aendert
>spaeter im internen Flashrom die ID um. Aber das muss man natuerlich
>bewusst machen.
Wenn Du die alte ID hast (bei Auslieferung immer 000...), dann kannst
Du auch eine Neue setzen. Nur wenn Du nicht die richtige ID hast, dann
reagiert der Controller nicht auf Deine Befehle am seriellen Port.
>
>Da aber diese Programm zum flashen der ALLERLETZTE Murks ist, ist da
>wohl irgendwas schief gelaufen. Obwohl ich das teil schon so 20-30 mal
>gebrannt habe geht es auf einmal nicht mehr. Er behauptet meine ID sei
>falsch. Jetzt kann ich das Kit an die Wand nageln.
>
Wieso hast Du denn den Controller komplett geflasht????
Normalerweise flasht man nur den Monitor nur ein einziges mal mit dem
Flashtool.
Das war's!!!
Ein neues Programm zum testen lädt man über den KD30 in den
Controller. Erst vor Auslieferung wirft man den Monitor wieder raus
und flasht die Applikation ohne den Monitor.
>
>Es sei denn jemand kennt noch einen Trick auf den ich bis jetzt noch
>nicht gekommen bin.
Wenn Du keine ID mehr hast, dann kannst Du nur noch mit einem
Olaf Kaluza
>Warum hast Du die denn gesetzt?????
Weil die Software sonst immer gesagt das man keine ID gesetzt hat und
man nicht weitermachen kann.
Mittlerweile kommt es noch besser. Ich hab das mindestens 20 mal
probiert und das Programm hat immer gesagt das die ID falsch ist.
Vorhin hab ich es einfach aus langeweile nochmal ausprobiert und
diesmal hat er die ID wieder akzeptiert. Ich konnte jetzt die CPU
loeschen und auch auslesen, aber nicht programmieren.
>Das ist der Softwareschutz, damit niemand über die serielle andocken
>und Deine Software auslesen kann. Die ändert man erst vor dem
>Verpacken und Ausliefern. Bist Du schon soweit??
Naja, niemand ist nicht richtig. Jemand der die ID geklaut hat
schon. Da sind andere Controller besser.
>>Stimmt diese ID nicht, kann man nichts mit dem Prozessor machen, auch
>>nicht loeschen!
>Halt ebend Softwareschutz.
Aber loeschen koennte man doch schon erlauben oder?
>Wenn Du die alte ID hast (bei Auslieferung immer 000...), dann kannst
>Du auch eine Neue setzen. Nur wenn Du nicht die richtige ID hast, dann
>reagiert der Controller nicht auf Deine Befehle am seriellen Port.
Tja, jetzt 'habe' ich sie wieder und ich darf alles ausser brennen.
>Wieso hast Du denn den Controller komplett geflasht????
>Normalerweise flasht man nur den Monitor nur ein einziges mal mit dem
>Flashtool.
>Das war's!!!
Welcher Monitor? Und wo soll der sein? Und wo soll dann mein Programm
sein? Das ist ja kein dicker M16C
Olaf
Dirk Ruth
"
>Dirk Ruth <d.r...@itecnet.de> wrote:
>
>
> >Warum hast Du die denn gesetzt?????
>
>Weil die Software sonst immer gesagt das man keine ID gesetzt hat und
>man nicht weitermachen kann.
>
>Mittlerweile kommt es noch besser. Ich hab das mindestens 20 mal
>probiert und das Programm hat immer gesagt das die ID falsch ist.
>
>Vorhin hab ich es einfach aus langeweile nochmal ausprobiert und
>diesmal hat er die ID wieder akzeptiert. Ich konnte jetzt die CPU
>loeschen und auch auslesen, aber nicht programmieren.
>
Da stimmt evtl. irgendwas mit Deiner Kommunikation nicht. Hast Du die
richtige Baudrate passend zum Quarz?
[...]
>
> >Wieso hast Du denn den Controller komplett geflasht????
> >Normalerweise flasht man nur den Monitor nur ein einziges mal mit dem
> >Flashtool.
> >Das war's!!!
>
>Welcher Monitor? Und wo soll der sein? Und wo soll dann mein Programm
>sein? Das ist ja kein dicker M16C
>
Lese gerade, dass Du gar keinen Monitor brauchst, weil der gleich vom
KD30 mitgeladen wird.
Der KD30 ist eigendlich das Sahnestück beim Debuggen. Und ich dachte,
Du wolltest mal was richtiges ausprobieren. Immer die Application
direkt zu flashen ist doch der gleiche Murks wie beim PIC und AVR.
Hier findest Du das Datenblatt http://www.m16c.de/sites/r8c15.htm
Der R8C/15 hat zwei Address Match Interrupts. Mit dem KD30 kannst Du
im Step-Betrieb arbeiten, oder zwei unabhängige Stop-Points setzen.
D.h., der KD30 setzt an der Stop-Adresse den Address Match Interrupt
und der Monitor wird aufgerufen, wenn der Prozessor auf die Adresse
kommt. Mit dem KD30 kannst Du Dir zu jedem Zeitpunkt ansehen, was auf
den Adressen steht (RAM oder ROM), Du siehst alle Register und kannst
Dir beliebige Variablen (structs, unions, arrays usw.) in's
Watch-Fenster ziehen und beobachten. Der KD30 zeigt Dir alles in
C-Sourcen Assembler oder gemischt an.
Dirk
Olaf Kaluza
>Vorhin hab ich es einfach aus langeweile nochmal ausprobiert und
>diesmal hat er die ID wieder akzeptiert. Ich konnte jetzt die CPU
>loeschen und auch auslesen, aber nicht programmieren.
Ich hab gerade nochmal ein bisschen rumgespielt.
Ich kann jetzt als ID alles eingeben und der Prozessor wird erkannt,
ich kann ihn dann auslesen und loeschen, aber nicht brennen.
Sehr eigenartig!
Olaf
Matthias Weingart
news:729f7$429b696b$508d8e48$14...@news1.surfino.com:
> MSP430 mit IAR kennt nur eine Fehlermeldung abort -> und weg.
Crossworks MSP430 ist gut. Flashed die 60k in ein paar Sekunden.
Sogar auf meinem P500. Und der MSP430 verhält sich so wie du das
beschrieben hast - laeuft per default immer mit ca. 800kHz.
Irgendwelche dämlichen Fuses gibbet nicht (bis auf die Echte, mit der
man den JTAG totlegt, da brennt wirklich ne Leiterbahn im Chip durch.
Das können aber "zum Glück" nur ein paar teurere JTAG Adapter. :-)
(Tja den MSP430 haben halt nicht igendwelche Prozessorleute gebaut,
sondern die Analogabteilung von TI (in Freising). Die kannten die
Probleme die Du hier schilderst wahrscheinlich alle selbst :-).
M.
--
Bitte auf mwn...@pentax.boerde.de antworten.
Dirk Ruth
Merkwürdig. Wenn Du Ihn löschen konntest, was willst Du dann auslesen?
Wenn Du nicht die richtige ID angibst, dann kannst Du nichts machen.
Hast Du mal versucht den KD30 zu installeren und dich an den R8 zu
connecten?
Dirk
Joerg Wunsch
> Und Außerdem was soll der ganze scheiß mit den Fuses ?
(Du plenkst, bitte abstellen.)
Schnellerer Start, ohne zweimal auf einen Oszillator warten zu müssen?
Fuses muss man ja sowieso für allen möglichen Krempel programmieren.
> Oder hat da Cygnal / Silabs ein Patent drauf.
Davon abgesehen, dass sowas ja auch nicht auszuschließen ist.
> Atmel treibt es sogar so bunt, das man einen AVR kaufen kann, in dem
> der externe Oszillator voreingstellt ist, und somit ein Takt außen
> angelegt werden muß( Zum Fuses setzen ), wenn mann den internen Oszi
> verwenden will. Hab mich schon deswegen schwarz geärgert(100Stück so
> eingestellt )
Lass mich raten, Uralt-Waren an AT90S2343? Hatte ein Kollege auch
mal, muss eine Ausschuss-Serie gewesen sein, die Reichelt billig
aufgekauft hat. ;-)
Passiert aber bei den aktuellen Chips nicht mehr, seit interner
RC-Oszillator standardmäßig auf jedem Controller drauf ist, der ist
dann immer voreingestellt.
> Und es scheint nur generell nur eine Entwicklerbude für µC Tools zu
> geben. Denn alle sind gleich scheiße.
Vielleicht solltest du dein Windows einfach in die Ecke legen und dich
der Welt der Opensource-Tools widmen. Wenn dir dort irgendwas nicht
gefällt, kannst du zumindest selbst aktiv dazu beitragen, es noch zu
verbessern (oft sind es ja nur Kleinigkeiten).
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Olaf Kaluza
>Vielleicht solltest du dein Windows einfach in die Ecke legen und dich
>der Welt der Opensource-Tools widmen. Wenn dir dort irgendwas nicht
>gefällt, kannst du zumindest selbst aktiv dazu beitragen, es noch zu
>verbessern (oft sind es ja nur Kleinigkeiten).
Das es dort besser ist glauben wir dir ja gerne, aber das ist ja auch
genau die Frage.
Ich meine eine Firma welche ICs herstellt sollte doch in der Lage sein
wenigstens ein halbwegs zuverlaessiges Programm zu schreiben was damit
arbeitet.
Ein weiteres Beispiel fuer die aergerlichen Kleinigkeiten die ich
meine:
Bei der Software von Renesas muss man ueber einen Haken einstellen
welchen Prozessor man hat. Aber jedesmal neu wenn man sein S-Record
neue eingelesen hat. Warum kann die sich das nicht merken? Hat der
Programmierer davon niemals dreimal hintereinander einen Prozessor
gebrannt? Dann waer ihm das wohl aufgefallen.
Schaust du dir dagegen mal das Programm an das jemand selber
geschrieben hat (http://www.m16c-flasher.de/) so hat das zwar auch
keine luxusdesignte Oberflaeche aber man merkt das es von jemanden
geschrieben wurde der wirklich mit den Controllern arbeitet. So
jemanden scheint es bei Renesas nicht zu geben.
Olaf
Olaf Kaluza
>Da stimmt evtl. irgendwas mit Deiner Kommunikation nicht. Hast Du die
>richtige Baudrate passend zum Quarz?
Ich mach alles defaultmaessig mit 9600 und das hat ja erstmal 20-30mal
funktioniert. Haette es von Anfang an nicht funktioniert wuerde ich
den Fehler natuerlich auch eher bei mir vermuten.
>Lese gerade, dass Du gar keinen Monitor brauchst, weil der gleich vom
>KD30 mitgeladen wird.
Da bin ich mal gespannt. :-) Ich probier es gleich mal aus.
Olaf
Olaf Kaluza
>>Ich kann jetzt als ID alles eingeben und der Prozessor wird erkannt,
>>ich kann ihn dann auslesen und loeschen, aber nicht brennen.
>>
>Merkwürdig. Wenn Du Ihn löschen konntest, was willst Du dann auslesen?
>Wenn Du nicht die richtige ID angibst, dann kannst Du nichts machen.
Argh! Es geht darum das die Programmfunktion 'Auslesen' nun
funktioniert ob dabei nun etwas sinnvolles rauskommt ist erstmal
nebensaechlich. Bis vor kurzem ging da naemlich nur ein Fenster auf
das ich die falsche ID habe. Wenn meine ID aber nun zum lesen und
loeschen geeignet ist, warum dann nicht zum brennen?
>Hast Du mal versucht den KD30 zu installeren und dich an den R8 zu
>connecten?
Nein.
Ich habe aber mal die Betaversion 1.40 vom anderen M16C-Flasher
(http://www.m16c-flasher.de/) runtergeladen und dort im File einen
eintrag fuer den R8 erzeugt. Der kann dann mit dem Prozessor
connecten, ihn loeschen und auslesen. Nur beim brennen gibt es sofort
nach beginn einen Fehler das ich ausserhab des erlaubten
Adressbereichs bin. Nun kann man das nicht ueberbewerten, da die
Software halt Beta ist und nicht fuer die R8 gedacht, aber interessant
finde ich schon das sie im Fehlerbild uebereinstimmt.
Olaf
Andre Grosse Bley
> Ich hab gerade nochmal ein bisschen rumgespielt.
>
> Ich kann jetzt als ID alles eingeben und der Prozessor wird erkannt,
> ich kann ihn dann auslesen und loeschen, aber nicht brennen.
>
> Sehr eigenartig!
Eindeutig. Ich hatte mal einen M16C, der sich so komisch verhielt. Wie
sich später herausstellte, war die Spannungsversorgung sehr gestört.
Evtl. hast Du ein ähnliches Problem? (Das war übrigens der erste LM317,
den ich schwingen sehen hab)
Natürlich ging die erste Idee Richtung "Controller defekt" ;-)
Sonst frag' mal bei Glyn nach, vielleicht wissen die mehr.
Grüße,
Andre
Olaf Kaluza
>Eindeutig. Ich hatte mal einen M16C, der sich so komisch verhielt. Wie
>sich später herausstellte, war die Spannungsversorgung sehr gestört.
>Evtl. hast Du ein ähnliches Problem?
Nein, der Verdacht liegt natuerlich nahe wenn man alles kann aber
ausgerechnet nicht flashen. Ich hab deshalb extra schon zwei
verschiedene Arten der Versorgung probiert.
Olaf
Olaf Kaluza
>Da bin ich mal gespannt. :-) Ich probier es gleich mal aus.
Debugger scheint grundsaetzlich zu funktionieren. Soll heissen er
laedt beim starten etwas in den Controller, ich konnte mein Programm
reinladen und mit 'GO' starten, und es laeuft dann auch.
Aber der Debugger ist dann nicht mehr zu bedienen und man muss ihn killen.
Muss ich von meinem Programm die Kontrolle besonders zurueckgeben? Ich
lass es jetzt einfach in das return von main laufen.
Eigenartig finde ich auch das der Debugger seine Firmware jedesmal
neu laedt. Ich dachte der schreibt sich in das Flashrom.
So langsam frag ich mich ob die Probleme nicht mit dem USB->RS232
Adapter zusammenhaengen. Aber warum sollte das dann erst funktionieren
und dann nicht mehr. Ausserdem gab es nie eine Fehlermeldung die
daraufhin deutet.
Ich teste auf jedenfall mal mit einer normalen RS232 und berichte dann.
Olaf
Andre Grosse Bley
> >Da bin ich mal gespannt. :-) Ich probier es gleich mal aus.
>
> Debugger scheint grundsaetzlich zu funktionieren. Soll heissen er
> laedt beim starten etwas in den Controller, ich konnte mein Programm
> reinladen und mit 'GO' starten, und es laeuft dann auch.
>
> Aber der Debugger ist dann nicht mehr zu bedienen und man muss ihn killen.
> Muss ich von meinem Programm die Kontrolle besonders zurueckgeben? Ich
> lass es jetzt einfach in das return von main laufen.
Du musst einen Interrupt-Vektor auf eine Routine im Monitor setzen.
Welcher das nun beim R8C ist, weiss ich nicht, sollte aber irgendwo in
der Doku stehen.
Gut, wenn Du (noch) keine eigene Interrupt-Tabelle setzt, dürfte das
entfallen.
Wo ich drüber gestolpert bin: Interrupts müssen noch aktiviert
werden (fset i).
Bei den richtigen Emulatoren von Renesas braucht man das natürlich nicht. ;)
Grüße,
Andre
Rafael Deliano
> sondern die Analogabteilung von TI (in Freising).
hält sich in Grenzen. Die Architektur der CPU mag gut sein und
die I/O ( Wandler mit guter Auflösung, MAC für Arithmetik ) ist
auch gut.
Aber MSP430 ist jetzt fast 10 Jahre alt, ein bisschen
ausgereifter könnte die Dokumentation und die Fehlerbehebung
schon sein. Das Errata-Blatt ist 13 Seiten mit 4 Bugs pro Seite.
Beim Bootloader ( 3 Bugs ) z.B. "The bootstrap loader SW cannot
program the flash memory, software workaround available" Was
der Fehler genau ist und wo man den Patch findet wird einem
aber nicht verraten. Ich habe auch nicht den Eindruck, daß
die Masken geändert werden, wird wohl munter mit Bugs
weiterproduziert.
Freescale 68HC08 ist nicht fehlerfrei, aber die Errata
mitdenen ich zu tun hatte sind 2 Seiten und wenn man
auf die Seriennummer der Chips schaut sind sie meist
historisch, d.h. Maske geändert, Bug hehoben.
MfG JRD
Dirk Ruth
"
>Olaf Kaluza <ol...@criseis.ruhr.de> wrote:
>
> >Da bin ich mal gespannt. :-) Ich probier es gleich mal aus.
>
>Debugger scheint grundsaetzlich zu funktionieren. Soll heissen er
>laedt beim starten etwas in den Controller, ich konnte mein Programm
>reinladen und mit 'GO' starten, und es laeuft dann auch.
>
Offensichtlich gelingt es dem Debugger Deinen Controller zu flashen!!
>Aber der Debugger ist dann nicht mehr zu bedienen und man muss ihn killen.
>Muss ich von meinem Programm die Kontrolle besonders zurueckgeben? Ich
>lass es jetzt einfach in das return von main laufen.
>
Beim M16C ist dass so, dass man die Interrupts der seriellen Ss. auf
bestimmte Adressen legen muss (bei Dir im Code). Wenn der KD30 etwas
an den Controller über die serielle Ss. sendet, wird dann in den
Monitor gesprungen, der antwortet. Ich kann mir aber gut vorstellen,
dass das beim R8C unnötig ist, weil der nur eine serielle Ss. hat und
somit alles eindeutig ist. Der M16C hat ja 5 Ss. und da muss man dann
auch seinen Monitor selbst compilieren, weil der ja nicht wissen kann,
welch der seriellen Ss. man verwendet.
>Eigenartig finde ich auch das der Debugger seine Firmware jedesmal
>neu laedt. Ich dachte der schreibt sich in das Flashrom.
>
Das hätte ich auch erwartet.
>So langsam frag ich mich ob die Probleme nicht mit dem USB->RS232
>Adapter zusammenhaengen. Aber warum sollte das dann erst funktionieren
>und dann nicht mehr. Ausserdem gab es nie eine Fehlermeldung die
>daraufhin deutet.
>Ich teste auf jedenfall mal mit einer normalen RS232 und berichte dann.
Deshalb hatte ich gefragt, ob irgendwas mit Deiner Kommunikation nicht
stimmt.
Dirk
Olaf Kaluza
>Offensichtlich gelingt es dem Debugger Deinen Controller zu flashen!!
Naja, aber das andere Tool konnte ja auch mal flashen! Es hat nur
irgendwann man verlernt das es das kann. :-/
Der Fall ich aber jetzt geklaert. Ich hab mal alles auf meinen
Rervelaptop mit echter RS232 kopiert und da funktioniert das
Flashtool.
Die Dinger laufen also ganz eindeutig nicht mit einem USB->RS232
konverter. Ich verstehe zwar nicht wieso es am Anfang funktioniert
hat, aber immerhin bestaetigt mich das darin das USB->RS232
grundsaetzlich von uebel ist.
>Beim M16C ist dass so, dass man die Interrupts der seriellen Ss. auf
>bestimmte Adressen legen muss (bei Dir im Code). Wenn der KD30 etwas
>an den Controller über die serielle Ss. sendet, wird dann in den
>Monitor gesprungen, der antwortet. Ich kann mir aber gut vorstellen,
>dass das beim R8C unnötig ist, weil der nur eine serielle Ss. hat und
>somit alles eindeutig ist. Der M16C hat ja 5 Ss. und da muss man dann
>auch seinen Monitor selbst compilieren, weil der ja nicht wissen kann,
>welch der seriellen Ss. man verwendet.
Es gibt aber auch R8C mit zwei RS232. Aber das wird ja wohl irgendwo
im Handbuch stehen.
>Deshalb hatte ich gefragt, ob irgendwas mit Deiner Kommunikation nicht
>stimmt.
Das Programm sagt nein. Aber egal, hauptsache man weiss erstmal woran
es liegt. Wenn es dann eines Tages nochmal ein vernuenftiges
Flashprogramm gibt kann man damit arbeiten.
Olaf
Klaus Butzmann
> Und es scheint nur generell nur eine Entwicklerbude für µC Tools zu geben.
> Denn alle sind gleich scheiße.
Du bist nur der falsche Kunde!
Sobald du mit irgendeinem Hersteller mehr als 10..500 Mio$ Umsatz machst
sitzen die Helfer den ganzen Tag neben dir...
Die europäisch/deutschen Sonderfälle ("Wir bauen 100..100.000 Geräte im
Jahr") interessieren niemanden.
Die Halbleiterfuzzis möchten nur riesige Stückzahlen verticken,
Software ist nur ein notwendiges Übel. Und die Japaner haben
Europa immer nur dann bedient wenn das Inlandsgeschäft mau war.
(Erinnert sich noch jemand an die spektakuläre TRON/ITRON Aktion?)
Und für Softwareschmieden ist die Marktnische uC-Tools/Layout und
ähnliches ziemlich eng, und der Aufwand für den Zoo von uC-Derivaten
"jetzt neu mit 25 neuen undokumentierten Bugs" ziemlich groß.
Das Problem habe ich schon seit einem Vierteljahrhundert :-(
Beim 8051 gibt´s ´nen Keil-C, für die AVRs mit Einschänkungen den
CodeVision aber alles drumherum ist meist mit heissen Nadeln gestrickt.
Butzo
p.s
Mit einem 5-pfündigen Ganzstahl-Egalisator werden widerspenstige Chips
ganz schön flach...
Olaf Kaluza
>konverter. Ich verstehe zwar nicht wieso es am Anfang funktioniert
>hat, aber immerhin bestaetigt mich das darin das USB->RS232
>grundsaetzlich von uebel ist.
Vielleicht interssiert es ja einen, aber ich hab es jetzt mit einer
CF-RS232 Karte laufen. Sowas ist kompatibler!
>Es gibt aber auch R8C mit zwei RS232. Aber das wird ja wohl irgendwo
>im Handbuch stehen.
Da war ich wohl zu optimistisch. Die mitgelieferte Hilfe ist ein
Trauerspiel, ein Handbuch ist nirgends aufzufinden.
Ich kann machen was ich will, aber der Druck auf 'GO' ist immer das
letzte was ich machen kann. Dann hilft es nur den KD30 zu toeten.
Er stopt sogar mit der Ausfuehrung an gesetzten Breakpoints, aber man
kann einfach nichts mehr machen. ARGH!
Olaf
Andre Grosse Bley
> Ich kann machen was ich will, aber der Druck auf 'GO' ist immer das
> letzte was ich machen kann. Dann hilft es nur den KD30 zu toeten.
> Er stopt sogar mit der Ausfuehrung an gesetzten Breakpoints, aber man
> kann einfach nichts mehr machen. ARGH!
Wie schon geschrieben: Den Interruptvektor gesetzt und die Interrupts
auch freigegeben? Letzteres hatte mich einige Zeit gekostet bei der
Inbetriebnahme des Boards meiner Diplomarbeit.
Grüße,
Andre
(und ja, die Doku ist leider nicht der Hit :-/)
Dirk Ruth
>Ich kann machen was ich will, aber der Druck auf 'GO' ist immer das
>letzte was ich machen kann. Dann hilft es nur den KD30 zu toeten.
>Er stopt sogar mit der Ausfuehrung an gesetzten Breakpoints, aber man
>kann einfach nichts mehr machen. ARGH!
>
Klingt so, als wenn dann keine Kommunikation mehr mit dem Monitor
möglich ist.
Geht denn der Step-Betrieb?
Wenn Du Dir vor dem GO mal den Memory anzeigen läßt, wohin die
IRQ-Vektoren für die serielle Ss. zeigen, sieht dass dann plausibel
aus?
Hast Du den Stackpointer gesetzt (im Startup)?
Sind die IRQs nicht global abgeschaltet, bzw. global und Ss.
eingeschaltet?
Kannst Du durch die Startup steppen?
Dirk
Olaf Kaluza
>Klingt so, als wenn dann keine Kommunikation mehr mit dem Monitor
>möglich ist.
>Geht denn der Step-Betrieb?
Eine sehr interessante Frage. Ich habs gerade mal ausprobiert.
Es geht eine ganze Weile gut, so 20-30Befehle lang. Dann kommt der
Befehl: jsr.a _init und die Kiste steht.
Wenn ich das richtig sehe ich das die initialisierung bevor main()
aufgerufen wird. Ich hab sie bloss noch nicht gefunden.
>Wenn Du Dir vor dem GO mal den Memory anzeigen läßt, wohin die
>IRQ-Vektoren für die serielle Ss. zeigen, sieht dass dann plausibel
>aus?
Aechz...ganz schoen kompliziert fuer so ein kleinen Prozessor.
Wenn ich das richtig sehe stehen die alle auf 0x9a,0xf7,0x00.
Ich denke auch das dies noch stimmen muss sonst wuerde Step zu begin
nicht funktionieren.
>Hast Du den Stackpointer gesetzt (im Startup)?
Noe, ich hab garnichts mit dem Stack gemacht. Mein Programm ist ja
komplett in C. Da kann ich doch wohl davon ausgehen das der Compiler
das macht.
Ich hab das Programm allerdings im HEW mit der Debug-Option uebersetzt
in der Hoffnung das dies fuer den Debugger notwendig ist.
>Sind die IRQs nicht global abgeschaltet, bzw. global und Ss.
>eingeschaltet?
ICh hab mal, wie von Andre vorgeschlagen, einen Assemblerbefehl zum
einschalten in main() aufgenommen. Hat aber nicht geholfen. Jetzt ist
mir auch klar wieso, er kommt erst garnicht bis main().
>Kannst Du durch die Startup steppen?
Nicht ganz. :)
So wie ich das sehe, kann ich in meinem Programm nichts falsch gemacht
haben weil der Debugger bereits abgeklemmt wird bevor es ausgefuehrt
wird. Es koennte also hoechstens irgendeine Einstellung im HEW
sein. Vielleicht muss fuer den Debugger eine andere Initialisierung
eingebunden werden und das muss man in einer dunklen Ecke bei den
sieben Buttons hinter den Bergen einschalten. :-/
Olaf
p.s: gdb ist schoener.
Andre Grosse Bley
> ICh hab mal, wie von Andre vorgeschlagen, einen Assemblerbefehl zum
> einschalten in main() aufgenommen. Hat aber nicht geholfen. Jetzt ist
> mir auch klar wieso, er kommt erst garnicht bis main().
Ahhh... Der initialisiert dann die standard-I/O... Nimm das mal raus,
die standard-IO richtOCet einen seriellen Port für printf ein. Und wenn Dein
R8 nur einen hat, ist es klar, dass der Debugger die Kommunikation verliert.
Grüße,
Andre
Olaf Kaluza
>Ahhh... Der initialisiert dann die standard-I/O... Nimm das mal raus,
>die standard-IO richtOCet einen seriellen Port für printf ein. Und wenn Dein
>R8 nur einen hat, ist es klar, dass der Debugger die Kommunikation verliert.
Ausgezeichnet! Das war es gewesen jetzt kann man alles laufen lassen und
auch wieder stoppen.
Olaf
Dirk Ruth
"
>Dirk Ruth <d.r...@itecnet.de> wrote:
>
> >Klingt so, als wenn dann keine Kommunikation mehr mit dem Monitor
> >möglich ist.
>
> >Geht denn der Step-Betrieb?
>
>Eine sehr interessante Frage. Ich habs gerade mal ausprobiert.
>
>Es geht eine ganze Weile gut, so 20-30Befehle lang. Dann kommt der
>Befehl: jsr.a _init und die Kiste steht.
>
>Wenn ich das richtig sehe ich das die initialisierung bevor main()
>aufgerufen wird. Ich hab sie bloss noch nicht gefunden.
>
Es muss da eine startup geben. Versuch mal dem "jsr.a _init" mit 'step
into' zu folgen. In der startup wird der RAM gelöscht und statics
initialisiert (Makros: N_BZERO und N_BCOPY). Beim M16C heist das
startup-File: "ncrt0.a30".
>
> >Wenn Du Dir vor dem GO mal den Memory anzeigen läßt, wohin die
> >IRQ-Vektoren für die serielle Ss. zeigen, sieht dass dann plausibel
> >aus?
>
>Aechz...ganz schoen kompliziert fuer so ein kleinen Prozessor.
>
>Wenn ich das richtig sehe stehen die alle auf 0x9a,0xf7,0x00.
>
>Ich denke auch das dies noch stimmen muss sonst wuerde Step zu begin
>nicht funktionieren.
Das sieht gut aus.
>
> >Hast Du den Stackpointer gesetzt (im Startup)?
>
>Noe, ich hab garnichts mit dem Stack gemacht. Mein Programm ist ja
>komplett in C. Da kann ich doch wohl davon ausgehen das der Compiler
>das macht.
>Ich hab das Programm allerdings im HEW mit der Debug-Option uebersetzt
>in der Hoffnung das dies fuer den Debugger notwendig ist.
>
Danach muss der Stackpointer gesetzt werden!!!
Woher soll der Compiler wissen, wohin Du gern Deinen Stack haben
möchtest und wie groß Du ihn denn gern hättest? Woher soll der
Compiler wissen, wie viele IRQs bei Dir gleichzeitig auftreten können
und wie diese priorisiert sind?
Beim M16C sieht das z.B. so aus:
;---------------------------------------------------------------------
; after reset,this program will start
;---------------------------------------------------------------------
ldc #istack_top, isp ;set istack pointer
bset 1,0ah
mov.b #00h,04h ;set processer mode
mov.b #08h,05h ;set reserved area expansion
bit
bclr 1,0ah
bset 0,0ah
mov.b #20h,07h ;set clock control register
mov.b #08h,06h ;to no clock division
bclr 0,0ah
ldc #0080h, flg
ldc #stack_top, sp ;set stack pointer
ldc #data_SE_top, sb ;set sb register
fclr U ;ADD THIS TO SELECT ISP
fset I ;ADD THIS TO ENABLE INTERRUPTS
& STOPPING PROGRAM
ldintb #VECTOR_ADR
_____________________________________________________________________________
[...]
>
>So wie ich das sehe, kann ich in meinem Programm nichts falsch gemacht
>haben weil der Debugger bereits abgeklemmt wird bevor es ausgefuehrt
>wird. Es koennte also hoechstens irgendeine Einstellung im HEW
>sein. Vielleicht muss fuer den Debugger eine andere Initialisierung
>eingebunden werden und das muss man in einer dunklen Ecke bei den
>sieben Buttons hinter den Bergen einschalten. :-/
>
Wenn Du ein x30-File erzeugst, und nur das kann der KD30 laden, dann
sind da alle Infos zum debuggen drin. Zum erzeugen eines s19-Files
wird dann ein anderer Linker verwendet. Irgendwas stimmt in Deiner
startup nicht.
Aber zum Glück hast Du ja den KD30 und kannst Dich da durchwühlen. Mit
PIC/AVR hättest Du jetzt ein echtes Problem.
Dirk
Dirk Ruth
A ja, dann scheint es bei Dir nun zu laufen.
Nun kannst Du dann ja auch zurücknehmen, dass der Renesas R8C Murks
ist ;-))
Dirk
Olaf Kaluza
>Danach muss der Stackpointer gesetzt werden!!!
>Woher soll der Compiler wissen, wohin Du gern Deinen Stack haben
>möchtest und wie groß Du ihn denn gern hättest? Woher soll der
>Compiler wissen, wie viele IRQs bei Dir gleichzeitig auftreten können
>und wie diese priorisiert sind?
Ich hab in meinem ganzen Leben noch nie einen Stackpointer bei einem
Compiler gesetzt. Woher soll ICH denn wissen wie er es gerne haette
und wieviel Platz er braucht.
>Beim M16C sieht das z.B. so aus:
Das sieht hier auch so aus. Aber das hat natuerlich der Compiler
gemacht. Ich hab da nicht dran rumgefummelt.
>Aber zum Glück hast Du ja den KD30 und kannst Dich da durchwühlen. Mit
>PIC/AVR hättest Du jetzt ein echtes Problem.
Nana. Mit AVR und Dragonball hatte ich diese Probleme nicht.
Olaf
Olaf Kaluza
>Nun kannst Du dann ja auch zurücknehmen, dass der Renesas R8C Murks
>ist ;-))
Ne! Die angesprochenen Macken des Brennprogramm bleiben. Und die
Dokumentation ist das GRAUEN.
Ich hab ja das Glueck sehr viel English zu reden mit einer
Japanerin. :) Ich bin also mit so manchen Eigenheiten vertraut
trotzdem muss ich gelegentlich seufzen wenn ich die Doku lese. Ich
wuesste mal gerne was ein Englaender denkt der die liesst.
Gerade habe ich mir mal angeschaut wie man den Compiler veranlasst
Funktionen im Interrupt aufzurufen. Das wirkt ein bisschen
nachtraeglich beigestrickt.
Wenn sich diese Controller auch in Deutschland ernsthaft verbreiten
dann wird es Zeit das mal jemand ein Buch schreibt. Hm..ich glaub ich
muss mal jemanden anrufen und ihn auf diesen Missstand aufmerksam
machen.
Olaf
Stefan Nöhammer
> Bei Freescale z.B. muß man IRQ-Pin auf 8V anheben.
> Muß den PA0-Pin hochohmig bekommen sodaß er bidirektional
> halbduplex die V24 macht. Andere PIns auf GND oder 5V ziehen.
> Muß alles in der Entwicklung der Hardware berücksichtigt
> sein, sonst hat man mit eingelötetem FLASH keine Freude.
Was mich dabei stört fürs erste mal (Resetvektor=0xFFFF) genügt es wenn
nur IRQ auf low (läuft dann auch mit internem Clk).
Wieso muß ich dann wenn ich weiter in den Monitor will diesen ganzen
Aufwand (HighVoltage,ext.Clk,versch. Pins) treiben...
Haben die Angst man kommt versehentlich in den Monitor?
(geht beim T89C51CC01 wunderbar mit einem Pin...)
/Stefan
Andre Grosse Bley
Es freut mich, dass ich Dir helfen konnte ;)
> Ne! Die angesprochenen Macken des Brennprogramm bleiben. Und die
> Dokumentation ist das GRAUEN.
Für ersteres gibt es zum Glück die wesentlich bessere Variante von
microcontroller.net. Der "Profi" wird eher den "Flasher" der Firma
Segger benutzen. Der kommt dank synchroner Übertragung dann auch mit
krummen Quarztakten klar. Sonst ist es auch nicht wirklich schwer dieses
Protokoll selbst zu implementieren. Wenn man denn irgendwo Dokumentation
dadrüber findet. Ich hab sie durch Zufall in einem Datenblatt eines
Vorgängers entdeckt. (M16C62)
> trotzdem muss ich gelegentlich seufzen wenn ich die Doku lese. Ich
> wuesste mal gerne was ein Englaender denkt der die liesst.
Ich habe mich da auch schon öfters gefragt, ob ich zu dumm bin, die
Renesas-Datenblätter/Dokumentationen zu verstehen.
> Wenn sich diese Controller auch in Deutschland ernsthaft verbreiten
> dann wird es Zeit das mal jemand ein Buch schreibt. Hm..ich glaub ich
> muss mal jemanden anrufen und ihn auf diesen Missstand aufmerksam
> machen.
Sonst gibt's da noch IAR und Tasking als Compilerlieferant. Aber die
kosten gleich sehr viel Geld. In der Firma setzen wir IAR ein. Version 3
der EWM16C scheint mehr zu taugen, auch wenn ein Tag zum portieren des
Quelltextes von Version 1 draufging. :-/
Beim Renesas-Compiler habe ich mich desöfteren bei Fehlermeldungen gefragt,
was das Teil denn von mir will. Und manche Fehlermeldungen sind einfach
viel zu freundlich für mich formuliert :)
Diese HEW scheint ursprünglich vom Hitachi zu stammen und hat meiner Meinung
nach den M16C Support drangeflickt. Und geht nicht wirklich sparsam mit den
Resourcen um. Auf meinem P-II 400 Laptop ist das editieren von Quelltext im
Editor schon eine Qual!
Ein gcc wäre sicherlich was feines für das Teil.
Grüße,
Andre
Olaf Kaluza
>Resourcen um. Auf meinem P-II 400 Laptop ist das editieren von Quelltext im
>Editor schon eine Qual!
Also das wiederum kann ich nicht sagen. Ich hab das hier alles auf
meinem neuen schnuckeligen Miniaturlaptop gemacht und der hat einen
TransMeta Crusoe mit 867MHz und eine relativ lahme 1.8" Platte. Das
duerfte von der Geschwindigkeit her vergleichbar sein da der Crusoe
langsamer ist als der Takt einem glauben laesst. Und da kann ich
eigentlich nicht drueber meckern.
Olaf
Rafael Deliano
> es wenn nur IRQ auf low (läuft dann auch mit internem Clk).
Halte ich aber aus genannten Gründen nichts davon: man muß
z.B. in Lagerware neue Software einspielen und Rückläufer
analysieren können.
> Wieso muß ich dann wenn ich weiter in den Monitor will diesen
> ganzen Aufwand (HighVoltage,ext.Clk,versch. Pins) treiben...
Bei interner RC-Clock ist die Toleranz ( +/-20% ehedem ) zu groß
als daß es mit Baudrate für UART an jedem PC passen könnte.
> Haben die Angst man kommt versehentlich in den Monitor?
Berechtigte. Wenn Controller in verseuchter Umgebung arbeiten
können sie saftig abstürzen. Monitor bedeuted ja auch: Watchdog
abgeschaltet.
MfG JRD
Dirk Ruth
"
>Dirk Ruth <d.r...@itecnet.de> wrote:
>
>
> >Danach muss der Stackpointer gesetzt werden!!!
> >Woher soll der Compiler wissen, wohin Du gern Deinen Stack haben
> >möchtest und wie groß Du ihn denn gern hättest? Woher soll der
> >Compiler wissen, wie viele IRQs bei Dir gleichzeitig auftreten können
> >und wie diese priorisiert sind?
>
>Ich hab in meinem ganzen Leben noch nie einen Stackpointer bei einem
>Compiler gesetzt. Woher soll ICH denn wissen wie er es gerne haette
>und wieviel Platz er braucht.
>
Das steht in den einzelnen List-Files, wie groß beim Compilieren die
Bereiche geworden sind und sieht dann z.B. so aus:
-------------------------------------
Section List
Attr Size Name
CODE 0001633(00661H) program
DATA 0000262(00106H) data_NE
DATA 0000003(00003H) data_NO
ROMDATA 0000262(00106H) data_NEI
ROMDATA 0000003(00003H) data_NOI
DATA 0000244(000F4H) bss_NE
-------------------------------------
Die Bereiche (Stack, Data near, Data far usw.) müssen z.B. auch beim
IAR eingestellt werden. Beim Mitsubishi-Compiler und M16C gibt es dazu
das File "sect30.inc". Es könnte ja auch z.B. sein, dass Du Deinen
Stack gar nicht im internen, sondern im externen RAM haben willst usw.
>
> >Beim M16C sieht das z.B. so aus:
>
>Das sieht hier auch so aus. Aber das hat natuerlich der Compiler
>gemacht. Ich hab da nicht dran rumgefummelt.
>
Wie schon geschrieben wird beim Mitsubishi-Compiler und M16C im File
"ncrt0.a30" der Stack und die variable IRQ-Table gesetzt. Dieses File
wird nicht! vom Compiler erzeugt, aber wohl als Beispiel mitgeliefert.
Es liegt auch nur in Assembler vor. Lösche mal das File und Du wirst
sehen, der Comier erzeugt kein neues und der Linker wirft Dir ein
ganzes Füllhorn voll Fehlermeldungen um die Ohren.
>
> >Aber zum Glück hast Du ja den KD30 und kannst Dich da durchwühlen. Mit
> >PIC/AVR hättest Du jetzt ein echtes Problem.
>
>Nana. Mit AVR und Dragonball hatte ich diese Probleme nicht.
>
Der AVR hat nicht die Möglichkeit auf dem Chip zu debuggen, d.h.
teuren Emulator kaufen. Und warum? Weil die bei Atmel offensichtlich
nicht in der Lage sind, priorisierte IRQs und 2 Address match IRQs zu
spendieren. Aber inzwischen sind sie ja schon mal soweit, dass sich
der AVR selbst umprogrammieren kann. Selbst für den uralten 68HC11
gibt es eine ähnliche kleine Möglichkeit zum debuggen (pcbug11). Für
AVRs habe ich sowas noch nicht gesehen, obwohl das gerade für
beginners von Vorteil wäre.
Kann man den Dragonball irgendwo kaufen? Was kostet der? Ist da ein
kostenloser Compiler mit dabei?
Dirk
Olaf Kaluza
>Wie schon geschrieben wird beim Mitsubishi-Compiler und M16C im File
>"ncrt0.a30" der Stack und die variable IRQ-Table gesetzt. Dieses File
>wird nicht! vom Compiler erzeugt, aber wohl als Beispiel mitgeliefert.
Ich weiss, ich hab das mittlerweile auch gesehen. Ich lass da aber
erstmal die Finger raus.
>Es liegt auch nur in Assembler vor. Lösche mal das File und Du wirst
>sehen, der Comier erzeugt kein neues und der Linker wirft Dir ein
>ganzes Füllhorn voll Fehlermeldungen um die Ohren.
Momentan liefert der Compiler und der Linker keine Fehlermeldungen,
dafuer stuerzt HEW gerne mal ab seitedem ich 4 Source und 4 Header
Files benutze. Es wird wirklich Zeit das ich mir den Emacs
installiere.
>>Nana. Mit AVR und Dragonball hatte ich diese Probleme nicht.
Mir ist uebrigens gerade beim portieren von Software aufgefallen das
der R8C _ungefaehr_ in derselben Liga spielt wie ein 68k bei gleichem
Takt.
>Kann man den Dragonball irgendwo kaufen? Was kostet der? Ist da ein
>kostenloser Compiler mit dabei?
Kommt drauf an. Der Dragonball ist in den alten Palms und macht IMHO
fuer die meisten Leute wenig Sinn da die das LCD Interface nicht
brauchen. Es gibt aber Typen die haben das nicht. Ich vergess nur
immer die Nummer (68k332?).
Das ist aber eigentlich eine andere Liga. Du brauchst auf jedenfall
externes Ram/Rom. (4-6Lagen Multilayer) Es gibt den gcc. Du kannst
ueber ein BDI Interface mit dem gbd auf dem Prozessor arbeiten.
Und besonders suess ist das der Proz dann noch einen zweiten Prozessor
fuer IO-Kram enthaelt.
Olaf
Dirk Ruth
>Momentan liefert der Compiler und der Linker keine Fehlermeldungen,
>dafuer stuerzt HEW gerne mal ab seitedem ich 4 Source und 4 Header
>Files benutze. Es wird wirklich Zeit das ich mir den Emacs
>installiere.
>
Hab mal vor langer Zeit (Linux 0.9xx) den Emacs installiert und
gesehen, dass man erst Lisp lernen muss. Da hab ich den Gedanken
gleich wieder verworfen. Vielleicht ist das aber inzwischen besser
geworden. Ich verwende hier Visual Slick Edit und bin zufrieden.
Codewright ist wohl auch nicht schlecht. Im Prinzip geht aber auch
Visual Studio.
> >>Nana. Mit AVR und Dragonball hatte ich diese Probleme nicht.
>
>Mir ist uebrigens gerade beim portieren von Software aufgefallen das
>der R8C _ungefaehr_ in derselben Liga spielt wie ein 68k bei gleichem
>Takt.
>
> >Kann man den Dragonball irgendwo kaufen? Was kostet der? Ist da ein
> >kostenloser Compiler mit dabei?
>
>Kommt drauf an. Der Dragonball ist in den alten Palms und macht IMHO
>fuer die meisten Leute wenig Sinn da die das LCD Interface nicht
>brauchen. Es gibt aber Typen die haben das nicht. Ich vergess nur
>immer die Nummer (68k332?).
Also eher schlecht zu bekommen.
>
>Das ist aber eigentlich eine andere Liga. Du brauchst auf jedenfall
>externes Ram/Rom. (4-6Lagen Multilayer).
Ganz schlecht.
> Es gibt den gcc. Du kannst
>ueber ein BDI Interface mit dem gbd auf dem Prozessor arbeiten.
Braucht man für das BDI spezielle Hardware? Hört sich an wie JTAG.
>Und besonders suess ist das der Proz dann noch einen zweiten Prozessor
>fuer IO-Kram enthaelt.
Dirk
Olaf Kaluza
>Braucht man für das BDI spezielle Hardware? Hört sich an wie JTAG.
Ich hab so einen Adapter fuer den Druckerport.
Olaf
Matthias Weingart
news:429C2876...@t-online.de:
> Aber MSP430 ist jetzt fast 10 Jahre alt, ein bisschen
Mhh die Familie ist 10J. alt. Der '149 nicht. Und wenn du "alte"
Klamotten einsetzt, dann bistu ja auch selber Schuld ;-). Man nimmt ja
jetzt auch den '169 oder '1611 (von letztem Jahr) schon allein weil der
'ne verbesserte Debugging Einheit hat.
> ausgereifter könnte die Dokumentation und die Fehlerbehebung
> schon sein.
Also die Menge der Docu erschlägt einen. Ich habe hier 200 Dateien,
100MB pdf's + zips nur von TI! Man darf nicht nur die 2 trockenen
Datenblaetter lesen, sondern muss sich unbedingt die Beispiele und
App.-Notes holen! (Metering Handbook ist zwar noch für die erste
Generation, aber unbedingte Lesepflicht! :-).
> Das Errata-Blatt ist 13 Seiten mit 4 Bugs pro Seite.
> Beim Bootloader ( 3 Bugs ) z.B. "The bootstrap loader SW cannot
> program the flash memory, software workaround available" Was
> der Fehler genau ist und wo man den Patch findet wird einem
> aber nicht verraten. Ich habe auch nicht den Eindruck, daß
> die Masken geändert werden, wird wohl munter mit Bugs
> weiterproduziert.
Im praktischen Einsatz hat mich bisher noch keiner
der (alten) Bugs berührt. Im Prinzip sind die Listen nur schlechtes
Marketing, man könnte die "Quirks" da auch einfach mit in das
Datenblatt schreiben. Die Bugs werden nicht behoben, weil sie einfach
irrelevant sind. Manche 'behebt' der Assembler (Compiler), bei manchen
muss man halt einen (meist) einfachen Würgaround tun.
Der '149 wird mittlerweile in Revision Q(?) verkauft. Die muessen da
ziemlich viel dran gemacht haben (schliesst neben Bugbehebung aber auch
Prozesswechsel usw. mit ein).
Naja sicherlich hat auch der MSP430 so seine Probleme, die ich hier
jetzt aber nicht anführen werde. :-).
M.
--
Bitte auf mwn...@pentax.boerde.de antworten.
Michael Dreschmann
>Der AVR hat nicht die Möglichkeit auf dem Chip zu debuggen, d.h.
>teuren Emulator kaufen. Und warum? Weil die bei Atmel offensichtlich
>nicht in der Lage sind, priorisierte IRQs und 2 Address match IRQs zu
>spendieren. Aber inzwischen sind sie ja schon mal soweit, dass sich
>der AVR selbst umprogrammieren kann. Selbst für den uralten 68HC11
>gibt es eine ähnliche kleine Möglichkeit zum debuggen (pcbug11). Für
>AVRs habe ich sowas noch nicht gesehen, obwohl das gerade für
>beginners von Vorteil wäre.
Na also das kann ich so auch nicht stehen lassen, zumindest nicht für
die grösseren AVRs...
Für 50€ bekommste nen JTAG Debugger (bzw. kannst ihn dir wie auf ein
paar Webseiten beschrieben für weniger Geld auch selbst basteln). Da
brauchste dann auch nicht erst nen Monitor reinladen, die serielle
Schnittstelle zu besetzten und vorher noch Interruptvektoren
anzupassen. Und wenn sich die ext. Taktfrequenz deines AVR verändert
macht das auch nix (hab hier so ein Design mit nem M16C, und das ist
grauenhaft). Ausserdem hängt sich das AVR Studio bei nem
Verbindungsabbruch zum Controller nicht gleich auf, so dass man
erstmal den Taskmanager rauskramen muss, so wie das beim KD30 is...
Ich will damit nicht sagen, dass ich den Emulator für den M16C
besonders schlecht finde, aber dass AVRs da nicht mithalten können
simmt so auch nicht...
Viele Grüsse,
Michael
Dirk Ruth
"
>Hallo,
>
[...]
>Na also das kann ich so auch nicht stehen lassen, zumindest nicht für
>die grösseren AVRs...
>Für 50€ bekommste nen JTAG Debugger (bzw. kannst ihn dir wie auf ein
>paar Webseiten beschrieben für weniger Geld auch selbst basteln).
Hm also Reichelt sagt mir 399,- EUR
> Da
>brauchste dann auch nicht erst nen Monitor reinladen, die serielle
>Schnittstelle zu besetzten und vorher noch Interruptvektoren
>anzupassen. Und wenn sich die ext. Taktfrequenz deines AVR verändert
>macht das auch nix (hab hier so ein Design mit nem M16C, und das ist
>grauenhaft). Ausserdem hängt sich das AVR Studio bei nem
>Verbindungsabbruch zum Controller nicht gleich auf, so dass man
>erstmal den Taskmanager rauskramen muss, so wie das beim KD30 is...
>Ich will damit nicht sagen, dass ich den Emulator für den M16C
>besonders schlecht finde, aber dass AVRs da nicht mithalten können
>simmt so auch nicht...
Man könnte den KD30 sicher noch verbessern, aber als null cost Lösung
finde ich den nicht so schlecht.
Unabhängig davon hat mir der AVR mit 4K zuwenig RAM, da ich hier
µCosII darauf laufen habe. Ich könnte mich ansonsten noch für den
H8/3069 erwärmen, aber da gibt's keinen KD30.
>
>Viele Grüsse,
> Michael
Michael Dreschmann
>Hm also Reichelt sagt mir 399,- EUR
Jo, wenn du dir das teuere Original Teil von Atmel besorgst. Das hier
kann z.B. das selbe (hab ich selbst ausprobiert):
http://www.sander-electronic.de/es0001.html
>Man könnte den KD30 sicher noch verbessern, aber als null cost Lösung
>finde ich den nicht so schlecht.
Sag ich ja nicht, aber schlecher als der von den AVRs :)
>Unabhängig davon hat mir der AVR mit 4K zuwenig RAM, da ich hier
>µCosII darauf laufen habe. Ich könnte mich ansonsten noch für den
>H8/3069 erwärmen, aber da gibt's keinen KD30.
Es ging mir nur darum zu sagen, dass es für AVRs sehr wohl einen guten
Emulator gibt. Dass die ansonsten in ner anderen Liga spielen als ein
M16C ist ja klar...
Michael
Joerg Wunsch
> Hab mal vor langer Zeit (Linux 0.9xx) den Emacs installiert und
> gesehen, dass man erst Lisp lernen muss.
Du musst das Lisp ungefähr so sprechen, wie den Hexcode deines
Controllers, obwohl du ihn in C programmieren willst. ;-) Sprich, kann
zuweilen ganz nützlich sein, ist aber keineswegs Voraussetzung.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Joerg Wunsch
> Hm also Reichelt sagt mir 399,- EUR
Das dürfte übrigens der mkII sein, mit dem du auch die neuen kleinen
AVRs online debuggen kannst (über eine Art 1-wire Protokoll, das noch
dazu auf dem /RESET-Pin gesprochen wird, dir also nichtmal eine
IO-Leitung klaut). Habe ich aber selbst noch nicht probiert. Der
mkII ist intern einiges aufwendiger als der mkI (zweimal ATmega128
plus USB-Chip plus Hühnerfutter im Vergleich zu einmal ATmega16 plus
Hühnerfutter).
Rafael Deliano
( sporadisch ). Spart man sich die Lötakrobatik.
>> ausgereifter könnte die Dokumentation und die Fehlerbehebung
>> schon sein.
> Also die Menge der Docu erschlägt einen. Ich habe hier 200 Dateien,
Masse ist nicht Klasse.
Ich wühle in: 430-Manual, plus Errata für dieses; Datenblatt des F149,
plus Errata für dieses; zwei ApplicationNotes für den Bootloader die
Zeug
erklären das eigentlich ins Manual gehören. Die Hex-File Schnippsel
für die Bootloader-Patches waren bei Ti gar nicht so direkt zu finden,
die hat google aus anderen Websites gefischt.
Die könnten ihren Fundus mal konsolidieren und das relevante Zeug
in 430-Manual und jeweiligem Controller-Datenblatt unterbringen.
> (Metering Handbook ist zwar noch für die erste Generation, aber
> unbedingte Lesepflicht! :-).
Werd mal suchen. Was für Quarze muß man eigentlich an XT1 bzw XT2
hängen daß der Bootloader wirklich mit 9600 Baud kommt ?
> Die Bugs werden nicht behoben, weil sie einfach
> irrelevant sind. Manche 'behebt' der Assembler (Compiler),
> bei manchen muss man halt einen (meist) einfachen Würgaround tun.
Der CPU4-Bug in den Errata des Controllers gehört eigentlich ins
430-Manual da ja Defekt im Befehlssatz des Prozessors. Da ich den
Assembler selber schreibe habe ich den Bugfix nicht automatisch.
Zudem will der Programmierer ja schon beim Schreiben der Source
wissen was nicht geht. Eine Fehlermeldung oder ein "geheimer"
automatischer Patch aus mehreren Opcodes ist nicht so erwünscht.
> Der '149 wird mittlerweile in Revision Q(?) verkauft.
Wenn ich nach den Häcklchen in der Bugliste gehe hat der 149 Q
alle Bugs des N nur der Prozess ist eventuell geändert worden.
MfG JRD
Matthias Weingart
>> Und wenn du "alte" Klamotten einsetzt, dann bistu ja auch selber
>> Schuld ;-).
> Phlegma: 430F149 Rev N gibts für 16 EUR auf Adapter aufgelötet bei
> ebay ( sporadisch ). Spart man sich die Lötakrobatik.
Wieso. Das ist auch so eine feine Sache mit dem MSP430ichs. Die im
gleichen Gehäuse sind alle pinkompatibel! Der '169 oder '1611 passt
problemlos in die '149er Sockel und die Programmiergeräte. Da ist
keine Änderung nötig! (Nur die Software muss den neuen Chip kennen).
Und von TI gibts ja 5 Muster umsonst. Solche Adapterplatinen von
Olimex (mit oder ohne aufgelöteten Chip).
>>> ausgereifter könnte die Dokumentation und die Fehlerbehebung
>>> schon sein.
>> Also die Menge der Docu erschlägt einen. Ich habe hier 200
>> Dateien,
> Masse ist nicht Klasse.
Das stimmt; ist so ein Mangel, und finden und sortieren muss man den
Kram auch erstmal. Die CD die TI so halbjährlich (?) herausbringt
spart da ein bisschen Zeit. Das ist da besser sortiert.
Der Controller ist ziemlich komplex. Im Vergleich zu 8051's vor 10
Jahren so 5mal mehr komplexer. (mhh da hatte ich nur 3 Register für
die serielle, jetzt sind es 8 16bit Register!
Man kann sehr viel damit machen, so viel das TI es kaum geschafft
hat, die Docus da zeitgleich mit den Controllern rauszubringen. Die
App-Notes und Beispiele kamen dann so nach und nach heraus. Die Docu
ist sozusagen "gewachsen". Das liegt daran, das da wohl auch nur
wenige Leute dran arbeiten und jede App-Note natuerlich auch ihre
Zeit braucht, um ausgearbeitet zu werden.
> Was für Quarze muß man eigentlich an XT1 bzw XT2
> hängen daß der Bootloader wirklich mit 9600 Baud kommt ?
Egal! Das läuft nur mit dem DCO. (Der misst am ersten Byte aus, wie
das Timing ist). Das Teil braucht nur Betriebsspannung und die
Leitungen zum Adapter. Man kann sich (später) auch seinen eigenen
"Bootloader" schreiben, je nachdem, wie die Anbindung zum Hostsystem
realisiert ist. Direkter Zugriff auf den Flash ist einfach möglich,
du hebst die Verriegelung auf, indem du ein paar Werte in ein paar
SFR's schreibst und dann kannst du direkt auf die Flash-Adressen
schreiben. Das Timing macht er dann selber. Man sollte nur die
Interrupts und den Watchdog sperren. Uebrigens ist die Stromaufnahme
für das Flashschreiben bei 0.3mA. Wenn ich das mit den 30mA für
Dataflash vergleiche ... (man hat keine Probleme mit dem Einbrechen
der Batteriespannung, wenn die Batterie nur klein ist).
> Da ich den
> Assembler selber schreibe habe ich den Bugfix nicht automatisch.
Harhar. Das glaub ich jetzt aber mal nicht wirklich. :-)
Wenn wir alles genau wissen wollten, dann würden wir ja nie fertig
werden. So ein gewisses Abstraktionslevel ist doch sehr praktisch,
man spart viel Zeit. Mich stört auch nicht, das das JTAG-
Debugginterface nicht zu 100% veröffentlicht ist. Hauptsache das Tool
funktioniert, wie und warum genau - interessiert micht nicht!
Darum verwende ich auch lieber C als ASM (man spart viel Zeit, man
hat erste Projekte schon am laufen, bevor man ueberhaupt den
Assembler richtig verstanden hat). Beim uC-Programieren gilt auch die
abgewandelte Messtechnikregel: "Nur so viel wissen wie nötig, nicht
soviel wie möglich." Sofern alles läuft ist das gut; wenn man aber
nen vertrackten Bug hat, dann ist mehr Wissen natürlich besser.
Bisher lagen die vertrackten Bugs aber alle an mir und Brain 0.9 ;-).
> Zudem will der Programmierer ja schon beim Schreiben der Source
> wissen was nicht geht. Eine Fehlermeldung oder ein "geheimer"
> automatischer Patch aus mehreren Opcodes ist nicht so erwünscht.
Klar sollte man vorher mal ins Errata schauen, ob ein Bug da einen
betrifft. Die wirklich schlimmen Bugs stehen uebrigens nicht im
Errata. Die I2C-HW bei den neuen '169 soll noch nen Fehler haben.
(mhh habe noch gar nicht in die neuen Erratas geguckt).
Rafael Deliano
>> hängen daß der Bootloader wirklich mit 9600 Baud kommt ?
> Egal! Das läuft nur mit dem DCO. (Der misst am ersten Byte
> aus, wie das Timing ist).
werkeln.
>> Da ich den
>> Assembler selber schreibe habe ich den Bugfix nicht automatisch.
> Harhar. Das glaub ich jetzt aber mal nicht wirklich. :-)
Der Assembler/Disassembler ( in FORTH, soll ja auf dem Chip
laufen ) ist schon fertig ( allerdings noch nicht debugged ),
braucht weniger Speicher als für 68HC08 weil der Befehlssatz
einheitlicher ist.
> Darum verwende ich auch lieber C
Ich vermute das compiliert auf MPS430 auch relativ effizient.
Allerdings ist die Achillesferse einer 16 Bit CPU mit 64kByte
MemoryMap ( byteadressiert, sonst wärens wenigstens 128kByte )
daß der Speicher bei HLL schnell knapp werden kann.
Gedenke das FORTH "halbinterpretierend" auszuführen und nicht
direkt Assembler um Speicher zu sparen.
MfG JRD
Matthias Weingart
>>> Da ich den
>>> Assembler selber schreibe habe ich den Bugfix nicht automatisch.
>> Harhar. Das glaub ich jetzt aber mal nicht wirklich. :-)
> Der Assembler/Disassembler ( in FORTH, soll ja auf dem Chip
> laufen ) ist schon fertig ( allerdings noch nicht debugged ),
> braucht weniger Speicher als für 68HC08 weil der Befehlssatz
> einheitlicher ist.
Ja, ne feine Sache die 100% Orthogonalität.
>> Darum verwende ich auch lieber C
> Ich vermute das compiliert auf MSP430 auch relativ effizient.
> Allerdings ist die Achillesferse einer 16 Bit CPU mit 64kByte
> MemoryMap ( byteadressiert, sonst wärens wenigstens 128kByte )
> daß der Speicher bei HLL schnell knapp werden kann.
Es soll ja auch mal Typen mit mehr Flash geben. Bin ja mal gespannt,
wie die das dann aufbohren werden (ich hoffe nicht mit Banking bzw
Segmenten ;-(.
TI wirbt zwar damit, das der MSP430 viel weniger Code braucht,
als z.B. der AVR, aber interessanterweise hat Paul (Hersteller von den
Crossworks-Tools für beide) mal die Zahlen eines Benchmarks gepostet.
Auf seinen (ziemlich gut optimierenden) Compilern belegte es fast
gleich viel Flash. Der MSP430 war wegen seine HW-Multiplizierers aber
schneller. (Naja, glaube keinem Benchmarks, den Du nicht selbst
gefälscht hast :-).
Rafael Deliano
> "Bootloader" schreiben,
Probleme wie üblich die Dokumentation:
* daß man die Sequenz SYNC=80h gefolgt von
Antwort DATA_ACK=90h nichtnur einmal nach
PowerUp sondern zwischen jedem Datenpaket
braucht fand ich nicht in den ApplicationNotes.
* daß man am Anfang des RAMs ( bis wohin ? )
besser nichts reinschreibt, weil das der
interne Bootloader benutzt und daraufhin
abstürzt fand ich auch nicht beschrieben.
Mal sehen was da noch alles wurmt.
MfG JRD
Matthias Weingart
Achso du lädst mit dem Bootloader Daten in das RAM?
Dann ist das klar. Das der Bootloader Code im RAM hat, war mir
zumindest immer schon klar (muss doch irgendwo stehen), wie lang der
Speicherbereich ist, ist wohl wirklich nirgends beschrieben. Vermutlich
ändert sich das sogar noch von Loader zu Loader Version. Frag doch mal
Paul oder Steve (du brauchst Infos die normalerweise nur Toolwriter
kriegen, TI hält sowas für die Allgemeinheit unter Verschluss). (Sprich
frag in den Mailinglisten mspgcc.souceforge.net oder
groups.yahoo.com/msp430). Alternativ könntest du auch versuchen direkt
zu den Leuten von TI Kontakt zu bekommen (sitzen glaube in Garching).
Die haben auch schon infos an die gcc-comunity rausgegeben (allerdings
ist das Ergebnis closed source).
Rafael Deliano
> zumindest immer schon klar (muss doch irgendwo stehen),
ein Unterprogramm der Firmaware temporär auf dem
Stack benutzt wenn man es aufruft.
> Vermutlich ändert sich das sogar noch von Loader
> zu Loader Version.
Den Softwarepatch für den V1.10 Firmwarebug laden sie
ab 220h also wohl die ersten 20h Bytes.
Meine Neigung von TI irgendwas anderes als den V1.10
Befehlssatz zu verwenden ist übers Wochenende drastisch
gesunken: weitere Funktionen selber entwickeln und
ins RAM laden ist wohl effizienter als schlecht
dokumentierte "fertige & kostenlose" Software zu
verwenden.
> (du brauchst Infos die normalerweise nur Toolwriter
> kriegen, TI hält sowas für die Allgemeinheit unter
> Verschluss).
Das ist das was ich sehr ungern höre. JTAG ist für Anwender
nicht relevant, da störts mich nicht. Beim Bootloader sehe
ich das anders, braucht man für in-circuit Programmierung
des FLASH.
Andererseits: jetzt wo ichs am laufen habe, kann ich die
Firmware ohnehin auslesen und disassemblieren.
Hoffe da Routinen zur Programmierung des FLASHs
zu finden die später das FORTH anspringen kann.
> groups.yahoo.com/msp430
Die yahoo-groups sind an sich eine gute Idee, aber
irgendwie ist Navigation & Suche innerhalb etwas mühsam.
MfG JRD
Matthias Weingart
>> (du brauchst Infos die normalerweise nur Toolwriter
>> kriegen, TI hält sowas für die Allgemeinheit unter
>> Verschluss).
> Das ist das was ich sehr ungern höre. JTAG ist für Anwender
Allgemeine Paranoia halt ;-).
> nicht relevant, da störts mich nicht. Beim Bootloader sehe
> ich das anders, braucht man für in-circuit Programmierung
> des FLASH.
Der Bootloader ist eigentlich irrelevant, da du dir eigentlich Deinen
Eigenen schreiben solltest. Den Bootloader von TI braucht du eigentlich
nur zum allerersten Download deines eignen Bootloaders (oder eben das
JTAG).
> Andererseits: jetzt wo ichs am laufen habe, kann ich die
> Firmware ohnehin auslesen und disassemblieren.
> Hoffe da Routinen zur Programmierung des FLASHs
> zu finden die später das FORTH anspringen kann.
Es ist eigentlich alles als APP-Note da. Es gibt die APP-Notes zum
Thema Flash slaa103, slaa123, slaa149 und welche zur seriellen
Schnittstelle per Timer-Capture (wie es der Bootloader macht): slaa078a
und slaa083
>> groups.yahoo.com/msp430
> Die yahoo-groups sind an sich eine gute Idee, aber
> irgendwie ist Navigation & Suche innerhalb etwas mühsam.
Das einzige was brauchbar ist, ist die Mailingliste (klar den webmüll
dort kannst du wegschmeissen). Da kannst du ganz normal per Mail
subscriben.
Oder lies es einfach über news.gmane.org. Die Gruppe ist
gmane.comp.hardware.texas-instruments.msp430.discuss