Hallo
ich will einen 16f877a mit dem pc verbinden!
aber es funktioniert nicht! das Programm habe ich in c geschrieben!
ich habe auch testweise dazu einfach 2 Ausgänge auf high gesetzt damit ich weiß ob der pic überhaupt arbeitet und es funktioniert!
kann es sein das ich es anders anschließen muss??
ich verwende nämlich ein RS232 kabel bei dem tx und rx ausgekreuzt sind!!
PIC MAX 232
PIN25-->PIN11
PIN26-->PIN12
MAX232 RS232 Schnittstelle
PIN13-->PIN3
PIN14-->PIN2
oder kann es sein das ich im c code einen fehler habe??
#include <16F877a.h>
#use delay (clock=4000000)
#use RS232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
#fuses XT, NOWDT, NOPROTECT, NOLVP
#include <stdlib.h>
void main (void)
{
while(TRUE)
{
output_high(PIN_B3);
output_high(PIN_B2);
printf("Hallo wie geht es dir?"); //Ausgabe auf RS232
}
}
hoffe mir kann jemand helfen!!
mfg
Gehe mal auf meine Seite: http://www.domnick-elektronik.de/aktdzm.htm
Da ist der Plan für einen PIC16F877 mit MAX232 und 10-pol. Pfosten, von dem per Flachbandkabel eine 9-pol. D-Sub-Buchse direkt in den PC eingesteckt werden kann.
Edit: Bei C kann ich Dir leider nicht weiter helfen, weil ich ausschließlich nur in Assembler programmiere.
Dazu gibt es unter http://www.domnick-elektronik.de/picasm.htm und http://www.domnick-elektronik.de/picpwm.htm viele Beispiele.
MfG Karl-Heinz
HobbyElektronik hier klicken ....
Hi doolitle,Zitat von doolitle15
dein Programm läuft bei mir auf meinem Testboard, so wie du es geschrieben
hast, allerdings mit weiteren Parametern unter #fuses NOBROWNOUT + NOPUT.
Muss also wenn der Fehler wenn im Spannungsconverterbereich (Beschaltung des RS232 IC's) liegen...
so long,
Reiner.
ok danke für die raschen antworten!! werde es heute nach der arbeit gleich ausprobieren!!!
mfg doolitle
Schaut nach CCS-C aus.
Wenn du evtl ein Steckbrett verwendest, könnte das der Störungsgrund sein. Ich hab noch nie einen Pegelwandler am Steckbrett zum laufen gebracht. Auch ein paar beliebte fehler sind falsche Einstellungen am Terminalprogramm und das Vertauschen von RX und TX.
Mich verblüfft von CCS die direkte PIC auf USB Konvertierung, wofür keine Zusatzhardware und Treiber notwendig sind.
Hallo,
da hatte ich bisher noch keine Probleme...
Gruß André
Hallo
habe die verbindung zum pc zusammengebracht!! war ein ganz dummer fehler den ich anscheinend übersehn habe!! RX und TX vertauscht!!
jetzt habe ich aber ein anderes Problem und zwar mit dem Brenner 5 von sprut! ich will wiedermal ein c programm hinein brennen aber immer zwischen 50 und 80% kommt eine fehlermeldung wo drinnen steht, dass der brenn vorgang abgebrochen werden muss weil bei ein fehler aufgetreten ist!!
das komische ist das ich das programm ohne fehler kompiliert habe!!
kann es sein das mein brenner den geist aufgibt??
mfg doolitle
Hi,
bei div. Brennsoftwarepaketen ist man in der Lage, eine Geschwindigkeits-
einstellung vornehmen zu können (längsamere Datenübertragung zum Brenner, da seriell).
Teilweise hängt die Geschwindigkeit doch stark vom Rechner ab. Da werden dann durch die Software "Pausen" von ein paar ms mehr eingelegt, so dass dieses Problem somit ggf. nicht mehr auftritt.
Ich hatte damals mal mir einen Brenner von VELLEMAN (über CONRAD Elektronik) zugelegt, in der Brennsoftware war z.B. eine solche Option zur Geschwindigkeitseinstellung (nicht Einstellung der Baudrate!) vorhanden.
Eine 2. Möglichkeit wäre noch, das dein Programm ggf. die Größe des Flash-
Speichers überragt, und deswegen der Abbruch kommt.
Aber wie gesagt, alles nur Vermutungen...
danke für die rasche antwort!!
ich glaub nicht das mein programm zu groß ist! oder?
hier der code:
--------------------------------------------------------------------------
#include <16F877a.h>
#use delay (clock=4000000)
#use RS232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
#fuses XT, NOWDT, NOPROTECT, NOLVP
#include <stdlib.h>
void main (void)
{
char empfangen[];
char *Text;
int8 duty1, duty2;
duty1 = 0;
duty2 = 0;
setup_ccp1(CCP_PWM); //setup capture unit 1 to
setup_ccp2(CCP_PWM); //setup capture unit 1 to
setup_timer_2(T2_DIV_BY_1,100,1); //setup period timer2
/* Haupt- und Heckrotor AUS */
output_low(PIN_C0); //Hauptrotor
output_low(PIN_C3); //Hauptrotor
output_low(PIN_D0); //Heckrotor
output_low(PIN_D1); //Heckrotor
set_pwm1_duty(0); //Geschwindigkeit Hauptrotor
set_pwm2_duty(0); //Geschwindigkeit Heckrotor
while(TRUE)
{
empfangen=getc();
delay_ms(200);
duty1 = (int)strtol(empfangen, &Text,10);
Text = (Text +1);
duty2 = (int)strtol(Text, &Text,10);
delay_ms(200);
printf("duty1= %u, duty2= %u", duty1, duty2);
}
}
-----------------------------------------------------------------------------------
das mit der geschwindigkeit muss ich mir gleich mal anschauen!!
mfg doolitle
Hi,
nun ich denke man kann anhand des Sourcecodes leider nicht direkt feststellen, wie lang in Bytes (für's Flashrom) letzten Endes der ausführbare compilierte Code für den Prozessor selbst geworden ist.
Ich weiss nur, das Stringfunktionen (Wandlerfunktionen) sehr viel an Code brauchen, in Abhängigkeit von dem PIC als solches (PIC16 wesentlich mehr als die neueren PIC18 und/oder höher), wo seitens der codeoptimierten Sprache für einzelne Prozessoren schon einige Unterschiede festzustellen sind. Dies hängt denn vom Compiler ab, wie er dies in Sacher Code optimiert, und was letzten Endes noch an Lib's (Funktions-Bibliotheken) "hinzugelinkt" wird. Das bauscht denn die Sache schon recht auf. Im MPLAB kannst Du nach einladen der HEX-Datei über die "Gauges" sehr gut sehen, wieviel Bytes dein Programm letzten Endes von welchem Speicher wieviel benötigen wird beim Brennen des PIC.
Falls die Länge keine Rolle spielen sollte, bleibt denn eigentlich meines erachtens nach nur die Brenngeschwindigkeit übrig, die ggf. ein Problem verursacht...
Berechtigungen
Zitieren
Lesezeichen