Hallo, ich habe eine Platine, welche durch einen pic18f2520 gesteuert wird. Diesen möchte ich nun durch einen atmega ersetzen. Hat jemand einen Tip, welcher atmel dazu am besten geeignet wäre? Im Idealfall pinkompatibel. genügen würde jedoch natürlich auch funktionskompatibel. Danke jay
Pinkompatibel kannste knicken. Funktionskompatibel wäre im weitesten Sinne ein Mega328(P), der sogar noch etwas mehr könnte, in manchen Dingen aber auch weniger.
Vergiss es. ATMEL und PIC sind so wie OPEL und FORD. Das Getriebe des eine passt nicht in den anderen. Auch falls das Programm in C geschrieben ist, musst Du etliches anpassen, da die in den µC eingebaute Hardware nicht kompatibel ist. Da kannst Du auch gleich neu schreiben. Warum willst Du denn wechseln?
Ähm, klar will/muss ich neu schreiben :-) Wechseln will ich deshalb weil sich meine Bekannten eher mit atmel Programmierung auskennen, ich mich da sowieso einarbeiten will und ich auch Programmer, Prozessoren und drumrum dazu da hab. Das ganze ist eine Steuerplatine mit ein paar Sensoren, ein paar Schaltausgängen, einem Display und eben einem Steuerprogramm. der pic "verliert seine Programmierung" und der Hersteller ist nicht fähig, eine Anleitung zum Neuprogrammieren der Steuerwerte zu liefern, sondern verkauft lieber für xxxeuro neue Platinen. jay
> der pic "verliert seine Programmierung" huch??? die PICs behalten Ihre Programmierung über Jahrezehnte (Datenblatt: >40 Jahre). Das hört sich nach fauler Ausrede des Lieferanten an.
Bevor Du da Zeit und Geld in eine Neuentwicklung steckst, frag mal rum, wer in Deiner Nähe PICs lesen und schreiben kann. mein Fehler im letzten Post: > (Datenblatt: >40 Jahre) richtig ist laut Datenblatt des 18F2520: typisch 100 Jahre
Naja, die "" waren beabsichtigt. :-) Vermutlich ist das Programm noch da, aber durch irgend einen Sensorfehler springt das Programm in einen Notmodus, in dem es auch bleibt, wenn der Sensor wieder repariert ist. Der italienische Hersteller der Maschine ist nun unfähig, eine Programmieranleitung zu liefern. der hat sich irgendwann mal die Platine bauen lassen und verkauft eben lieber neue, als beim Entwickler nach der Anleitung zu fragen. Ich halte es auch für unwahrscheinlich, dass man das Programm einfach auslesen kann... jay
> Ich halte es auch für unwahrscheinlich, dass man das Programm einfach > auslesen kann... Es gibt für die PICs auch ein "code protect", wenn diese Fuse gesetzt ist, kann man das Flash nur noch löschen und neu beschreiben. Aber das kann man easy ausprobieren, die PIC Programmer melden dies, wenn sie den PIC identifizieren. Falls es doch geht, dürfte es allerdings SEHR aufwendig sein, das Programm zu "reengineeren" und für einen AVR umzuschreiben. Das wird dann eine komplette Neuentwicklung.
:-) Genau deshalb versuche ich garnicht erst es auszulesen, sondern schmeiße eben den pic runter und programmiere es gleich neu. jay
Jay B. schrieb: > Der italienische > Hersteller der Maschine ist nun unfähig, eine Programmieranleitung zu > liefern. der hat sich irgendwann mal die Platine bauen lassen und > verkauft eben lieber neue, als beim Entwickler nach der Anleitung zu > fragen. Sorry, aber euer Laden scheint ja lieber neu zu entwickeln als den Italienern ne fertige Platine abzukaufen. Das muss man auch nicht verstehen, oder?
hi, Loonix schrieb: > Sorry, aber euer Laden scheint ja lieber neu zu entwickeln als den > Italienern ne fertige Platine abzukaufen. Das muss man auch nicht > verstehen, oder? 1. ist es privat und 2. HABEN wir "den Italienern" bereits 4 Platinen a 600 euro abgekauft! Und das, obwohl KEINE der Platinen wirklich defekt ist, sondern ALLE "nur" die Programmierung verloren haben! Dein geflame ist also alles andere als angebracht... Die Bauteile der Platine kosten übern daumen vielleicht 30 euro. Die Steueraufgaben sind recht trivial. Also - JA! Da gebe ich sehr wohl lieber einem Hobbyprogrammierer 400 euro und habe nacher ein System, das mich nicht jedes Jahr 600 sinnlose euro kostet, weil der Hersteller unfähig ist! Im übrigen habe ich bereits jetzt schon ca 10 anfragen von (italienischen) "Leidensgenossen"...
400 Eus .. naja ob das reicht ? und die Platine muss dann ja auch noch neu entwickelt + aufgebaut werden
@Jay B. Blas dich mal nicht so auf, Junge. Man wird sich ja wohl noch wundern dürfen. Jay B. schrieb: > Dein geflame ist also alles andere als angebracht... Deine Großbuchstaben und Ausrufezeichen sind es ebenso. Im Übrigen ist das einzige "geflame" in diesem Thread deine Behauptung, ein PIC würde "sein Programm" verlieren. Deine Erklärungen zu dem Fall sind wirklich nicht besonders aufschlussreich. Aber egal, mach doch was du willst...
Leute, kommt mal wieder ´runter. Der Kollege, der den Thread eroffnet hat, hat doch alle Infos, die er braucht. Und wenn ihm das Entwickeln einer maßgeschneiderten Lösung Spaß macht, warum nicht. Manche Leute arbeiten eben auch gerne in der Freizeit, um eine Herausforderung zu meistern. Ich zähle mich mal dazu.
hi, emh schrieb: > 400 Eus .. naja ob das reicht ? Woher weisst du so genau, welcher Aufwand das programmieren meines Programms ist? > und die Platine muss dann ja auch noch neu entwickelt + > aufgebaut werden Wozu? Ich tausche den Prozessor. Alles weitere wird von den "defekten" Platinen benutzt. jay
Jay B. schrieb: > Ich tausche den Prozessor. Alles weitere wird von den "defekten" > Platinen benutzt. Hoffentlich sind nicht alle Pins vom Pic benutzt. Der AVR braucht alleine für die Stromversorgung 2 Pins mehr. Für das Programmierinterface auch nochmal 1 Pin falls "in cirquit" programmiert werden soll und der Pin nicht doppelt belegt werden kann. -> ggf. nach einem ATMEL mit mehr Pins Ausschau halten. Gruß Anja
Jay B. schrieb: > HABEN wir "den Italienern" bereits 4 Platinen a > 600 euro abgekauft! Und das, obwohl KEINE der Platinen wirklich defekt > ist, sondern ALLE "nur" die Programmierung verloren haben! Jetzt hast Du mich neugierig gemacht. Magst Du verraten, um welche Maschine es sich handelt? Die einizige italienische Maschine, von der ich mir vorstellen könnte, dass sie in Deutschland eingesetzt wird, wäre ein Kaffeevollautomat von DeLonghi.
hallo, Anja schrieb: > Jay B. schrieb: >> Ich tausche den Prozessor. Alles weitere wird von den "defekten" >> Platinen benutzt. > > Hoffentlich sind nicht alle Pins vom Pic benutzt. Der AVR braucht > alleine für die Stromversorgung 2 Pins mehr. Für das > Programmierinterface auch nochmal 1 Pin falls "in cirquit" programmiert > werden soll und der Pin nicht doppelt belegt werden kann. -> ggf. nach > einem ATMEL mit mehr Pins Ausschau halten. :-) Ja. Darin sehe ich auch kein Problem. ich werde einfach eine kleine Adapterplatine machen und dort wohl zb. einen mega644 draufsetzen. ISP werde ich vermutlich nicht brauchen. Eine Parametrierung kann über seriell erfolgen (ein Pegelwandler ist bereits auf dem Original). jay
hallo, Andreas schrieb: > Jay B. schrieb: >> HABEN wir "den Italienern" bereits 4 Platinen a >> 600 euro abgekauft! Und das, obwohl KEINE der Platinen wirklich defekt >> ist, sondern ALLE "nur" die Programmierung verloren haben! > > Jetzt hast Du mich neugierig gemacht. Magst Du verraten, um welche > Maschine es sich handelt? Nein, so öffentlich nicht. Ich möchte der Hersteller/Entwicklungsfirma nicht "auf die Füße treten"... Aber wenn du mir eine pm mit deiner Mailadresse schreibst, maile ich dir, um was für eine Maschine es sich handelt. > Die einizige italienische Maschine, von der ich mir vorstellen könnte, > dass sie in Deutschland eingesetzt wird, wäre ein Kaffeevollautomat von > DeLonghi. Geht schon fast in die richtige Richtung; die fragliche Maschine kostet allerdings etwa das 10-fache ;-) jay
Hi, ich meine, wenn du keine Angst vor dem Programmieren hast, waere es vielleicht nicht einfacher die Schaltung mit einem selbst programmierten PIC zu "reparieren" ? Dann kannst du dir zumindest die ganze Rumloeterei sparen... ein Pickit2 als Entwicklungsumgebung gibts auch schon fuer 20 Euronen.... Stampede
Stampede schrieb: > ein Pickit2 als Entwicklungsumgebung gibts auch schon fuer 20 > Euronen.... Das lese ich nicht zum ersten mal. Doch wie immer fehlt eine bezugsquelle.
Weil das Pickit3 der Stand der Technik fuer die LowEnd Debugger ist. Den gibts ab 40 Euro bei Reichelt, Digikey, Mouser, Farnell, ... Das Pickit2 wird bei deinen soweit ich weiss auch noch gefuehrt!
und ein Brenner5 oder Brenner8 von www.sprut.de ist an einem Nachmittag geätzt und zusammengelötet, notfalls auch auf Lochraster.
Stampede schrieb: > ich meine, wenn du keine Angst vor dem Programmieren hast, waere es > vielleicht nicht einfacher die Schaltung mit einem selbst programmierten > PIC zu "reparieren" ? Was soll das bringen, wenn er eh nicht die original Sourcen hat? Einen MC programmieren lernen dauert deutlich länger, als einen Adapter zu basteln. Und wenn seine Leute schon AVR können, dann ist das ein guter Grund, sich viel Zeit zu sparen. Ich würde das auch so machen. Es kann gut sein, daß der Hersteller die SW-Entwicklung extern hat machen lassen und keine Sourcen hat. Wenn dann Externe nicht mehr verfügbar ist, steht man dumm da. Und man kann auch nicht kontrollieren, ob in der SW Fehler gemacht wurden, z.B. in der Benutzung des EEPROM. Peter
Das Problem ist doch, dass sich bei bestimmten Umständen der PIC verabschiedet und nicht wieder zur normalen Funktion zurückkehrt. Das kann ein Software-Fehler aus Versehen oder auch Absicht sein (siehe Tintendrucker). Wenn er einen neuen PIC auslesen kann (sofern nicht code protected), dann würde es genügen, dass er die HEX-Datei (Flash und EEPROM) wieder einspielt.
>Was soll das bringen, wenn er eh nicht die original Sourcen hat? >Einen MC programmieren lernen dauert deutlich länger, als einen Adapter >zu basteln. >Und wenn seine Leute schon AVR können, dann ist das ein guter Grund, >sich viel Zeit zu sparen. Ich würde das auch so machen. das halte ich aber echt für ein Gerücht, oder es liegt an mir, dass ich keine großen Schwierigkeiten habe, mich in einen neuen µC einzuarbeiten. Meine Empfehlung wäre einen PicKit2/3 kaufen und loslegen. Sieht das doch mal von der Seite, die ganze Diskussion hier im Forum kostet Zeit und diese Zeit könnte man dazu nutzen sich mit dem PÍC auseinander zu setzen.
Hi, Peter Dannegger schrieb: > Was soll das bringen, wenn er eh nicht die original Sourcen hat? > Einen MC programmieren lernen dauert deutlich länger, als einen Adapter > zu basteln. > > Und wenn seine Leute schon AVR können, dann ist das ein guter Grund, > sich viel Zeit zu sparen. Ich würde das auch so machen. Also sofern man Datenblätter lesen kann ist zumindest in C der Unterschied zwischen PIC und AVR eher marginal. Einzig andere Libs sind einzubinden und zu benutzen. Für einfache Funktionen wie etwas Sensorabfrage sollte das nicht mehr wie ein Nachmittag sein. Wir reden hier ja weder vom neu lernen der µC Programmierung noch davon das es für den AVR eine fertige SW gibt die man benutzen kann. Es muss für beide µC eine FW komplett neu geschrieben werden. Wenn man einen AVR nutzt, dann muss man jetzt einen passenden Ersatztyp suchen, eine Adapterplatine anfertigen, die FW schreiben, hoffen das es nicht iregednwelche unvorhegesehene Kompatiblitätsprobleme gibt die noch mal eine Änderung am µC oder dem Adapter und in der Folge an der FW nötig machen. Und vor allem -da anscheinend nicht nur der Ersatz für eine Platine geplant ist- Für jede einzelne Platine eine Adapter Anfertigen und somit umrüsten. Verwendet man jedoch den originalen PIC, so muss man sich zwar einen Nachmittag in die anderen Libs einarbeiten, hat dann als einzige Aufgabe nur noch das neuschreiben der FW, alles andere passt garantiert. Steht die Firmware dann einmal braucht man nur noch pro Baugruppe den Pic proggen und umstecken - wenn man nicht sogar den alten Pic neu flashen kann! Also nur noch ca. 10sek. pro Baugruppe! Wie lange hingegen dauert wohl das anfertigen und einpassen des Adapters? Was kostet ein Adapter umgerechnet? Was ist wohl deutlich einfacher??? Und Programmer MIT Debug Option für 20Eur. bekommt man hier: http://cgi.ebay.de/Clone-Microchip-Programmer-PICkit2-/350445520669?pt=Wissenschaftliche_Ger%C3%A4te&hash=item51982e471d oder besser gleich 5 Eur. für das aktuelle Modell drauflegen: http://cgi.ebay.de/Clone-Microchip-Development-Programmer-Mini-PICKIT-3-/230594473204?pt=Wissenschaftliche_Ger%C3%A4te&hash=item35b0806cf4 Das Original bekommt man aber auch schon für 36Euro bei Digikey oder wenn man über die Akademische Linie bestellen kann für etwas über 20Eur. beim Distri. Gruß Carsten P.S. Interessant wäre es mal zu prüfen ob der vorhandene PIC vollkommen i.O. ist oder tatsächlich einen Defekt hat. Ist der PIC hardwaremäßig noch in Ordnung und läuft mit anderem Prog einwandfrei, liegt der Verdacht eines programmierten Ablebens bei dieser Häufigkeit wirklich nahe!
Carsten Sch. schrieb: > Also sofern man Datenblätter lesen kann ist zumindest in C der > Unterschied zwischen PIC und AVR eher marginal. Einzig andere Libs sind > einzubinden und zu benutzen. Für einfache Funktionen wie etwas > Sensorabfrage sollte das nicht mehr wie ein Nachmittag sein. Wenn man es schon kann, sieht alles einfach aus. Aber wenn ich mal zurück denke, wie lange es bei mir gedauert hat, mit dem Keil C51 oder mit dem WINAVR richtig warm zu werden, das hat Monate gedauert. Wenn er seinen Entwicklern sagt, lernt mal eben schnell von AVR auf PIC um, dann kenne ich deren Antwort bereits. Peter
... - - - ... schrieb: > Sieht das > doch mal von der Seite, die ganze Diskussion hier im Forum kostet Zeit > und diese Zeit könnte man dazu nutzen sich mit dem PÍC auseinander zu > setzen. Oder man könnte die Entscheidung und Gründe des OP einfach mal akzeptieren. Peter
> Wenn er seinen Entwicklern sagt, lernt mal eben schnell von AVR auf PIC > um, dann kenne ich deren Antwort bereits. Das Ganze hängt davon ab, wie flexibel die Leute sind. Bei Leuten, die es drauf haben, ist es natürlich kein Problem, sich mal wieder mit einem neuen µC zu beschäftigen. Die andere Sorte wird natürlich lieber beim AVR bleiben.
>Wenn er seinen Entwicklern sagt, lernt mal eben schnell von AVR auf PIC >um, dann kenne ich deren Antwort bereits. Schon klar, aber ich meine, deswegen sind wir eben Entwickler
Ganz OT. Sorry, dass ich hier störe. Weiß aber sonst keinen anderen Weg mich an Stampede zu wenden. Der hatte hier in einem ganz alten Beitrag Teil-Code für den si4705 gepostet. Wollte hier ihn fragen, ob man den gesamten Zugriff irgend wo einsehen kann. Ich versuche seit Tagen dem si4705 Reaktionen zu entlocken. Mehr als ein Statusbyte (0x80) ist er aber nicht willens. Besten Dank im voraus. max
fff schrieb: > Das Ganze hängt davon ab, wie flexibel die Leute sind. Bei Leuten, die > es drauf haben, ist es natürlich kein Problem, sich mal wieder mit einem > neuen µC zu beschäftigen. Die andere Sorte wird natürlich lieber beim > AVR bleiben. Nö, sondern ob die Leute auch ökonomisch denken können. D.h. die aufgewendete Zeit sollte sich möglichst wieder bezahlt machen. Ein neuer MC sollte signifikante Vorteile haben oder andere Anwendungsgebiete erschließen. Peter
Hi, Peter Dannegger schrieb: > ... - - - ... schrieb: >... > Oder man könnte die Entscheidung und Gründe des OP einfach mal > akzeptieren. > > Peter Naja - sonst wird im Forum bei fast jeder Problemstellung (oft -aber nicht immer-) darauf hingewiesen das die favorisierte Problemlösung des T.E. oft ebend nicht die optimale Lösung darstellt und mit dieser Begründung werden dann weitere Infos erfragt und der T.E. darauf vorbereitet seine Idee zwecks besserer Lösungen evtl. noch einmal neu zu überdenken. Die weiteren Infos liegen hier vor - Und nur weil die eindeutig bessere Lösung bedeutet das ebend KEIN AVR eingesetzt wird soll es hier nicht mehr gelten? Also: Wenn es ausdrücklich nur um eine Platine gehen würde, dann würde ich sagen lass es ihn machen wie er meint. Aber hier haben wir eine Baugruppe wo ein µC eingesetzt ist der: 1. Leicht und günstig zu bekommen ist. 2. Einsteigerfreundlich ist 3. Das Programmierzubehör sehr günstig ist. Ich sehe wirklich keinen Grund da jetzt auf Teufel komm raus unbedingt einen AVR reinquetschen zu wollen anstelle einfach den passenden µC neu zu programmieren. Natürlich obige drei Punkte gelten auch für (einige) AVR, aber diese Platine ist nun einmal auf PIC ausgelegt und der PIC passt sofort und 100%. Und nur um sich da zwei - drei Stunden Datenblattlesen zu ersparen... Wenn es jetzt um kleinst-µC gehen würde die eine Programmierung in ASM erfordern würde ich dir vieleicht noch teilweise zustimmen. Wenn man sich wirklich von AVR in die Besonderheiten der PIC ASM Programmierung mit abweichenden Befehlen, Banking und den spezifischen Registern einarbeiten müsste, dann kommt eine Überlegung des wechsels in Betracht. Aber bei einem gut dokumentierten Prozessor für dessen Serie es zahlreiche C Beispielprogramme gibt deren Grundgerüst man weiter verwenden kann doch weiß gott nicht! Zumal ja MPLAb auch für Einsteiger in den grundfunktionen schnell zu bedienen ist und in der Grundeinstellung ohne irgendwelche aufwendigen Einstellungen sofort mit nachladen des C18 Compilers ohen irgendwelche notwendigen Einstellungsanpssungen sofort für die Entwicklung Einsatzbereit ist. Gruß Carsten P.S. Wenn es jetzt anders herum wäre - also die Originalschaltung einen AVR hätte und jetzt jemand da einen PIC hereinquetschen will - dann würde ich genau dasselbe schreiben!
Peter Dannegger schrieb: > fff schrieb: >> Das Ganze hängt davon ab, wie flexibel die Leute sind. Bei Leuten, die >> es drauf haben, ist es natürlich kein Problem, sich mal wieder mit einem >> neuen µC zu beschäftigen. Die andere Sorte wird natürlich lieber beim >> AVR bleiben. > > Nö, sondern ob die Leute auch ökonomisch denken können. D.h. die > aufgewendete Zeit sollte sich möglichst wieder bezahlt machen. > Ein neuer MC sollte signifikante Vorteile haben oder andere > Anwendungsgebiete erschließen. > > > Peter GENAU - Da der AVR in der Schaltung keine Vorteile gegenüber dem PIC bietet, sondern nur Nachteile ist die durch die Adapterlösung verschwendete Zeit -selbst nach Abzug des Zeitaufwandes in die Einarbeitung beim PIC- viel zu groß als das sich der Wechsel der CPU lohnen würde. Es ist viel einfacher beim PIC zu bleiben und sich den Nachmittag für die Unterschiede zum AVR zu nehmen, als den AVR durchdrücken zu wollen und nur Nachteile in Kauf zu nehmen. Ein Umstieg auf AVR ist in diesem Fall soetwas von Unökonomisch... Gruß Carsten
> P.S. Wenn es jetzt anders herum wäre - also die Originalschaltung einen > AVR hätte und jetzt jemand da einen PIC hereinquetschen will - dann > würde ich genau dasselbe schreiben! Genau, nämlich das er dann den PIC nehmen soll. SCNR. Aber so wie ich es verstanden habe geht es um ein Einzelstück. Da muß man schon abwägen ob es nicht tatsächlich einfacher ist sich einen Adapter zu bauen und die vorhandene Ausrüstung und das Wissen einzusetzen als sich ein Programmiergerät zu besorgen, eine neue Toolchain zu installieren und sich dort einzuarbeiten. Ich würde das allerdings machen ;). Was mich hier vor allem interessiert ist die Frage warum der µC "sein Programm verliert". Ein solches Phänomen habe ich auch schon beobachtet. Eine Schaltung funktioniert zunächst ohne Problem, dann geht es plötzlich nicht mehr. Flasht man das Programm dann neu, geht es wieder als wäre nichts gewesen. Ich konnte das bislang nicht reproduzieren. Ab und an passiert es einfach. Eine mögliche Erklärung wäre vielleicht das sich der µC Spikes an irgendwelchen PINs (MCLR?) einfängt. Also ein elektrisches Problem. Wie würde ein AVR darauf reagieren?
Ich kenne jemanden, der sich super mit Pics auskennt, vielleicht kann der ja helfen? Ich bin mir sicher, das die "Leiterplatte" vom italienischen Hersteller und auch das Programm auf dem PIC "buggi" ist. Wenn man mit ein paar einfachen Maßnahmen das verbessern könnte wäre das sicherlich schneller und einfacher, als einen Adapter zu bauen und das Programm neu zu entwickeln... Bei Interesse: PM... Gruß Frank
let schrieb: > Was mich hier vor allem interessiert ist die Frage warum der µC > "sein Programm verliert". Ich könnte mir auch schlechtes Platinendesign vorstellen. Wenn es sich bei dem Gerät wie angedeutet um einen Kaffeeautomaten handelt, muss ich an Magnetventile, Pumpen, etc. denken. Wenn das Platinenlayout bescheiden gemacht ist, kann ich mir schon vorstellen, dass EMV-Probleme dazu führen, dass das Teil im Nirvana landet...
let schrieb: > Aber so wie ich es verstanden habe geht es um ein Einzelstück. Jay B. schrieb: > 1. ist es privat und 2. HABEN wir "den Italienern" bereits 4 Platinen a > 600 euro abgekauft! Und das, obwohl KEINE der Platinen wirklich defekt > ist, sondern ALLE "nur" die Programmierung verloren haben! Ich denke es sind 4. Jay B. schrieb: > Wechseln will ich deshalb weil sich meine Bekannten eher mit atmel > Programmierung auskennen, ich mich da sowieso einarbeiten will und ich > auch Programmer, Prozessoren und drumrum dazu da hab. Da sehe ich 2 Möglichkeiten. 1) Er kann bereits PICs programmieren aber will sich in die AVRs einarbeiten, oder 2) Er kann noch keine µCs programmieren und will sich in die AVRs einarbeiten, da seine BEKANNTEN (Keine Mitarbeiter oder sowas, ist ja auch Privat) schon AVR Erfahrung haben und er da nachfragen kann. Dazu hat er den Programmer, was ansich für den AVR sprechen würde. 4 Lochraster-Platinen zu machen mit ein bisschen Draht ist auch nicht das Problem. Deswegen ist es ansich nur an ihm zu überlegen, ob er den AVR benutzen will, oder den gleichen PIC, um sich die Platine zu sparen und evtl. das Programm kopieren zu können. Die Frage ist nur, ob er das Programm kopieren sollte, wenn es ginge. Denn wenn es ein Programmfehler ist, kopiert man den mit. Wenn es aber kein Programmfehler ist, wird der AVR auch irgendwelche Störspannungen oder was auch immer abbekommen, und ich glaube nicht, das der so viel resistenter ist, als ein PIC. Also kurz: Liegt es am Programm, sollte man es neu schreiben, dann kann man auch gleich einen AVR nehmen, der ist ja schon vorhanden. Wenn nicht, hilft meiner Meinung auch kein anderer µC sondern dann ist Platinentechnisch/Schaltungsmäßig was im Busche.
Wird langsam offtopic hier...
Carsten Sch. schrieb: > Es ist viel einfacher beim PIC zu bleiben und sich den Nachmittag für > die Unterschiede zum AVR zu nehmen, als den AVR durchdrücken zu wollen > und nur Nachteile in Kauf zu nehmen. Es ist vielleicht nicht jeder so ein Genie wie Du, daß ein Nachmittag ausreicht. Ich würde für mich minimal 14 Tage veranschlagen (Installieren, Compiler, IDE, Programmer, Konfigurationen, Blink-LED, Interrupts, Timer, UART, ADC). Kann natürlich bei Problemen bis open-end dauern. Und bei nem Anfänger noch länger. Peter
hallo, Knut Ballhause schrieb: > Wird langsam offtopic hier... Ja, ich war auch gerade verwundert, welche Auswirkungen ein einfaches "danke" haben kann ;-) Allerdings finde ich dieses "offtopic" sehr interessant und Großteils auch hilfreich. Ich würde gerne auf viele der Posts antworten, aber da muss ich mir erst nochmal die Boardhilfe durchlesen. Ich weiß nämlich nicht, wie ein Zitat aus vielen Posts in einem Antwortpost zusammengefasst wird. Oder wird es hier toleriert, wenn ich für jede Antwort einen eigenen Post mache? jay
Jay B. schrieb: > Ich weiß nämlich nicht, wie ein Zitat > aus vielen Posts in einem Antwortpost zusammengefasst wird. Du markierst ein Stück Text, klickst auf "Markierten Text zitieren", und er erscheint (so du javascript aktiviert hast) untendran im Editierfenster. Nach dem Schreiben der ersten Antwort gehst du zum nächsten zu beantwortenden Artikel und wiederholst das Ganze. Carsten Sch. schrieb: > Es ist viel einfacher beim PIC zu bleiben und sich den Nachmittag für > die Unterschiede zum AVR zu nehmen, als den AVR durchdrücken zu wollen > und nur Nachteile in Kauf zu nehmen. Den Nachmittag würde ich, falls man beide einigermaßen kennt, abkaufen, wenn es sich um einen PIC16F84 handelt, aber nicht bei einem 32-KiB-Teil — mal in der Annahme, dass da nicht umsonst so ein großer Controller verbaut worden ist, sondern dass der auch einigermaßen mit Software gefüllt werden soll. Das ist übrigens ziemlich unabhängig von PIC oder AVR: wenn man vor 10 Jahren mal einen AT90S1200 in der Hand hatte und nun plötzlich einen ATmega324P programmieren sollte, wäre der Aufwand für den Umstieg vergleichbar.
Jay B. schrieb: > Ich weiß nämlich nicht, wie ein Zitat > aus vielen Posts in einem Antwortpost zusammengefasst wird. Du markierst einen Text, klickst im dazugehörigen Feld/Beitrag auf "markierten Text zitieren" und er erscheint unten. Dann kannste dazu was schreiben und markierst das nächste und klickst wieder im dazugehörigen Feld/Beitrag auf "markierten Text zitieren" und dann haste den nächsten Beitrag ;)
>aber durch irgend einen Sensorfehler springt >das Programm in einen Notmodus, in dem es auch bleibt, >wenn der Sensor wieder repariert ist. Also wenn die Maschine einen Druckbehälter mit Wasser >100°C enthält, wäre ich sehr vorsichtig. Nach Vorschrift muß dann die Software in einen Lock Out Modus gehen. Jedoch ist es seltsam, daß kein Reset möglich ist. Bestimmt gibt es eine Tastenkombination oder einen Jumper/Resetkontakt auf der Platine. Bernd
Knut Ballhause schrieb: > Wird langsam offtopic hier... Also das finde ich nun überhaupt nicht. Nach dem anfangs extrem wnderlichen geflame ist es doch -im weiteren Sinne-wieder sachlich zum Thema -Ersatz für einen PIC18f2520 in bestehender Schaltung duch AVR- zurückgekehrt. let schrieb: > Was mich hier vor allem interessiert ist die Frage warum der µC > "sein Programm verliert". Ein solches Phänomen habe ich auch schon > beobachtet. Eine Schaltung funktioniert zunächst ohne Problem, dann > geht es plötzlich nicht mehr. Flasht man das Programm dann neu, geht > es wieder als wäre nichts gewesen. Ich konnte das bislang nicht > reproduzieren. Ab und an passiert es einfach. In meinem Ausbildungsbetrieb gab es damals wohl tatsächlich anfangs Probleme das Pics teile Ihrer Programmierung verloren haben. Betraf nur eine sehr geringe Prozentzahl - aber in der Summe war es dann zumindest ein häufigerer Fehler. Aus diesem Grunde haben wir dann damals die Pics zweimal Programmiert - Natürlich beim ersten mal ohne CP - Damit war das Problem behoben. Das waren aber noch PIC-16C71 mit echtem EPROM als Programspeicher. Könnte an einer trotz original "Picmate II" Programmer nicht 100% sauberen Programmierspannung gelegen haben. Das ist aber über 10Jahre her, war eine völlig andere Speichertechnologie und dürfte mit diesem Problem überhaupt nichts gemeinsam haben... Eine IDEE: Es gibt nicht wenige PICs die können nach Freigabe ihren eigenen Programmspeicher beschreiben. (Sonst würde ja auch die ganzen Bootloader nicht funktionieren). Wenn nun das Freigabebit aber nicht wie in einer sauberen Programmierung üblich direkt nach dem Schreibzugriff wieder zurückgesetzt wird - oder gar immer aktiv ist - kann es unter ungünstigen Umständen (Störpuls) nicht nur zu einem zu einem Ungewollten Absturz kommen der dank WDT folgenlos bleibt, nein es kann dann auch zum Willkürlichen verändern des Programmspeichers führen. Denke das ist bei 99% aller Programmdefekte bei -F- Typen ohne Zerstörung des µC die Ursache. Falls es also keine Selbstmordaktion zwecks Gewinnmaximierung ist, könnte ein simples Bit die Ursache sein... Peter Dannegger schrieb: > Carsten Sch. schrieb: >> Es ist viel einfacher beim PIC zu bleiben und sich den Nachmittag für >> die Unterschiede zum AVR zu nehmen, als den AVR durchdrücken zu wollen >> und nur Nachteile in Kauf zu nehmen. > > Es ist vielleicht nicht jeder so ein Genie wie Du, daß ein Nachmittag > ausreicht. > Ich würde für mich minimal 14 Tage veranschlagen (Installieren, > Compiler, IDE, Programmer, Konfigurationen, Blink-LED, Interrupts, > Timer, UART, ADC). Kann natürlich bei Problemen bis open-end dauern. Und > bei nem Anfänger noch länger. > > Peter Frage: Hast du dich in den letzten drei Jahren mal mit den PICs befasst? Oder vermutest du nur??? Wenn jemand AVR in C Programmieren kann müsste es schon ein echter Trottel sein um auch nur annähernd 14 Tage für die Anpassung zu brauchen. Wir reden hier nicht über das Neulernen sondern nur über andere Libarys! Dazu kommt bei Microchip alles aus einer Hand, die IDE läuft sofort mit den Standartinstallationseinstellungen rund und die Libs sowie Frameworks passen alle zusammen. Das ganze sauber dokumentiert mit Beispielprogramme aus denen man sich das wichtigste kopieren kann. Nicht zu vergessen Tools mit denen man sich gleich den fertigen Code zum Einbinden für bestimmte Standartanwendungen wie LCD Displays generieren kann! Wir reden also nur davon das jemand lernen muss statt wie beim AVR: "PORTB |= ((1 << 0)" beim PIC entweder "LATB &= 0xfd" ODER "LATBbits.LATB0 = 0" zu schreiben um den pin 0 von PORTB auf Low zu setzen. (Statt LatB kann man auch PortB nehmen, das manipulieren des Latchregisters ist aber vorteilhafter) Wenn ich Dinge wie das Debuggen oder Simulieren aussen vor lasse dann braucht der DURCHSCHNITTSUSER bei DSL Anschluss incl. Download vieleicht 90Minuten bis er das erste Programm in den PIC schieben kann. Und ADC, UART usw. sind nun wirklich nichts wildes, je nach Lib und Datentyp hast teilweise genau je einen Befehl zum Einlesen und Ausgeben. Die Init ist oft fertg vorgegeben und du brauchst nur die Parameter anpassen. Ich sage es mal so: Vor ein paar Wochen hatten wir bei uns im FH Labor jemanden der ein LCD Display suchte das er mittels Terminalprogramm über die Serielle Schnittstelle ansteuern wollte. Dieser hatte noch nie mit µC gearbeitet. (wohl aber mit PC C Programmiert)... Ich habe dem ein Pickit(Leihgerät), zwei Pics + Quarz und ein paar Bauteile sowie ein altes HD44780 kompatibles Display mitgegeben. Am nächsten Tag kam gegen 13.00 per Mail die NAchfrage nach dem Suchbegriff für die Libs. Noch vor der 20.00 Tagesschau am selben Tag dann die Erfolgsmeldung das sein Display jetzt über COM arbeiten würde - incl. UHR... Auch wenn jemand er im Stoff drin steckt es nicht unbedingt immer einschätzen kann - aber so schwer kann es also nicht sein! Gruß Carsten
Jörg Wunsch schrieb: > > Carsten Sch. schrieb: >> Es ist viel einfacher beim PIC zu bleiben und sich den Nachmittag für >> die Unterschiede zum AVR zu nehmen, als den AVR durchdrücken zu wollen >> und nur Nachteile in Kauf zu nehmen. > > Den Nachmittag würde ich, falls man beide einigermaßen kennt, > abkaufen, wenn es sich um einen PIC16F84 handelt, aber nicht bei > einem 32-KiB-Teil — mal in der Annahme, dass da nicht umsonst so > ein großer Controller verbaut worden ist, sondern dass der auch > einigermaßen mit Software gefüllt werden soll. > Umgekehrt... Würde es sich um den 16C84 handeln würde ich behaupten für ein lauffähiges Programm kommt man mit einem Nachmittag nicht aus... Aber bei diesem µC. Ok, lass es zwei NAchmittage sein wenn man noch nicht so oft umgestiegen ist. Die Größe spielt doch keine Rolle. Es kommt drauf an was ich machen will. Er soll doch nicht den Proz von der Architektur auswendig kennen lernen. Er schreibt von der Abfrage einiger Sensoren und dem Display. Für das Display baue ich die Lib ein und gut ist, dann mus ich mir anschauen wie ich die Ports an meine verwendeten Ports anpasse und welche Befehle die Lib möchte. Nach der Initialisierung mit *LCDInit()* sende ich fleißig meine Daten mit * LCDWriteLine()* an das LCD ;-) Thats ALL Genauso sieht es doch aus wenn z.B. noch RS232 dazukommt... Ich muss mich doch nicht mit den Details beschäftigen. ICh binde die RS232 Lib ein, öffne die Schnitstelle mit *UART2Init()* und übergebe einfach meine Daten z.B. als String mit *UART2PrintString()* Natürlich gibt es dann auch noch die Befehle zum einlesen von Strings und beides nochmal für Bytes bzw. Bytefolgen. Der ganze Aufwand reduziert sich also auf die Änderung einer gut dokumentierten Tabelle mit den PINzuordnungen bzw. GEschwindigkeiten und einer Handvoll Befehle. Gruß Carsten P.S. da hier immer geschrieben wird - evtl. CP nicht gesetzt und Auslesen- Ich denke die Hoffnung kann man begraben. Mir ist noch kein komerzieller PIc untergekommen der nicht geschützt ist. Das wäre ja ein echter Anfängerfehler (zumindest wenn der Code "Non-Public"bleiben soll)
Carsten Sch. schrieb: > Die Größe spielt doch keine Rolle. Es kommt drauf an was ich machen > will. Richtig. Aber das ist bei einem entsprechend großen Controller auch typischerweise einiges, und man muss mehr als nur die Änderungen in den paar GPIOs lernen. Nein, eine Bibliothek eines Herstellers tut das allein auch nicht, sofern man nicht die Grundlagen der Hardware-Architektur kennt.
Jörg Wunsch schrieb: > Nein, eine Bibliothek eines Herstellers > tut das allein auch nicht, sofern man nicht die Grundlagen der > Hardware-Architektur kennt. Manche lernen´s nie. Das predige ich auch mindestens 1x die Woche, aber kaum jemand versteht wirklich, was ich damit meine. Eine eingeklinkte, ach so feine Bibliothek irgendeines Programmierers ersetzt noch lange kein Fachwissen oder die Erfahrung, die man durch jahrelanges Herumspielen oder ernsthafte Arbeiten mit den Steinen erlernt hat. Klar sind sich alle 8-Bit-Controller irgendwo ähnlich, aber der Pferdefuß liegt oft in manch kleinem Detail. Und wenn es sich dabei nur um ein nicht eigehaltenes Timing handelt, welches im Datenblatt unter "Electrical Charcteristics" zu finden ist. Just my 2 cents.
Carsten Sch. schrieb: > Die Größe spielt doch keine Rolle. Es kommt drauf an was ich machen > will. Er soll doch nicht den Proz von der Architektur auswendig kennen > lernen. Carsten Sch. schrieb: > Für das Display baue ich die Lib ein und gut ist, dann mus ich mir > anschauen wie ich die Ports an meine verwendeten Ports anpasse und > welche Befehle die Lib möchte. Nach der Initialisierung mit *LCDInit()* > sende ich fleißig meine Daten mit * LCDWriteLine()* an das LCD ;-) > Thats ALL Carsten Sch. schrieb: > Genauso sieht es doch aus wenn z.B. noch RS232 dazukommt... > Ich muss mich doch nicht mit den Details beschäftigen. ICh binde die > RS232 Lib ein, öffne die Schnitstelle mit *UART2Init()* und übergebe > einfach meine Daten Carsten Sch. schrieb: > Der ganze Aufwand reduziert sich also auf die Änderung einer gut > dokumentierten Tabelle mit den PINzuordnungen bzw. GEschwindigkeiten und > einer Handvoll Befehle. Du Held. Mir fehlen die Worte vor lauter Ehrfurcht!
OT: @ max.L Microspace: Geh mal auf www.picplayer.de und schreib mir dann ne Mail. Dann kann ich dir mit dem Radiochip weiterhelfen! @ Peter: Da er keine Sourcen hat, ist ohnehin eine Neuentwicklung noetig. Da braucht man sich nicht einen anderen Controller schnappen, nur um den auf biegen und brechen in das Geraet zu quetschen. Diese Geschichte der PIC wuerde sein Programm "verlieren" halt ich fuer extrem unglaubwuerdig. In der Firma wo ich z.Z. bin setzen wir jede Menge PICs ein (6 stellige Zahl) und mir ist bisher nicht zu Ohren gekommen, dass der Flash schlapp macht.
Stampede schrieb: > Diese Geschichte der PIC wuerde sein Programm "verlieren" halt ich fuer > extrem unglaubwuerdig. Dem stimme ich aufgrund bisheriger Erfahrungen voll zu.
>> Diese Geschichte der PIC wuerde sein Programm "verlieren" halt ich fuer >> extrem unglaubwuerdig. > Dem stimme ich aufgrund bisheriger Erfahrungen voll zu. Das habe ich schon am 08.03.2011 um 16:57 geschrieben. Das ist eine oberfaule Ausrede.
Die Flash Problematik taucht sporadisch immer wieder mal in Foren auf. Zumindest im Zusammenhang mit Bootloadern finden sich plausible Erklärungen. Hier mal auf die schnelle: http://www.microchip.com/forums/m251160.aspx Bei Lady Ada findet sich auch ein entsprechender Hinweis für AVRs. Stampede schrieb: > In der Firma wo ich z.Z. bin setzen wir jede > Menge PICs ein (6 stellige Zahl) und mir ist bisher nicht zu Ohren > gekommen, dass der Flash schlapp macht. Diese Aussage ist allenfalls dann interessant wenn jemand man davon ausgeht das Microchip fehlerhafte Flashspeicher produzieren würde. Doch das hat niemand behauptet. Bisher war von Programmfehlern und elektrischen Problemen die Rede.
firefighter schrieb: > Nach einem Reset geht der PIC aber wieder normal Eben nicht, wenn der Flash verändert wurde. Dies kann bei ausgeschaltetem BrownOut, heftigen Transienten oder schlechtem Layout durchaus passieren.
Stampede schrieb: > Diese Geschichte der PIC wuerde sein Programm "verlieren" halt ich fuer > extrem unglaubwuerdig. Bin ich ganz bei Dir. Aber die angefangene Diskussion wurde schnell durch Eitelkeiten zu einem Schlagabtausch unter der Gürtellinie. Von "einem wie mir" würde man sich doch nicht vom geplanten Vorhaben abhalten lassen... (Beiträge wurden gelöscht (Danke an die Mods, dem Thread fehlt dadurch sicher nichts)) Mich würd auch nur interessieren in wie fern die Tatsache, dass ein PIC verbaut wurde, hier einen Einfluss auf das Problem haben soll.
Loonix schrieb: > Mich würd auch nur interessieren in wie fern die Tatsache, dass ein PIC > verbaut wurde, hier einen Einfluss auf das Problem haben soll. Einige Controller sind anfälliger gegen Spikes auf der Versorgung, als andere. Der Name spielt erstmal keine Rolle, wohl aber der verwendete Prozess und die Strukturen auf dem Chip und nicht zuletzt auch das Chipdesign.
> Mich würd auch nur interessieren in wie fern die Tatsache, dass ein PIC > verbaut wurde, hier einen Einfluss auf das Problem haben soll. Auch von dieser Behauptung weiß ich nichts. Wo steht das? Auf der ominösen Platine ist nun einmal ein PIC drauf. Und "die Leute" vom TE können oder wollen damit anscheinend nicht umgehen. Das ist alles.
Hi, Knut Ballhause schrieb: > Du Held. Mir fehlen die Worte vor lauter Ehrfurcht! Ehrfurcht deinerseits ist nicht nötig... Wenn hier einer vor Ehrfurcht erstarren müsste dann bin ich das... Anscheinend habe ich die hohe Wissenschaft und die das gewaltige erforderliche Wissen unterschätzt das nötig ist um die hohe Kunst der AVR Programmierung zu beherrschen und welche es den "eingeweihten" unmöglich macht zu glauben das man ohne Neuabsolvierung eines Grundlagenstudiums einen anderen Prozessor als den AVR verwenden kann. Leider bin ich mit diesen gewaltigen Weihen nicht gesegnet und muss meinen Alltag daher weiterhin nach der Ansicht ausrichten das sich die Wahl des Prozessors nach der Anwendung richtet und nicht nach "AVR or BUST" Wenn ich es nicht besser wüsste, dann würde ich glauben das AVR Programmierung etwas so wahnsinnig komplexes ist das jemand der sich da mühselig eingearbeitet hat mangels Kraft niemals mehr einen weiteren Controller lernen möchte.- so wie manche hier über den Prozessorwechsel denken... Aber ich weiß das dem nicht so. Auch wenn ich die zur Verfügung stehenden Tools eher bescheiden finde... Meine Güte - vielleicht solltet Ihr euch die Anfangspostings mal wieder anschauen und bedenken das es hier um einen EINSTEIGER geht der mit Unterstützung von anderen die sich "Ein wenig" auskennen ein paar Taster abfragen und in Folge dessen ein LCD ansteuern und Schaltimpulse ausgeben will und nicht um die Realisation der Zentralsteuerung eines Marsrovers. Jay B. schrieb: > Wechseln will ich deshalb weil sich meine Bekannten eher mit atmel > Programmierung auskennen, ich mich da sowieso einarbeiten will Natürlich ist es unbestritten das wenn man wirklich gut µC Programmierung beherrschen will, insbesondere wenn es um kommerzielle hochkomplexe High-End Entwicklungen geht, auch die Peripherie und das Timing verhalten sowie den ganzen Ablauf im µC kennen MUSS. Und ja darin unterscheiden sich PIC und AVR. Aber hier ist die Rede von einem EINSTEIGER der diese Parameter WEDER bei dem EINEN, noch bei dem ANDEREN kennt. Es ist überhaupt nicht die Rede davon das er stundenlang die Unterschiede vergleichen muss, da er die ja Daten wohl ja nicht mal bei einem Prozessor kennt. Ja... Timing verhalten... Wenn er eine durch Firmware emulierten USB Anschluss implementieren wollte ist das sicherlich notwendig alles vorher schon zu bedenken. Aber für eine so triviale Anwendung doch nicht! Klar, die Frage ist worum es ihm geht. Will er in erster Linie was lernen, macht es schon Sinn sich wirklich in die Grundlagen einzuarbeiten, erst mal mit ASM ein paar LEDs blinken zu lassen usw. Wenn er aber an dem schnellen Ergebnis interessiert ist, dann wird er das weder bei AVR noch bei PIC machen und das braucht er für so triviale Dinge auch nicht... Wobei "der Appetit dann sicherlich beim Essen kommt" und das Interesse was sich im Hintergrund abspielt schon zu etwas Wissenserwerb führt. Ich bezweifle ja auch nicht das es etwas Arbeit ist sich zusätzlich zum AVR in die PIC Besonderheiten einzuarbeiten. Und JA da er die AVR Programmierausrüstung laut eigener Aussage besitzt müsste er sich die für den PIC zusätzlich anschaffen. Aber sowohl die 20Eur. Investition wie auch die zusätzliche Zeit stehen in keinem Verhältnis zum Aufwand für das rein quetschen eines AVRs, was neben dem Aufwand auch noch eine Mechanisch eher Zweifelhafte Festigkeit zur Folge hätte. Aber ich finde es immer wieder erstaunlich wie sehr sich gewisse Erfahrungen immer wieder decken. http://www.eevblog.com/2010/02/22/eevblog-63-microchip-pic-vs-atmel-avr/ Man führe sich hier mal insbesondere die Abschnitte bei den Zeiten 1:30 - 2:00 und 5:30 - 6:10 zu Gemüte führen. 100% durch diesen Thread bestätigt ;-) Und speziell Knut, du solltest dir auch noch mal den Abschnitt 3:10 - 3:50 ansehen damit du vielleicht endlich erkennst das der emotionslose Wechsel zwischen Mikrocontrollerfamilien eben kein Heldentum ist dessen Verfechter man ehrfürchtig verehren muss - sondern ganz normaler Alltag zigtausender die sich professionell oder auch nur halbprofessionell mit µC Programmierung beschäftigen... Und JA- ich gebe zu wenn man oft wechselt bleibt nicht immer die Zeit sich bei jedem einzelnen µC in alle Feinheiten einzuarbeiten. Das wichtigste wird sich angesehen, dann die fertigen Libs gesichtet, benutzt was da ist und was nicht da ist selbst entworfen. Wenn ein Ing. der von seinem Arbeitgeber den Auftrag bekommt für einen µC in einer fertigen (zugekauften?) Schaltung ein Programm mit ganz trivialer Funktion abzuändern damit ankommen würde er müsste dazu erst mal die 1000 Seiten Datenblatt und 100ANs ganz genau lesen - Das Gesicht vom Chef möchte ich sehen... Die Probleme werden gelöst WENN Sie auftreten...
Carsten Sch. schrieb: > Und speziell Knut, du solltest dir auch noch mal den Abschnitt 3:10 - > 3:50 ansehen damit du vielleicht endlich erkennst das der emotionslose > Wechsel zwischen Mikrocontrollerfamilien eben kein Heldentum ist dessen > Verfechter man ehrfürchtig verehren muss - sondern ganz normaler Alltag > zigtausender die sich professionell oder auch nur halbprofessionell mit > µC Programmierung beschäftigen... Mist, Du hast den virtuellen Smilie nicht gesehen.... Carsten Sch. schrieb: > Und JA- ich gebe zu wenn man oft wechselt bleibt nicht immer die Zeit > sich bei jedem einzelnen µC in alle Feinheiten einzuarbeiten. Ein Problem der Moderne. Carsten Sch. schrieb: > Wenn ein Ing. der von seinem Arbeitgeber den Auftrag bekommt für einen > µC in einer fertigen (zugekauften?) Schaltung ein Programm mit ganz > trivialer Funktion abzuändern damit ankommen würde er müsste dazu erst > mal die 1000 Seiten Datenblatt und 100ANs ganz genau lesen - Das Gesicht > vom Chef möchte ich sehen... Trivial ist nicht immer trivial. Guck Dir die heutigen, elektronischen Gebrauchsgegenstände an. Wieviele von von denen funkionieren wirklich? Carsten Sch. schrieb: > Die Probleme werden gelöst WENN Sie auftreten... Ideal ist, wenn die Lösung so gestaltet ist, dass das Problem nicht auftritt, sonst holst Du Deine Produkte vom Kunden zurück. Welches Gesicht macht Dein Chef dann?!
Es gibt defekte Chargen, ist mir auch schon mal untergekommen. Die gibt es aber nicht im kommerziellen Temperaturbereich. Zur Programmierung, es kann damit Probleme geben, die HW ist aber so gemacht, daß auch Spikes und sonstiges durch eintsprechende SW-Programmierung abgefangen werden kann. Daß die Bausteine durch einen sogenannten "production programmer" programmiert wurden wird angenommen, ansonsten mit PicKit programmiert, langen Usb Kabel und noch längeren icsp Kabel da kann sowas schon passieren.
pic user schrieb: > Zur Programmierung, es kann damit Probleme geben, die HW ist aber so > gemacht, daß auch Spikes und sonstiges durch eintsprechende > SW-Programmierung abgefangen werden kann. Das Problem ist nicht die Programmierung, sondern das Laufen auf dem Board unter Betriebsbedingungen. Wenn die Spannung unkontrolliert einbricht, aufgrund eines unsauberen Layouts oder massiver Störungen, dann kann sich der Chip selber umprogrammieren. Dagegen hilft nur das Sperren der Flash-Programm-Befehle per Fuse.
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.