Kritische Probleme mit PIC16F648A !!!

[Grzegorz Zalot]

Folgendes Problem : eine neu-Entwicklung, die auf PIC16F628 basierte. Wegen
Platzmangel wurden jetzt die neuen (... na ja, verspaeteten) 16F648A eingesetzt
(doppel so viel Speicher).

Und folgendes wurde festgestellt :
1. Ab und zu werden die Richtungen des Ports A (Register TRISA) von Ausgang auf
Eingang umgestellt. Na ja, jetzt wird TRISA staendig kontrolliert.

2. KRITISCH - ab und zu der Prozessor haengt ! Nicht die Software, weil dasselbe
Programm auf derselben Platine (dieselbe HEX-Datei) funktioniert einwandfre. Und
nur ein Programm, ein anderes funktioniert problemlos. Auf der Platine sind 2
Relais 12V, mit "langsamen" BC847 + 4k7 + LL4148 gesteuert. Alles unabhaengig,
ob die Last da ist oder nicht (220V, Lampe oder Trafo !).

Ich werde schon nicht meckern, dass die original-Tools von Microchip (Picstart
Plus) mit der neuesten Firware programmiert diese Sch...-Teile nicht (na ja,
Riesenunterschied - 2 bits in Control-Wortchen), aber das aufhaengen ist schon
sehr schlimm.

Hat jemand vielleicht einige Erfahrungen mit dem brandneuem Chip (angemendet
fuer XI.2002, erschienen Juli 2003) ? Was kann hier schief sein ?
Microchip-Distributor schon benachrichtigt, aber Ratlos ....

