MPLAB -> Mülltonne

[Simon S. (-schumi-)]

Hallo,

die Frage AVR<->PIC ist ja schon lange durchgekaut worden. Gegen den PIC 
selbst habe ich auch garnichts einzuwenden.

Aber diese MPLAP Entwicklungsumgebung bringt mich noch ins Grab!

Heute hab ich in der Arbeit angefangen ein Testboard (<- fertig gekauft, 
zum üben) mit Platine mit Real-Time-Clock dran zu programmieren.

1. Versuch mit PIC18F4550:
- Erstellen eines Projektes ewig kompliziert und ohne Ende 
unübersichtlich (z.B.: Warum X verschieden Compiler zum auswählen? 
Reicht es nicht C oder ASM anzukreuzen? Und dann ist MPLAB natürlich 
noch zu dämlich um die Compiler selbst einzubinden, sondern der Anwender 
darf sie mühsam suchen)
- Compilieren an sich hat funktioniert -> "Linking failed" -> 
ARHGHGHGH!!
-> Irgendwann aufgegeben

2. Versucht mit einem PIC16F887 (anderes Board):
- 1. MicroCPro oder wie es heißt gestartet -> Fail -> Restart -> Fail -> 
Restart -> Fail.... ahja... Ein Programm dass abstürzt bevor es 
überhaupt offen ist, auch toll...

Und die IDE geht mir derart auf die Nerven (z.B. kann ich nicht mal Tabs 
machen!?!?), dass ich Geany installierte und eine "make_all.bat" und 
eine "make_program.bat" angelegt hatte. Also das Zeug wieder 
rausgekrahmt.

Ok, kompilieren und Flashen funktioniert in Geany jetzt relativ gut (bis 
auf die ziemlich krasse Trägheit wenn man auf "kompilieren" klickt)

Also mal losgelegt. Dann fast eine Stunde einen "; expected, "char" 
found"-Fehler gesucht. Irgenwann drauf gekommen dass der Compiler zu 
dämlich ist um im Quellcode (und nicht nur ganz am Anfang von main) 
Variablen zu deklarieren -> Kreisch + Kopf->Tisch

==> Warum ist das alles so kompliziert, instabil und unübersichtlich?? 
Mir braucht niemand zu erzählen dass diese IDE einfacher zu bedienen 
währe als ein Makefile zu kopieren und das TARGET zu tauschen.

Ist das bei euch auch so? Als Vorteil beim PIC wird ja oft erwähnt dass 
alles aus einer Hand kommt -> Hilft auch nichts wenn dann nichts 
funktioniert...

Ich wünschte man könnte mit dem GCC für den PIC kompilieren, dann währen 
alle Sorgen vergessen...


Gruß
-schumi-

[Purzel H. (hacky)]

Es wird im allgemeinen positiv vermerkt, dass man einen eigenen Compiler 
anschnallen kann. Ja. Und wenn der Compiler magere Fehlermeldungen 
rausgibt, kann die IDE nichts dafuer.

[Simon S. (-schumi-)]

>Es wird im allgemeinen positiv vermerkt, dass man einen eigenen Compiler
>anschnallen kann.
Mir ist keine IDE bekannt die das nicht könnte

>Und wenn der Compiler magere Fehlermeldungen
>rausgibt, kann die IDE nichts dafuer.
Das ist mir natürlich klar. Deswegen schrieb ich ja auch
>Ich wünschte man könnte mit dem GCC für den PIC kompilieren
GCC ist ja auch nur ein Compiler

Aber danke für deine Antwort! Inwiefern hast du Erfahrung mit MPLAB? 
(Bzw. welche?)

[C. H. (_ch_)]

Mit dem MPLAB-Editor stehe ich ehrlich gesagt auch auf Kriegsfuß, aber 
Tabs kann man einstellen.

Mal sehen wann das neue MPLAB-X serienreif ist. Vielleicht kann man sich 
dann mal wieder vom externen Editor trennen :)

Gruß,
Christian

[Purzel H. (hacky)]

Die AVR IDE's die ich in gebrauch habe koennen das alle nicht. Dh 
koennen keinen anderen Compiler wie der der dazu geplant wurde.

