www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik pic18f2520 alternativer avr


Autor: Jay B. (jay_)
Datum:

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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: Jay B. (jay_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke

jay

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-)

Autor: bingo (Gast)
Datum:

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

Autor: Jay B. (jay_)
Datum:

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

Autor: bingo (Gast)
Datum:

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

Autor: bingo (Gast)
Datum:

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

Autor: Jay B. (jay_)
Datum:

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

Autor: bingo (Gast)
Datum:

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

Autor: Jay B. (jay_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-)
Genau deshalb versuche ich garnicht erst es auszulesen, sondern schmeiße 
eben den pic runter und programmiere es gleich neu.

jay

Autor: Loonix (Gast)
Datum:

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

Autor: Jay B. (jay_)
Datum:

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

Autor: emh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
400  Eus  .. naja  ob  das  reicht ?

und  die  Platine  muss dann ja  auch  noch  neu  entwickelt  + 
aufgebaut  werden

Autor: Loonix (Gast)
Datum:

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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: Jay B. (jay_)
Datum:

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

Beitrag #2094893 wurde von einem Moderator gelöscht.
Autor: Anja (Gast)
Datum:

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

Autor: Andreas (Gast)
Datum:

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

Autor: Jay B. (jay_)
Datum:

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

Autor: Jay B. (jay_)
Datum:

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

Autor: Stampede (Gast)
Datum:

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

Autor: Ungläubiger (Gast)
Datum:

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

Autor: Stampede (Gast)
Datum:

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

Autor: bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und ein Brenner5 oder Brenner8 von www.sprut.de ist an einem Nachmittag 
geätzt und zusammengelötet, notfalls auch auf Lochraster.

Beitrag #2095222 wurde von einem Moderator gelöscht.
Autor: Peter Dannegger (peda)
Datum:

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

Autor: Stephan S. (uxdx)
Datum:

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

Autor: ... - - - ... (Gast)
Datum:

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

Autor: Carsten Sch. (dg3ycs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Ebay-Artikel Nr. 350445520669
oder besser gleich 5 Eur. für das aktuelle Modell drauflegen:
Ebay-Artikel Nr. 230594473204

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!

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: fff (Gast)
Datum:

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

Autor: ... - - - ... (Gast)
Datum:

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

Autor: max L. (microspace)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Carsten Sch. (dg3ycs)
Datum:

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

Autor: Carsten Sch. (dg3ycs)
Datum:

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

Autor: let (Gast)
Datum:

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

Autor: Frank B. (frankman)
Datum:

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

Autor: nicht_eingeloggt (Gast)
Datum:

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

Autor: ich (Gast)
Datum:

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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wird langsam offtopic hier...

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Jay B. (jay_)
Datum:

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

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

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

Autor: ich (Gast)
Datum:

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

Autor: B e r n d W. (smiley46)
Datum:

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

Autor: Carsten Sch. (dg3ycs)
Datum:

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

Autor: Carsten Sch. (dg3ycs)
Datum:

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

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

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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: Stampede (Gast)
Datum:

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

Autor: fff (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stampede schrieb:
> Diese Geschichte der PIC wuerde sein Programm "verlieren" halt ich fuer
> extrem unglaubwuerdig.

Dem stimme ich aufgrund bisheriger Erfahrungen voll zu.

Autor: bingo (Gast)
Datum:

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

Autor: let (Gast)
Datum:

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

Autor: firefighter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach einem Reset geht der PIC aber wieder normal, was nach Aussage des 
TE hier nicht der Fall ist.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: Loonix (Gast)
Datum:

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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: let (Gast)
Datum:

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

Autor: Carsten Sch. (dg3ycs)
Datum:

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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Autor: pic user (pic_user)
Datum:

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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

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

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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