etwas aufgeregt ..... :-( !
MfG
--
Grzegorz Zalot

complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515

http://www.complex.org.pl/
mailto:complex@alpha.pl

 

[chris b]

"Grzegorz Zalot" <complex@alpha.pl> schrieb im Newsbeitrag
news:3F0C532C.5090707@alpha.pl...

Folgendes Problem : eine neu-Entwicklung, die auf PIC16F628 basierte.
Wegen
Platzmangel wurden jetzt die neuen (... na ja, verspaeteten) 16F648A
eingesetzt
(doppel so viel Speicher).

Und folgendes wurde festgestellt :
1. Ab und zu werden die Richtungen des Ports A (Register TRISA) von
Ausgang auf
Eingang umgestellt. Na ja, jetzt wird TRISA staendig kontrolliert.

2. KRITISCH - ab und zu der Prozessor haengt ! Nicht die Software, weil
dasselbe
Programm auf derselben Platine (dieselbe HEX-Datei) funktioniert
einwandfre. Und
nur ein Programm, ein anderes funktioniert problemlos. Auf der Platine
sind 2
Relais 12V, mit "langsamen" BC847 + 4k7 + LL4148 gesteuert. Alles
unabhaengig,
ob die Last da ist oder nicht (220V, Lampe oder Trafo !).

Ich werde schon nicht meckern, dass die original-Tools von Microchip
(Picstart
Plus) mit der neuesten Firware programmiert diese Sch...-Teile nicht (na
ja,
Riesenunterschied - 2 bits in Control-Wortchen), aber das aufhaengen ist
schon
sehr schlimm.

Hat jemand vielleicht einige Erfahrungen mit dem brandneuem Chip
(angemendet
fuer XI.2002, erschienen Juli 2003) ? Was kann hier schief sein ?
Microchip-Distributor schon benachrichtigt, aber Ratlos ....

etwas aufgeregt ..... :-( !
MfG
--
Grzegorz Zalot

complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515

http://www.complex.org.pl/
mailto:complex@alpha.pl

eigentlich wollte ich mir ein paar exemplare dieses chips kaufen !

aber wenn ich das lese .....


gib bitte hier bescheid wenn du neue erkenntnisse hast !

 

[jochen rapp]

Hallo Grzegorz,

Meine Glaskugel sagt mir, dass das nach Problemen mit der
Bankumschaltung aussieht. Im Ram kommst Du gelegentlich an der Bank 1
vorbei und änderst das TRistate-register, vielleicht hast Du auch irgend
eienn Speicherüberlauf und landest wieder im Tristate-Regster......


Könnte es auch sein, dass du das PC-Lath-Register nicht korretk
verarbeitest (nicht sichern bei Interrupts,etc....)


Mit welcher Programmiersprache /Compiler arbeitest Du?


Gruss Jochen

 

[Grzegorz Zalot]

Hallo jochen rapp !:

Hallo Grzegorz,

Meine Glaskugel sagt mir, dass das nach Problemen mit der
Bankumschaltung aussieht. Im Ram kommst Du gelegentlich an der Bank 1
vorbei und änderst das TRistate-register, vielleicht hast Du auch irgend
eienn Speicherüberlauf und landest wieder im Tristate-Regster......

Hmmm, man muss nachschauen. Aber warum laeuft der alte 16F628 ? Wandert nach
anderen Registern nicht ?

Könnte es auch sein, dass du das PC-Lath-Register nicht korretk
verarbeitest (nicht sichern bei Interrupts,etc....)

Dann sollte auf dem alten 16F628 auch nicht laufen.

Mit welcher Programmiersprache /Compiler arbeitest Du?

C HiTech, aber ziemlich alt (7-er Version), lediglich die Definition des
prozessors aktualisiert. In Assembler-Listing scheint alles OK sein. Und bevor
ich ein update kaufe, muss ich SICHER sein, dass alles bei 16F648 richtig
laeuft. Auf dem 16F628 war OK. Mit einigen Programmen. Und mein PIC-Lieferant
hat noch keinen Compiler, der schon den neuen 16F648 als Option hat - sonst
koennte man einfach die Kompilation neu machen, falls das ein Compiler-Bug ist.
Und in den alten 16F87x waren schon die 4 Banks da. Also alles sollte gehen ?
Oder wieder neu Geld ausgeben fuer laufende Updates ?


HfG
--
Grzegorz Zalot

complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515

http://www.complex.org.pl/
mailto:complex@alpha.pl

 

[Grzegorz Zalot]

Neue Versuche :

- Compiler 8.02 in DEMO - Mode (tral 21 Tage)
- Programm neu kompiliert

Passiert genau dasselbe, also bei schneller Arbeit der Schaltung (viele
Interrupts) Prozessor wird blockiert, trotz des Watchdogs (ohne WD passiert auch
dasselbe).

Mit anderen Worten : Sch.... !


Teste folgen noch ...
--
Grzegorz Zalot

complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515

http://www.complex.org.pl/
mailto:complex@alpha.pl

 

[Heiko Höbel]

laeuft. Auf dem 16F628 war OK. Mit einigen Programmen. Und mein PIC-Lieferant
hat noch keinen Compiler, der schon den neuen 16F648 als Option hat - sonst

Der CCS hat den 16F648A in der Device-List drin. Imho ist der CCS
nicht nur wegen seines Preises eine Überlegung wert. Mitten im Projekt
wechseln ist aber nicht zu empfehlen wenn der Zeitplan eng ist.

Gruß,

Heiko Höbel

 

[Ulrich Trettner]

also sprach Grzegorz Zalot:

Folgendes Problem : eine neu-Entwicklung, die auf PIC16F628
basierte. Wegen Platzmangel wurden jetzt die neuen (... na ja,
verspaeteten) 16F648A eingesetzt (doppel so viel Speicher).

schon mal hier geschaut:

http://www.microchip.com/1010/suppdoc/migrat/9706/index.htm

mfg Ulrich

--
.... und paßt mir bitte auf die Elektronen auf ...
.... die sind immer noch sooooo klein ...
Aktuellste Version der EAGLE FAQ:
http://www.trettner.de/faq-eagle/faq-eagle.htm

 

[Grzegorz Zalot]

Hallo Heiko Höbel !:

laeuft. Auf dem 16F628 war OK. Mit einigen Programmen. Und mein PIC-Lieferant
hat noch keinen Compiler, der schon den neuen 16F648 als Option hat - sonst


Der CCS hat den 16F648A in der Device-List drin. Imho ist der CCS
nicht nur wegen seines Preises eine Überlegung wert.

Sehe ich GUT ? 125 Dollar ? Das ist ja ein Preisbrecher. Hast Du vielleicht
diesen Compiler schon im Einsatz ?

Mitten im Projekt

wechseln ist aber nicht zu empfehlen wenn der Zeitplan eng ist.

Stimmt. Jetzt hatten wir mit der Demo-V 8.02 getestet. Genau dasselbe. Ich
vermute einen Bank-Umschaltungsfehler, aber doch im Prozessor. Mit der
Portausgabe kann man das umgehen, aber was passiert, wenn nach einer Int-R. das
Programm nicht die richtige Daten bekommt ? Die Forschung geht morgen weiter ...

Gruss

--
Grzegorz Zalot

complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515

http://www.complex.org.pl/
mailto:complex@alpha.pl

 

[Grzegorz Zalot]

Hallo Ulrich Trettner !:

also sprach Grzegorz Zalot:


Folgendes Problem : eine neu-Entwicklung, die auf PIC16F628
basierte. Wegen Platzmangel wurden jetzt die neuen (... na ja,
verspaeteten) 16F648A eingesetzt (doppel so viel Speicher).


schon mal hier geschaut:

http://www.microchip.com/1010/suppdoc/migrat/9706/index.htm

:-( jaaa .... Und mit 16F628A (!A!) geht problemlos ..... dasselbe HEX natuerlich !

Das ist ja ein S...dreck ! Ich werde das aber GENAU verfolgen und notfalls gut
international beschreiben.

Gruss

--
Grzegorz Zalot

complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515

http://www.complex.org.pl/
mailto:complex@alpha.pl

 

[Oliver Bartels]

On Wed, 09 Jul 2003 19:38:52 +0200, Grzegorz Zalot <complex@alpha.pl>
wrote:

2. KRITISCH - ab und zu der Prozessor haengt ! Nicht die Software, weil dasselbe
Programm auf derselben Platine (dieselbe HEX-Datei) funktioniert einwandfre. Und
nur ein Programm, ein anderes funktioniert problemlos. Auf der Platine sind 2
Relais 12V, mit "langsamen" BC847 + 4k7 + LL4148 gesteuert. Alles unabhaengig,
ob die Last da ist oder nicht (220V, Lampe oder Trafo !).
Normalerweise arbeiten die Microchip Bauteile sehr gut.

Die Architektur ist wohlbekannt, normalerweise wird jeder IC
mit tausenden Testvektoren vor Auslieferung gequält.
Was bei neuen IC's sein kann: Errata wie "wenn Feature
X und Feature Y gleichzeitig aktiv sind, funktioniert Bit Z
nicht mehr/anders".

Mir klingt das danach, dass auf Deiner Platine irgendetwas geschieht,
was die alten IC's gerade noch vertragen haben und die neuen eben
nicht mehr. Generell reagieren z.B. die Ausgangsverstärker von Flash
Arrays säuerlich auf Verschiebungen des Ground Potentials.

Ein Grund könnten z.B. die Relais sein, diese können bei
Schaltvorgängen *massive* Störungen einbringen. Gerade bei der
Anwesenheit von Relais ist u.a. das korrekte Layout (Vcc, GND) sehr
wichtig.

Aussagen wie: Mit dem alten Chip lief es, also muss der Hersteller
Schuld sein, helfen da nicht, vermutlich wurden in so einem Fall
auch schon früher Datenblatt Ratings überschritten, aber der alte
IC Typ hat es gerade noch toleriert.

Was ich machen würde: Alle Pins der CPU mit einem geeignetem
High Speed DSO überprüfen, dto. die Masseverhältnisse, dafür
gibt es nette Features wie Analog Persistence, wahrscheinlich
fällt dann der Übeltäter sofort auf.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

 

[jochen rapp]

Hallo,
vom CCs-Compiler, mit dem ich gearbeitet habe, halte ich nicht
sonderlich viel:
Für kleine Projekte, Quick and Dirty Programmierung ist der geeignet,
bei Grossprojekten würde ich die Finger weglassen. Der einzige Vorteil
neben dem Preis beim CCS ist, das für die Üblichen Anwendungsfälle
(Serielle Schnittstelle, I2C-Bus) schon was vordefiniert ist.
Die Nachteile wären: Optimierung mangelhaftt, Support: fehlanzeige.

Beim HiTch-Compiler ist das eine Frage der Zeit, bis der PIC eingebaut
wird, zumal dieser Compiler von Microchip offiziell unterstützt /
empfohlen wird. Neben kompaktem Code gibt es in Deutschland sehr
kompetenten Support für diesen compiler. Der einzige Nachteil ist
eigentlich, dass dieses ein Richtiger, reiner ANSI-C- Compiler ist.
I2C-Bus, bitverarbeitung kennt dieser aus diesem Grunde von Haus aus
nicht, das muss halt nachgerüstet werden.

Gruss Jochen,

der auch gerne Assembler programmiert.

 

[Marcus Nemec]

On Thu, 10 Jul 2003 23:47:11 +0200, jochen rapp <j.rapp@addcom.de>
wrote:

Beim HiTch-Compiler ist das eine Frage der Zeit, bis der PIC eingebaut
wird, zumal dieser Compiler von Microchip offiziell unterstützt /
empfohlen wird. Neben kompaktem Code gibt es in Deutschland sehr
kompetenten Support für diesen compiler. Der einzige Nachteil ist
eigentlich, dass dieses ein Richtiger, reiner ANSI-C- Compiler ist.
I2C-Bus, bitverarbeitung kennt dieser aus diesem Grunde von Haus aus
nicht, das muss halt nachgerüstet werden.

Dafür hat er schon Makros/Routinen für Daten-EEPROM/-Flash Zugriff und
ADC drin

--

- Marcus

Believe those who are seeking the truth; doubt those who find it.

 

[Grzegorz Zalot]

Hallo jochen rapp !:
......

woher weisst Du, dass der Hardwareemulator unzulänglich ist?

Bei meinem PIC-Distributor.

Mittlerweise auf PIC16F873A laeuft das Programm einwandfrei (zwischenstecker).
Also - doch die sch... prozessoren !


Bis dann
--
Grzegorz Zalot

complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515

http://www.complex.org.pl/
mailto:complex@alpha.pl

 

[jochen rapp]

Hallo Heiko,

ich hatte mal die Freude, für ein Projekt mit dem 16F73 mehrere Compiler
zu Benutzen.

Angefangen habe ich mit Assembler, den ich dann auch noch für die
Stromsparvariante verwende.

Weiter (da Forderung Programmierung in C) gings mit CCS-compiler.
Nachdem ich 50% des Projektes realisiert habe, war der Speicher voll.
Ausserdem habe ich festgestellt, dass der Compiler bei der
Interruptverarbeitung mehr Maschinenbefehle benötigt, bis der
eigentliche Interrupt-Code abgearbeitet wird, wie die Gesamte
Interrupt-Routine in Assembler umfasst.

Geendet bin ich dann beim Hitec C-Compiler.
Die Interruptbearbeitung hat Assembler-Qualität, Support ist erstklassig
(Problemlösung in Deutsch und im Stundenbereich).

Aber wie geschrieben, letztendlich musst Du selbst wissen, welche Kröte
Du schlucken willst

Gruss Jochen

 

[Heiko Höbel]

Angefangen habe ich mit Assembler, den ich dann auch noch für die
Stromsparvariante verwende.

In Assembler habe ich auch schon häufiger gefüttert, aber die
Möglichkeit bietet sich bei meinen Projekten immer weniger und meist
nur für Teile, da ich häufiger mal den Controller wechseln muß und der
Code in kurzer Zeit migrierbar sein muss. Daher ist ein teuerer
Compiler bei mir meist schon wieder zu alt, bis er das zweite Mal zum
Einsatz kommt (die billigen kaufe ich dann einfach nochmal nach).

Weiter (da Forderung Programmierung in C) gings mit CCS-compiler.
Nachdem ich 50% des Projektes realisiert habe, war der Speicher voll.

Da wiederhole ich mich gerne: die Fortschritte dieses Compilers mit
steigender Versionszahl sind durchaus sehens- und beachtenswert.

Ausserdem habe ich festgestellt, dass der Compiler bei der
Interruptverarbeitung mehr Maschinenbefehle benötigt, bis der
eigentliche Interrupt-Code abgearbeitet wird, wie die Gesamte
Interrupt-Routine in Assembler umfasst.

Der CCS kann auch angewiesen werden das ganze Sichern der Register zu
unterlassen und das dem Anwender zu übertragen. Ich nutze auch eine
Interruptroutine der das Fast-Context-Saving reicht uns somit einiges
spart.

Geendet bin ich dann beim Hitec C-Compiler.
Die Interruptbearbeitung hat Assembler-Qualität, Support ist erstklassig
(Problemlösung in Deutsch und im Stundenbereich).
Hallo,

Gut, deutsch bietet CCS nicht, das ist mir persönlich aber egal, da
bei uns sowieso jeglicher Schriftverkehr und Programmdokumentation in
Englisch geführt werden muss. Stundenbereich ist von der Tageszeit
abhängig, da andere Zeitzone. Bis jetzt hat aber das Forum immer
superschnell (Minuten- bis Stundenbereich) reagiert. Das lass ich mir
persönlich dann auch gefallen. Mein Supportbedarf ist aber auch meist
gering.

Aber wie geschrieben, letztendlich musst Du selbst wissen, welche Kröte
Du schlucken willst

100% ACK. Sonst könnte man hoch- oder höher-preisige Produkte ja auch
kaum an den Mann/Frau bringen.
Was mich übrigens noch mehr überzeugt als der CCS ist der Codevision
für AVR. Der hat mir bei meinem letzten Projekt bessere Ergebnisse als
der 30x teurere IAR geliefert und Support war einsame Spitze. Problem
gemeldet - 2h gewartet - neue Version oder Problemlösung retour. Und
im Preis sind Updates für 1 Jahr inbegriffen.
Was ich dagegen nie mehr kaufen würde ist ein Compiler von ByteCraft.
Die PIC-Version hatte schon in einfachsten Programmen die
haarsträubensten Fehler.

Gruß,

Heiko