Ich kenn das MPLAB nur aus der Ferne, irgendwann in den 90ern wurde es 
mir zu bloed das immer noch 16 bittige MPLAB zu verwenden, waehrend die 
anderen IDE's bereits 32 bit waren. Dh ich bin dann auf AVR umgestiegen. 
Sehe das MPLAB aber noch bei meinen Kollegen. Und hab auch schon einen 
PIC Kurs besucht, um nicht aus der Uebung zu kommen.

[Wilhelm F. (Gast)]

Gelegentlich arbeite ich auch mit MPLAB, und muß sagen, daß ich damit 
immer sehr gut zurecht kam. Besonders, wenn man nur in Assembler 
programmiert, und keinen fremden C-Compiler einbindet.

Ich verwende mit MPLAB die Freeware-Version des HiTech-C-Compilers, und 
der ist etwas limitiert. Leider compilieren die Sourcen einwandfrei und 
ohne Fehlermeldungen, aber der Code läuft dann einfach nicht. Die 
Limitierung des Compilers besteht einfach darin, daß er diverse 
Konstrukte wie mehrfach geschachtelte Klammerausdrücke und Verknüpfung 
dieser ganz einfach nicht umsetzt, und es auch gar nicht dokumentiert 
ist. Dem kam ich auf die Schliche, weil ich Assemblercode 1:1 nach C 
portierte. Einfach just for Fun, weil ich anstatt Assembler mal lieber 
in C programmieren wollte, und es testete. Wohl bemerkt, nur kleinere 
Programme. In den 12F675 passt ja ohnehin nicht viel ins Flash, der hat 
nur 1kByte. Vereinfachte ich die Ausdrücke schrittweise, funktionierte 
denn auf einmal alles. Tolle Wurst. Wie es bei gekauften Vollversionen 
aus sieht, weiß ich nicht. Aber die sollten in dieser Hinsicht doch in 
Ordnung sein. Wenn man da was selbst basteln muß, dann ist das Ding ganz 
klar "für die Füße".

Bei Keil, sagen sie dir klar, das Demo-Ding ist z.B. auf 16k limitiert, 
macht aber sonst alles. Das ist wiederum ganz nett, und alles ist klar.

[Hans W. (stampede)]

Jung...
Ich komme mit MPLAB sehr gut zurecht. Ich finde, wenn was kompliziert 
zum Einstellen ist, dann sind es andere Programm wie Visual Studio und 
der ganz MS Kaese. Da motzt keiner!
Tabs gehen, wie schon gesagt.
Dass man verschiedene Complier einbinden kann ist ja an und fuer sich 
nicht verkehrt. Da man die aber aus einem PullDown Menu holt, sollte das 
idiotensicher sein.
>- Compilieren an sich hat funktioniert -> "Linking failed" ->
>ARHGHGHGH!!
Weil du wahrscheinlich die vorkompilierten Libs wie die C18i.o (oder wie 
die heisst) nicht eingebunden hast. Muss im Projekt eingestellt sein.

>Also mal losgelegt. Dann fast eine Stunde einen "; expected, "char"
>found"-Fehler gesucht. Irgenwann drauf gekommen dass der Compiler zu
>dämlich ist um im Quellcode (und nicht nur ganz am Anfang von main)
>Variablen zu deklarieren -> Kreisch + Kopf->Tisch
Haette ich dir sagen koennen.

>Ist das bei euch auch so? Als Vorteil beim PIC wird ja oft erwähnt dass
>alles aus einer Hand kommt -> Hilft auch nichts wenn dann nichts
>funktioniert...
Wenn man sich mal ne Stunde damit beschaeftigt hat kriegt mans hin. Oder 
du gehst ins PIC Forum, und da helfe ich dir gerne 
(www.fernando-heitor.de). Hier erspare ich mir das, da jede Aussage 
bezueglich PIC/AVR unweigerlich in einen Flamewar ausartet, da irgendein 
AVR Fanboy sein Maul nicht halten kann. Daher ist hier meist jede Hilfe 
was das anbelangt vergebens und kostet nur Nerven.

Gruss,
Stampede

[Simon S. (-schumi-)]

