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...
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.
Jo, wenn du dir das teuere Original Teil von Atmel besorgst. Das hier kann z.B. das selbe (hab ich selbst ausprobiert):
formatting link
Sag ich ja nicht, aber schlecher als der von den AVRs :)
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...
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. ;-)
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).
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Phlegma: 430F149 Rev N gibts für 16 EUR auf Adapter aufgelötet bei ebay ( sporadisch ). Spart man sich die Lötakrobatik.
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.
Werd mal suchen. Was für Quarze muß man eigentlich an XT1 bzw XT2 hängen daß der Bootloader wirklich mit 9600 Baud kommt ?
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.
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.
Rafael Deliano wrote in news: snipped-for-privacy@t-online.de:
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).
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.
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).
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 ;-).
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).
Hört sich gut an, werde ich am Wochende mal wieder am MPS430 werkeln.
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.
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.
Rafael Deliano wrote in news: snipped-for-privacy@t-online.de:
Ja, ne feine Sache die 100% Orthogonalität.
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 :-).
Ich hab die Schnittstelle jetzt am laufen. 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.
Rafael Deliano wrote in news: snipped-for-privacy@t-online.de:
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).
Bei Freescale gibts sogar Angaben wieviel Bytes ein Unterprogramm der Firmaware temporär auf dem Stack benutzt wenn man es aufruft.
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.
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.
Die yahoo-groups sind an sich eine gute Idee, aber irgendwie ist Navigation & Suche innerhalb etwas mühsam.
Rafael Deliano wrote in news: snipped-for-privacy@t-online.de:
Allgemeine Paranoia halt ;-).
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).
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
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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.