hallo leute, ich hab mir für ein kleines projekt nen tsic 206 zugelegt und lese den mittels einem atmega32 aus. das ganze klappt wunderbar, rein mittels software (ohne interrupts und warteschleifen). also fallende flanken detektieren, t_strobe messen und anschließend die 2byte auslesen. mein problem ist jetz aber, dass ich die berechnung in eine klasse packen möchte. wenn ich den 100% funktionierenden code 1:1 in eine eine funktion einer klasse stecke und dann die berechnung ausführe, kommen sinnlose werte. also in etwa so, als wenn der zu falschen zeit anfangen würde bits zu lesen. ich hab schon sehr viel versucht. und bin zu dem entschluss gekommen, dass es an dem aufbau per klasse liegen muss :(. ich betreib den controller momentan mit 8mhz intern (16mhz extern klappt irgendwie nicht -> ein controller schon verfust -.-). reicht das vllt nicht, weil c++ langsamer ist? oder ist das quatsch? hat jemand eine idee oder nen hinweis? dankeschön! gruß flo
Flo schrieb: > ich betreib den controller momentan mit 8mhz intern (16mhz extern klappt > irgendwie nicht -> ein controller schon verfust -.-). reicht das vllt > nicht, weil c++ langsamer ist? oder ist das quatsch? Das ist Quatsch. > hat jemand eine idee oder nen hinweis? Code? (wenn du freundlich bist: sowohl die C Version als auch die C++ Version)
vielleicht seh ich auch nur den wald vor lauter bäumen nicht ^^. vielen dank!
der code funktioniert außerdem nur mit einem ausgangspin. also ohne das einschalten und 85ms warten. also es wird der anfang vom packet abgewartet. damit kann man den tsic nach belieben raus und reinstecken und zudem ständig den wert abfragen (sollte eine recht schnelle variante sein). paritybits werden momentan nicht geprüft. ich hätte ja die fertige klasse dann hochgeladen, aber leider klappts halt nich :(. wer solchen code gesucht hat, kann meinen gerne benutzen ;). der normale c code funktioniert ja.
Ein Fehler ist schonmal, dass du m_pDisplay keinen Wert zuweist. Ansonsten ist das generell sehr unuebersichtlich. Die Formatierung ist unordentlich, ein Teil der Implementation im Header, die Variablennamen oft nichtssagend.
> Ein Fehler ist schonmal, dass du m_pDisplay keinen Wert zuweist.
ich musste auch est suchen, aber hier steht es
TSIC tsic;
tsic.m_pDisplay = &lcd;
das man von außen auf Members zugreift, verletzt aber schon mal das
Object Prinzip.
was ist denn das. > uint8_t timeStartTSIC; > timeStartTSIC = TCNT1L; > timeStartTSIC |= TCNT1H<<8; ????????
Peter schrieb: >> Ein Fehler ist schonmal, dass du m_pDisplay keinen Wert zuweist. > ich musste auch est suchen, aber hier steht es > > TSIC tsic; > tsic.m_pDisplay = &lcd; Das ist aus dem nurc.cpp, oder? Ich dachte, das waere die C-Variante und haette mit der C++ nix zu tun... Chaos. Loeschen. Nochmal von vorne.
och jungs ... vielen dank erstmal für eure hilfe. aber ich programmier nich erst seit gestern. die public-variable m_pDisplay ist nur zum test. und funktioniert ganz nebenbei @ frage nach zuweisung. ich hatte ja auch nur nach ideen gefragt. der entscheidende quelltext in "nurc.cpp" wurde in die TSIC::run() kopiert. mir ist klar, dass nurc.cpp eine c++ datei ist. ich habe den namen nur gewählt, weil der funktionelle anteil sich rein auf den inhalt von einer funktion (main) und lokale variblen beschränkt und nicht in einer klasse steckt. @peter: die zuweisung ist dafür, dass die messung sofort anfängt und nicht erst auf die erste flanke wartet, um mit der zeitmessung zu beginnen (um den anfang vom packet zu finden) falls noch jemand eine idee hat, wäre ich dankbar. aber bitte nicht sinnlos auf der formatierung o.ä. was rumhacken... danke.
Flo schrieb: > vielen dank erstmal für eure hilfe. aber ich programmier nich erst seit > gestern. Sieht aber so aus. > falls noch jemand eine idee hat, wäre ich dankbar. aber bitte nicht > sinnlos auf der formatierung o.ä. was rumhacken... danke. Wohin dich dein Stil fuehrt, siehst du doch? Aber du bist ja so erfahren...
tja, schade. man bekommts immer wieder aufs neue bewiesen, dass sämtlich leute im internet den respekt vorm anderen verlieren... meist sinds die, die im wahren leben nur ganz kleine leuchten sind und sich im internet herablassend über andere äußern und somit profilieren wollen. gerade als diplomingenieur sollte man es doch eigentlich nicht nötig haben, andere leute auf diese weise zu kritisieren. tu niemandem was gutes, so wiederfährt dir nichts schlechtes... diese klasse wollte ich zur allgemeinen verwendung vorbereiten und nicht als din-muster.
> uint8_t timeStartTSIC; > timeStartTSIC = TCNT1L; > timeStartTSIC |= TCNT1H<<8; > @peter: die zuweisung ist dafür, dass die messung sofort anfängt und > nicht erst auf die erste flanke wartet, um mit der zeitmessung zu > beginnen (um den anfang vom packet zu finden) bist du sicher das die anweisung das macht was du denkst? Ich dachte du hast ein Problem damit das die Messung ebend zu spät beginnt. Und die Anweisung sieht mehr sehr merkwürdig aus.
jetzt wo du es "sagst" ^^, fällts mir auch auf, dass die variable nur als 8bit deklariert ist. das könnte es sein, ist wirklich quatsch. komisch ist trotzdem, dass die gleiche(!) definition bei der "nurc"-variante funktioniert. ich werds heut abend probieren, was das gerät dazu sagt. danke :)
> komisch ist trotzdem, dass die gleiche(!) definition bei der > "nurc"-variante funktioniert. nein, dort setzt du sie auf 0
hm, wo meinst du?
ich hab hier im konstruktor:
TSIC(){
tStrobe = 0; // zwischen 60 und 65
timeStartTSIC = TCNT1L;
timeStartTSIC |= TCNT1H<<8;
...
}
geschrieben. überseh ich was???
oh ich hatte nur das gesehen
> uint8_t timeStartTSIC = 0;
da hatte ich übersehen das du es später noch mal änderst.
so, ich hab jetzt die 8bit vari auf 16bit geändert und festgestellt, dass die messung davon nur gering beeinflusst wird. was ich jedoch festgestellt hab, ist dass die klasse doch funktionieren kann. und zwar dürfen während der messung nicht zuviele anweisungen ausgeführt werden. dass heißt, der tsic wird wunderbar ausgelesen, wenn der controller nicht viele berechnungen in der hauptschleife drin hat. ich denke dass die zeitfenster ganz einfach nicht eingehalten werden können. die lösung sollte doch sein, während der messung (die zwei byte auslesen, zu je ca. 125mikrosekunden) keine weiteren berechnungen anstellt (bzw. wenige). oder halt den takt auf 16mhz erhöhen. ist das realistisch? also kann es wirklich ein timing-problem sein? schließlich benutz ich keine pins die auf fallende flanken reagieren und habe somit um einiges größeren rechenaufwand. gruß flo
Hi Was mir so aufgefallen ist: >das ganze klappt wunderbar, rein mittels software (ohne interrupts und >warteschleifen). also fallende flanken detektieren, t_strobe messen und >anschließend die 2byte auslesen. Dein Programm ist eigentlich eine einzige Warteschleife. MfG Spess
jo klar ^^. ist im grunde jedes programm, dass sich wiederholt :P. aber halt "nicht blockierend". also keine delay's drin, was jedoch nach neuesten erkenntnissen aber aufs selbe herausläuft. also während der messung wird fast die gesamte rechenleistung benötigt...
Hi >jo klar ^^. ist im grunde jedes programm, dass sich wiederholt :P. >aber halt "nicht blockierend". also keine delay's drin, was jedoch nach >neuesten erkenntnissen aber aufs selbe herausläuft. >also während der messung wird fast die gesamte rechenleistung >benötigt... Ich habe die TSIC-Abfrage auch schon mal programmiert. Allerdings in Assembler und Interruptgesteuert. Die Prozessorbelastung liegt bei ein paar Prozent, bei ca.80 Word Flash. Deine Prozessorbelastung liegt bei 100%. Vom Speicherbedarf ganz zu schweigen. MfG Spess
hallo spess, jo klar, interruptgesteuert ist das auch kein problem (mit interrupt auf fallende flanke). so kannst du den tsic aber an jedem anderen pin nutzen. ob dus brauchst oder nicht, sei mal dahingestellt. und 100% auslastung ist aber gemein formuliert :P. nur wegen der while schleife? ... das soll ja eine reglung werden, da fängts halt immer wieder von vorn an. ich bin nicht so der assembler-freund und sooviel speicherplatz braucht das prog nun auch nicht ;). gruß
Hi >so kannst du den tsic aber an jedem anderen pin nutzen. ob dus brauchst >oder nicht, sei mal dahingestellt. Dank Pin-Change-Interrupt neuerer AVRs geht das auch an fast jedem Pin. >ich bin nicht so der assembler-freund Und ich bezweifle die Sinnhaftigkeit von C++ auf AVRs. Aber lass dich von mir nicht davon abbringen. >und sooviel speicherplatz braucht das prog nun auch nicht ;). Schon mal nachgeprüft? MfG Spess
688 Byte. bei 32k find ich das zu verkraften. aber das mit dem Pin-Change-Interrupt klingt super! da werd ich mir das mal anschauen. c++ find ich hauptsächlich wegen der wiederverwendbarkeit und übersichtlichkeit gut. die pure effizienz mag es nicht sein, klar. gruß
warum sollte man C Code nicht wieder verwenden könnne? Es gibt genügend grosse projekte die in C geschrieben sind. z.b. Der Linux Kernel.
Hi >688 Byte. bei 32k find ich das zu verkraften. Bei 1k nicht mehr so lustig. >c++ find ich hauptsächlich wegen der wiederverwendbarkeit und >übersichtlichkeit gut. die pure effizienz mag es nicht sein, klar. Wiederverwertbarkeit von Software hat nichts mit der Programmiersprache zu tun, nur mit dem Programmierer. Oder meinst du etwa ich schreibe z.B. die Displayroutinen für einen bestimmten Displaycontroller jedes mal neu? MfG Spess
spess53 schrieb: > Und ich bezweifle die Sinnhaftigkeit von C++ auf AVRs. Aber lass dich > von mir nicht davon abbringen. Mein aktuelles Projekt hat 23545 Zeilen Code. Ich wuesste nicht, wieso ich auf den erhoehten Komfort durch C++ statt C verzichten sollte.
Hi >Mein aktuelles Projekt hat 23545 Zeilen Code. Willst du mich jetzt einschüchtern? >Ich wuesste nicht, wieso ich auf den erhoehten Komfort durch C++ statt C >verzichten sollte. Wenn man mit den Ressourcen wildern kann/darf, auf keinen Fall. MfG Spess
Durch C++ wird Code nicht automatisch besser lesbar. Dein Problem ist, daß Du nicht modular arbeitest, sondern unhandliche monolithische Codemonster bastelst. Wenn ich das programmieren müßte, würde ich zuerst eine Bitlesefunktion (Verzeihung: Methode) basteln. Dann damit ne Bytelesefunktion. Dann damit ne Wertlesefunktion. Und dann erst das Ganze im Main aufrufen. Der Witz daran ist, nur die Bitlesefunktion macht die ganzen Timings, alle anderen Funktionen sind harwareunabhängig. Wenn man dann mal die MC-Familie wechselt, muß man nur die Bitlesefunktion anpassen. Das Main mit Code zuzupflastern mag ich nicht (zu unübersichtlich). Das Main sollte nur Funktionsaufrufe enthalten. Ich programmiere immer nach der Methode: teile und herrsche (divide and conquer). Peter
Peter Stegemann schrieb:
> Mein aktuelles Projekt hat 23545 Zeilen Code.
Es dürfte allgemeiner Konsens bestehen, daß die Zeilenzahl kein Zeichen
der Qualität oder des Funktionsumfangs von Software ist.
Es mag alle möglichen nur entfernt brauchbaren Kriterien geben, aber die
Zeilenzahl ist keines davon.
Ich habe auch den Eindruck, daß C++ Quellen erheblich größer sind, als C
Quellen. Insbesondere die Header-Dateien explodieren geradezu in C++.
Peter
Hi >Peter Stegemann schrieb: >> Mein aktuelles Projekt hat 23545 Zeilen Code. >Es dürfte allgemeiner Konsens bestehen, daß die Zeilenzahl kein Zeichen >der Qualität oder des Funktionsumfangs von Software ist. Naja. Für mich wäre die Grösse des resultierenden Programms mal interessant. Von der Plattform mal abgesehen. MfG Spess
Peter Dannegger schrieb: > Peter Stegemann schrieb: >> Mein aktuelles Projekt hat 23545 Zeilen Code. > Es dürfte allgemeiner Konsens bestehen, daß die Zeilenzahl kein Zeichen > der Qualität oder des Funktionsumfangs von Software ist. Wenn ich so einen Satz schon lese... der gehoert in die gleiche Tonne wie "Ich spreche fuer die schweigende Mehrheit" und "kein vernuenftiger Mensch wuerde behaupten..." > Es mag alle möglichen nur entfernt brauchbaren Kriterien geben, aber die > Zeilenzahl ist keines davon. Natuerlich ist die Zeilenzahl ein Hinweis auf den Umfang. So gut oder schlecht wie viele andere Kriterien auch. Ich wollte Spess lediglich verdeutlichen, dass es auch umfangreiche Mikrocontroller-Projekte gibt. Die Diskussion gab es schon im Chat und dort vertrat jemand vehement die Meinung, 1000 Zeilen Assembler seien ein grosses Projekt und man brauche keine anderen Sprachen als Assembler, weil sowas damit problemlos zu handeln sei. > Ich habe auch den Eindruck, daß C++ Quellen erheblich größer sind, als C > Quellen. Insbesondere die Header-Dateien explodieren geradezu in C++. Das liegt aber nicht an C++, wie denn auch? Warum der Eindruck entsteht, ist doch klar - wer staerker abstrahiert und modularisiert, greift eher zu C++ und produziert durch die hoehre Abstraktion auch eher mehr Code. Wenn du das gleiche Design in C und C++ aufbaust, wird dagegen der C-Code eher umfangreicher sein.
> warum sollte man C Code nicht wieder verwenden könnne? Es gibt genügend
grosse projekte die in C geschrieben sind. z.b. Der Linux Kernel.
ich meinte das mit der wiederverwendbarkeit nur gegenüber von assembler.
klar, gehts auch. aber so eine klasse ist schöner, so wird das ganze
projekt schön modular ...
aber wie schon gesagt - alles aus hobby-aspekten und nicht wegen
100%iger performance. überhaupt seid ihr hier alle ganz schön angespannt
^^ (@>Mein aktuelles Projekt hat 23545 Zeilen Code. >>Willst du mich
jetzt einschüchtern?)
wenn man den ganzen elektrokram professionell machen würde (und nicht
aus hobby wie ich), wird man wohl kaum so ein thema starten, sondern das
problem - aus reinem können ;) - von selbst lösen...
also danke pst, dass du dann doch noch helfen wolltest!
gruß
flo
spess53 schrieb: > Naja. Für mich wäre die Grösse des resultierenden Programms mal > interessant. Von der Plattform mal abgesehen. ATMega2560, 82472 byte. Edit: Das hier wirst du wahrscheinlich auch noch brauchen: Sections: Idx Name Size VMA LMA File off Algn 0 .data 00000282 00800200 00013ef8 00013fac 2**0 CONTENTS, ALLOC, LOAD, DATA 1 .text 00013ef8 00000000 00000000 000000b4 2**1 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .bss 00000b26 00800482 00800482 0001422e 2**0 ALLOC 3 .eeprom 0000006c 00810000 00810000 0001422e 2**0 CONTENTS, ALLOC, LOAD, DATA 4 .stab 00032d0c 00000000 00000000 0001429c 2**2 CONTENTS, READONLY, DEBUGGING 5 .stabstr 000de8c1 00000000 00000000 00046fa8 2**0 CONTENTS, READONLY, DEBUGGING
Hi
>dit: Das hier wirst du wahrscheinlich auch noch brauchen:
Und wo steht jetzt die Progragrösse?
MfG Spess
Was willst du denn wissen, Groesse des .hex-Files, des Code-Segments, Code + Daten...? Inklusive lib-c-Teile, ohne? Was ist fuer dich die "Programmgroesse"?
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.