>Dh koennen keinen anderen Compiler wie der der dazu geplant wurde.
Ich arbeite immer mit dem Makefile, und das kann man beliebig verändern. 
Man kann aber auch z.B. in Geany unter "Erstellen"->"Komandos zum 
erstellen konfigurieren" direkt die Angaben für den Compiler (abhängig 
vom Dateityp z.B. ".c" -> "make all" oder ".bas" der FreeBASIC-Compiler) 
eingeben
(Was nicht heißen soll dass ich bis jetzt nur Geany benutzt habe, war 
z.B. lange auch mit Code::Blocks unterwegs. Im Moment schiele ich zu 
Anjuta)

>Ich finde, wenn was kompliziert zum Einstellen ist, dann sind es
>andere Programm wie Visual Studio und der ganz MS Kaese. Da motzt keiner!
Ich motze darüber nicht weil bei mir gilt MS=Käse -> Linux, und da is 
nix mit Visual Studio

>Dass man verschiedene Complier einbinden kann ist ja an und fuer sich
>nicht verkehrt. Da man die aber aus einem PullDown Menu holt, sollte das
>idiotensicher sein.
Ja, natürlich ist das nicht verkehrt, aber wenn ich ihm dann die .exe 
suchen darf ist das weniger toll (Was an der Stelle vielleicht auch 
etwas mit der Win-Architektur zusammenhängt, weil man da ja kein Prog 
ausführeren kann ohne ihm zu erzählen wo es ist)

>[Variablen mitten im Sourcecode geht nicht] Haette ich dir sagen koennen.
GCC hat mir aber z.B.
>for(unsigned char zaehler=0; zaehler<234; zaehler++)
angewohnt.
Und wenn mir der Compiler dann wieder nichtssagende Fehlermeldungen 
entgegenwirft habe ich direkt das Gefühl ich müsste gegen den Compiler 
kämpfen...

>Oder du gehst ins PIC Forum, und da helfe ich dir gerne (www.fernando-heitor.de).
Danke! Werd mich dort mal umsehen :-D

Vielen Dank für die Zahlreichen Rückmeldungen und Meinungen!
Gruß
-schumi-

[Simon S. (-schumi-)]

ARGHH!! Ich könnt schon wieder dieses SCHEI** PIC-Zeug in der Luft 
zerreissen!!

Controller: 16F887
Compiler: mikroCPIC1618.exe

Code:

sbit  SPExpanderCS  at RA2_bit;
sbit  SPExpanderRST at RA3_bit;
sbit  SPExpanderCS_Direction  at TRISA2_bit;
sbit  SPExpanderRST_Direction at TRISA3_bit;

void wait (void)
{
  unsigned char zahl;
  for(zahl=0; zahl<30; zahl++)
  {
    Delay_ms(100);
  }
}

void main(void)
{
  ANSEL  = 0;  // Configure AN pins as digital
  ANSELH = 0;
  C1ON_bit = 0;// Disable comparators
  C2ON_bit = 0;

  TRISD=0b11111110;

  while(1)
  {
    PORTD=0;
    wait();
    PORTD=1;
    wait();
  }
}

Was passiert? -> LED für ca. 3sec. aus, dann flammt sie ganz ganz ganz 
kurz und fast nicht sichtbar auf

===> Ist es nicht mal möglich eine stinknormale blinkende LED zu 
programmieren?!?!?!?

Und mit dem Zeug soll ich Funktionen zur Ansteuerung einer Realtimeclock 
bauen -> Vergiss es

PS: wenn man 100ms als Zeit nimmt gehts (also for(zahl=0; zahl<1; 
zahl++))

[Michael X. (Firma: vyuxc) (der-michl)]

Wo ist Delay_ms deklariert?

Ich fürchte deine MPLAB-Probleme lassen sich mit einem C-Lehrbuch lösen.

[Simon S. (-schumi-)]

Das fürchte ich weniger.

1. die Delay_ms ist aus einem Beispielprogramm (dort war auch nichts 
mehr extra eingebunden)

2. 1x >> Delay_ms(100); << ausführen klappt einwandrei. Aber mehrmals 
(siehe for-Schleife) geht nicht. Nachdem ich auch jetzt sehr lange mit 
meinem Ausbilder zusammen herumprobiert habe stellte sich heraus, dass 
der Fehler eindeutig nicht mehr im Quellcode liegen kann (Wenn jemand 
genauer wissen möchte was sich bei der Analyse mit Oszi ergab erläutere 
ich das natürlich gerne).

==> Anderer µController + anderer Compiler wird morgen probiert. Bin ja 
schon mal gespannt...

