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)
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.
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 :)
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???
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ß
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
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"?
