Hallo an alle Ich möchte ein AVR-code in einen Pic schreiben und wollte wissen ob es einen decompiler dafür gibt Oder hat jemand eine andere lösung mfg FK
In C vielleicht, in Assembler fast unmöglich. Die Befehlssätze sind einfach zu unterschiedlich. Und viele Sachen muß man auf eine völlig andere Art lösen (Pointer, Stack, Tabellen, Interruptvektoren, 16/32Bit Operationen usw.) Machbar erscheint mir nur, das Programm auf dem PIC nochmal von Null an neu zu schreiben, so das es funktional gleich ist. Wie groß ist denn das AVR-Programm ? Warum willst Du denn überhaupt sowas verrücktes machen ? Peter
Da hat Peter mehr als recht. Obwohl die Frage gar nicht so verkehrt ist. Von Paralax gab es mal einen Assembler, den konnte man auch mit 8051 ASM (habs nie benutz, könnte auch ein anderer gewesen sein) füttern. Die Assemblerbefehle wurden dann einfach per Macro in die für den PIC funktionsfähigen Assemblerbefehle umgesetzt. Was aber nicht die Stackprobleme etc. bereinigt. Neu schreiben und gut ist. Was anderes kann ich auch nicht empfehlen. Steffen
Hallo Peter und steffen Ich wollte mir einen DCC-decoder bauen und arbeite leiter nur mit Pic. Da ich im internet leider nur etwas gefunden habe mit einem AT90S2313 und nicht mit einem Pic war das meine Frage dazu. -home1.tiscalinet.de/jkatzer/modellbahn/hardware.htm -http://bahn-in-haan.de/_decoder.html(sehr gute Seite) Ich selber arbeite mit Code-Studio und Micro-Studio zusammen und bekomme leider keine verbindung zustande um denn Datenstrang einzulesen. Vieleicht hat einer eine idee dafür oder kann mir eine Abfrage schreiben als ASM die ich dann bei mir einbinden kann. mfg Frank
Hi Frank, "...arbeite leiter nur mit Pic..." Wenn Du den PIC bereits gemeistert hast, sollte der Umstieg zum AVR überhaupt kein Problem mehr sein. Der AVR kann alles was der PIC kann, nur eben noch ne Menge mehr. Deshalb ist ja der umgekehrte Weg AVR->PIC so schwierig bzw. unmöglich. Deine alten PIC-Programme auf einen AVR umzurubeln sollte Dich kaum vor Schwierigkeiten stellen. Eigentlich dürfte nur die Syntax und das Ansprechen der Peripherie (Timer, ADC usw.) die größten Unterschiede darstellen. Ansonsten ergeben sich höchstens noch Vereinfachungen, wie: - alle SRAM-Bankumschaltung ersatzlos streichen - alle Flash-Pageumschaltung ersatzlos streichen - alle Erkennung der Interruptquelle ersatzlos streichen, den entsprechenden Interrupt von dem ihm zugeordneten Vektor aus direkt anspringen. - Sicherungsregister für die Portrichtungsumschaltung ersatzlos streichen, da diese Register beim AVR auch lesbar sind - sämtliche Sicherungsregisterdefinitionen können durch bequemes PUSH/POP ersetzt werden. - extra Berücksichtigung des Carry bei 16/32-Bit Arithmetik ersatzlos streichen und ADC bzw. SBC Instruktionen nehmen. - nie wieder nen Kopf um die CALL-Tiefe machen müssen Nur die RETLW Instruktion muß durch 2 Befehle (LDI+RET)ersetzt werden. Aber das würde ich eh nur zum leichteren Übergang von PIC-AVR machen. Später wirst Du merken, daß der AVR wesentlich effektivere Methoden zum Tabellenzugriff (LPM) hat, so daß man dem RETLW keine Träne nachweinen muß. Beachten solltest Du auch, daß die neueren AVRs mit 16MHz sauschnell sind. Da kann es leicht passieren, daß bei der Übernahme von Delay-Schleifen vom PIC, diese dann zu kurz sind. Also lieber erstmal einen kleineren Quarz oder internen Takt (z.B. 1MHz) auswählen. Der Tip wird warscheinlich zu spät kommen, aber ich habe mir auch das STK500 für 50,-Euro bei der letzten Atmel-Roadshow in Berlin besorgt. Ist wirklich easy, damit anzufangen und sein Geld wert. Der beiliegende ATMega16 ist fast schon zu gut für kleinere Projekte. Peter
Hallo Peter kann mann dann zumindesten die Hex-Datei in eine ASM Datei wieder umwandel damit mann das Programm auch lesen kann und ich dann doch auf Atmel umsteigen kann mfg Frank
@Peter Ich will ja eigentlich nicht schon wieder anfangen aber deine Liste zeigt mal wieder, das Du außer den 16C5X anscheinend keine weiteren PIC´s kennst. Ein Sicherungsregister für die Portrichtungsumschaltung wofür soll das denn gut sein?? Die meisten PIC´s haben ein Portrichtungsregister, welches Schreib und lesbar ist. Ein Teil deiner Liste kannst Du schon bei den 14-Bit Serien streichen. Fast der komplette Rest kann bei den 18FXX in die Tonne. Der einzigste Vorteil der AVR sind die 16MHz, was aber nicht unbedingt bedeutet, dass die Programme der 10MHz(40MHz)-PICs schneller sind. Kleiner Tipp, schau nur mal so wenn Du Zeit hast ins Datenblatt vom 16F8720, dann kannst Du den größten Teil deiner Vorurteile streichen. Nochmal, das soll nicht wieder eine Grundsatzdiskussion werden. @Frank Es gibt zwar Disassembler aber ohne Sprungmarken und Kommentare ist der Code so gut wie nicht nachvollziebar. Entscheide dich für einen Prozessor, besorg Dir die Datenblätter für die Datenübertragung und versuche das Ganze selbst nachzuvollziehen. Für welche Prozessor Du dich entscheidest ist relativ egal. Beide haben Vor und Nachteile. Steffen
Hi Steffen Leider habe ich noch keine Ahnung wie ich die abfrage angehen soll es ist doch nicht so einfach wie eine Led an und auschalten. schau dir doch mal die abfrage des DCC Signal an dann weist du was ich meine. Sieh hier http://bahn-in-haan.de/_decoder.html. Ich arbeite mit Pic 16F627/28 12F629 12F675 zusammen. Hast du ein paar anfangsroutinen dafür für mich oder ein Tipp wie ich im Programm (Micro_studie_Plus von http://www.mecanique.co.uk) das anfangen kann. mfg Frank
@Steffen, Du hast recht, die Erkenntnisse habe ich nicht aus dem Datenblatt des allerneuesten und allerbesten PIC, sondern einfach nur aus dem Ansehen praktischer Programmbeispiele wie z.B.: http://www.mikrocontroller.net/forum/read-4-40889.html Bei den AVRs nehme ich ja auch nicht die allergrößten und allerteuersten Boliden. Z.z. habe ich mich auf den ATTiny26 und ATMega8 eingeschossen, welche ein sehr gutes Preis-Leistungs-Verhältnis haben und gut verfügbar sind. @Frank, wie Steffen schon sagte, disassemblierte HEX-Files sind extrem schlecht lesbar. Sowas eignet sich nur, wenn man eine bestimmte Stelle patchen will. Vielleicht kannst Du versuchen vom Autor das Sourcefile zu bekommen. Du must Dich auch nicht zwischen PIC und AVR entscheiden, Du kannst beide benutzen. Man sollte nur vermeiden, auf allzu vielen Hochzeiten zu tanzen: Wer behauptet 20 oder mehr CPUs zu kennen, der kennt sie nicht gut genug um damit auch effektiv arbeiten zu können. Peter
Zu PIC vs AVR Also ich hab mich bis jetzt fast nur mit PICs beschäftigt. Hab fast für alle Projekte einen 18F458 oder ähnliches verwendet. Versuche gerade mit AVRs so beginnen, aber mein Programmiergerät (http://rumil.de/hardware/avrisp.html) will einfach net hinhauen. Stört es vielleicht dass das paralelle Kabel zum PC ca 5 meter lang ist? Naja jedenfalls hab ich mir das Datenblatt von so einem ATMega mal angeschaut und ich muss sagen, eigentlich sind die neuen PICs mit den AVR so gut wie identisch.... Ok der AVR mehr Befehle, aber braucht man die alle?? Schneller ist er auch ein wenig (16 Mhz) aber sonst...? Der ADC des AVR ist übrigens auch deutlich langsamer wenn ich mich nicht irre... MfG Martin
Die 5m können schon ein Problem sein, müssen aber nicht. Ich kann die Probleme, die viele haben, nicht nachvollziehen, ich habe ein ähnliches Programmieradapter von Lancos / Ponyprog inzwischen auf 6 versch. Rechnern getestet, immer hats funktioniert (Win98,Win NT4.0). Zum PIC / Atmel: Das ist Geschmackssache, muß jeder für sich selbst entscheiden. Ich persönlich habe Gänsehaut bekommen, als ich mir den Assembler des PIC angeschaut hatte - und nahtlos zum AVR gewechselt. Der PIC ist von der Struktur her sehr ungewöhnlich - für mich jedenfalls. Ich bin mit 6502,Z80, 68000 und MCS-51 vertraut und da war der Atmel-Assembler kein so großer Umstieg, wie der PIC es wäre. Man muß sich ja nicht festlegen - bei manchen Projekten nutze ich immer noch MCS-51 Derivate.
@Frank, ich hab gerade mal auf die Seite geschaut. Im Prinzip ist dort doch alles recht gut dargestellt. Was den Basic-Compiler anbetrifft, von dem hab ich keine Ahnung. Steffen
Hi Steffen Der Basic-Compiler geht super einfach und ist zu 100% auch was für Anfänger. mfg Frank
Auf den Seiten des DCC-Portal gibt´s auch noch einige Links zu PIC als auch AVR basierten DCC-Decodern. hier noch der URL: http://www.dcc-portal.net/ Ein Problem haben sie meines Erachtens alle noch: "Programming on the Track" scheint eine echte Herausforderung zu sein. Gruss, Klaus
Klaus, "Programming on the Track" ist nicht das Problem. Das Problem ist eher, welche Funktionalität integriert man in einen Decoder, der so viele CVs hat. Ich habe mal einen Entwurf gemacht und auf: http://bahn-in-haan.de/nmradec.html veröffentlicht. Gruß Gerard
Hallo Gerard! Sieht vielversprechend aus, halt uns auf dem laufenden ! Gruss, Klaus
>Naja jedenfalls hab ich mir das Datenblatt von so einem ATMega mal angeschaut und ich muss sagen, eigentlich sind die neuen PICs mit den AVR so gut wie identisch.... Die PIC's haben vielleicht die gleichen Funktionen wie die AVR, aber irgendwie gibt es keinen der so wirklich alles bietet was es bei den PIC gibt, oder ich hab ihn in den Untiefen der PIC Vielfalt einfach noch nicht gefunden. Bei den AVR ist das einfacher. Mega128 kann alles was die kleineren haben und noch mehr. Punkt. >Ok der AVR mehr Befehle, aber braucht man die alle?? Atmel hat sowohl den Core als auch den Befehlssatz zusammen mit IAR auf Hochsprachenoptimierung getrimmt, aber die meisten Befehle sind auch bei der ASM Programmierung hilfreich/sinnvoll >Schneller ist er auch ein wenig (16 Mhz) aber sonst...? Ein Wenig? Ich würde sagen deutlich. Aber das Thema gab es schon zur Genüge Der ADC der AVR ist nicht der schnellste, das stimmt. Aber bisher hat mir die Geschwindigkeit mehr als gereicht. Hab noch kein Oszi damit bauen müssen, oder Audiodaten sampeln. Und die Auflösung von 10 Bit reicht auch (die Frage kam mal in dem Semiar ob denn auch ADC mit höherer Auflösung geplant sind). Um die Auszureizen muß das erstmal die Schaltung hergeben. In den meisten Fällen ist der Rauschanteil wohl schon höher als die kleinste messbare Spannung Gruß Markus www.embedit.de
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.