[C. H. (_ch_)]

Simon S. schrieb:
> (Wenn jemand
> genauer wissen möchte was sich bei der Analyse mit Oszi ergab erläutere
> ich das natürlich gerne).
Dann erzähl doch mal.

Bei den PICs im allgemeinen ist es eher ratsam das Latch-Register 
anstelle des PORT-Registers zu beschreiben - sprich in deinem Fall 
LATD-Register bzw. LATDbits.LATD0-Bit.

Desweiteren ist es immer gut auch mal ins Disassemblerlisting zu gucken 
und nachsehen was der Compiler so alles aus dem C-Code macht bzw. was 
alles wegoptimiert wird.

Gruß,
Christian

[Wilhelm F. (Gast)]

Simon S. schrieb:

> 2. 1x >> Delay_ms(100); << ausführen klappt einwandrei. Aber mehrmals
> (siehe for-Schleife) geht nicht.

Untersuche mal den Assembler-Code, der vom Compiler generiert wird.

Ich arbeite oft mit dem SDCC für 8051, und ein Blick in den vom 
C-Compiler generierten Assemblercode bringt immer sehr viel Aufschluß, 
wie die C-Konstrukte genau umgesetzt werden.

[Simon S. (-schumi-)]

>Dann erzähl doch mal.
Also: Es gibt zwei Funktionen:

void wait_aus (void)
{
  unsigned char zahl;
  PORTD=0;
  for(zahl=0; zahl<8; zahl++)
  {
    Delay_ms(100);
  }
}

und

void wait_ein (void)
{
  unsigned char zahl;
  PORTD=1;
  for(zahl=0; zahl<8; zahl++)
  {
    Delay_ms(100);
  }
}

Die sind also exakt gleich, bis auf das "PORTD=0;" <-> "PORTD=1;"

An RD0 wurde ein Oszi gehängt, ich werd mal versuchen jeweils das 
Oszibild zur entsprechenden main dazuzumalen:

================================================================

void main(void)
{
  TRISD=0b11111110;
  while(1)
  {
    wait_ein();
    wait_aus();
  }
}

Als auch:

void main(void)
{
  TRISD=0b11111110;
  while(1)
  {
    wait_ein();
    wait_aus();
    wait_ein();
    wait_aus();
  }
}

##########################
#  ____   ____   ____   _#
# |    | |    | |    | | #
# |    | |    | |    | | #
# |    | |    | |    | | #
#_|    |_|    |_|    |_| #
#                        #
##########################
=> Signal länger als Pause

================================================================

void main(void)
{
  TRISD=0b11111110;
  while(1)
  {
    wait_aus();
    wait_ein();
  }
}

als auch:

void main(void)
{
  TRISD=0b11111110;
  while(1)
  {
    wait_aus();
    wait_ein();
    wait_aus();
    wait_ein();
  }
}

##########################
#_     _     _     _     #
# |   | |   | |   | |   |#
# |   | |   | |   | |   |#
# |   | |   | |   | |   |#
# |___| |___| |___| |___|#
#                        #
##########################
=> Signal länger als Pause

Im Endeffekt kann man sagen, dass sich der Puls zur Pause (bzw. 
andersherum, je nach dem was als erstes in der Schleife kommt) >> IN 
ETWA << so verhällt:
Pause = Wartezeit
Puls  = 1/Wartezeit

Außerst verwirrend also wie man sieht...
In das ASM-File werd ich mal gucken, auch wenn ich dem Assembler bist 
jetzt noch kaum mächtig bin

Gruß
-schumi-

[Hans W. (stampede)]

Moin,

wie sieht die Config aus? Speziell: sind Watchdog (danach sieht es mir 
fast schon aus) und LVP deaktiviert?
Mist, ich wollte doch hier nix mehr schreiben... :)

Gruss,
Stampede

[Vlad T. (vlad_tepesch)]

Simon S. schrieb:
> Irgenwann drauf gekommen dass der Compiler zu
> dämlich ist um im Quellcode (und nicht nur ganz am Anfang von main)
> Variablen zu deklarieren -> Kreisch + Kopf->Tisch

das ist nun mal laut der ANSI C Sprachdefinition so

Variablendeklarationen zwischen Anweisungen gibts erst seit C99.