Ich habe den Text ausgetauscht... leider immer noch kein Signal auf dem
Oszi zu sehen... jedenfalls kein Sägezahn ;)
Hast du übers WE noch einen Geistesblitz gehabt?
Gruß & THX
Ich müsste aber auch noch eine haben, die eine Variable ausgeben kann...
da muss ich aber erst suchen...
Du siehst aber schon hier, der Aufwand ist ziemlich groß an Code, der
für ein einfaches printf nötig ist ;) bei meinem µC!
Gruß
Hallo Jochen,
das ist gelinde gesagt M...!
Ich würde gerne sehen welche Werte bei unseren Berechnungen rauskommen.
Ich mach mir Sorgen das ich mit den Type Castings nen Bock geschossen
habe ;-)
Irgend eine Idee wie wir da an eine Rückmeldung vom uC kommen können?
Ich vermute das wir auch keinen online debugger haben?
Grüße
Frank
Hallo Jochen,
so da werden wir wohl ein kleines Testprogramm stricken müssen um eine
Textausgabe hin zu bekommen.
Mein Problem is jetzt das ich nicht sicher bin wie arrays definiert
werden.
Das musst Du bitte mal nachschauen und auch ob es eine Bibliothek mit
einem printf gibt. Das sollte eigentlich in deinen Handbüchern zum
compiler drin stehen ;-)
Weil wenn, dann können wir so etwas bauen:
1
#include<stdio.h>
2
3
#include<mc912d128.h>
4
5
#define RDRF 0x20 // Receive Data Register Full Bit
6
#define TDRE 0x80 // Transmit Data Register Empty Bit
7
8
constdoubleHalfRange=2.5;
9
constdoubleDACStepWidth=5/0x03ffff;
10
11
12
voidsci0_init(void){
13
SC0BDH=0;// 19200 BR=26 (MCLK=8MHz)
14
SC0BDL=26;// MCLK/(16*BaudRate)
15
SC0CR1=0;
16
SC0CR2=0x0C;//TE+RE enable
17
}
18
19
voidsci0_putc(chardata){
20
while((SC0SR1&TDRE)==0){};
21
SC0DRL=data;
22
}
23
24
voidsci0_puts(char*data){
25
while(*data)
26
sci0_putc(*data++);
27
}
28
29
voidmain(void){
30
charmycharacterarray[128]/* This should be a 128 characters long array, how to do this properly? */
31
32
sci0_init();
33
mycharacterarray=printf("\n Here kommt die 1. Zahl: %f",HalfRange);
34
sci0_puts(mycharacterarray);
35
mycharacterarray=printf("\n Here kommt die 2. Zahl: %f",DACStepWidth);
36
sci0_puts(mycharacterarray);
37
38
while(1);
39
}
DAS IST SO SICHER NICHT LAUFFÄHIG!!
Jetzt brauche ich deine Hilfe. Schau bitte das DU das array und den
printf sauber bekommst. Evtl. gibt es auch einen Ersatz für den printf
;-)
Grüße
Frank
J. R. schrieb:> Kann es sein, dass hier der Wurm drinnen ist?> DACValue = (int)(VoltValue / DACStepWidth); /* typeconversion added */
DACValue = (VoltValue / DACStepWidth);
Der Compiler macht die entsprechenden Konvertierungen.
[unsigned long] = ([Float]/[Float]) bzw
[ signed long] = ([Float]/[Float])
Sieh mal ins List-File, da wird das auf einen Blick klar.
Wenn du keine Umgebung hast, online zu debuggen,
dann schau wenigstens ab und zu ins list-File rein, was der
Compiler aus den C-Konstruktionen macht.
Du brauchst die 20-fache Zeit (gerade als Anfänger) wenn du keine
Möglichkeit hast, ein Programm zu debuggen, und am besten
mit Single-Stepping durchzutesten. Die Erfahrungen, die man dabei macht,
sind unbezahlbar.
Das mit
(int)..
ist hier total falsch. Das kopiert letztendlich einfach einen
(normalerweise 16Bit-) Teil aus dem Floatergebnis, konvertiert/erweitert
ihn dann erst (automatisch) auf den Typ von DACValue.
@APW
nene so ganz falsch liegst Du nicht.
Das mit dem ungetestet tut mir ja auch leid, ich hab halt nix hier zum
testen ;-)
@ Jochen
Da klauen wir mal die Idee vom APW und ändern die Zeile in:
DACValue = (VoltValue / DACStepWidth);
also das (int) raus. Ist wie ihr beide festgestellt habt aus mehreren
Gründen Unsinn :-(
Ja ich werde doch langsam alt!
Was macht unser printf Testprogramm?
Grüße
Frank
Das Problem ist, dass ich jetzt einige Jahre nicht mehr in C
programmiert habe. Da ist einiges angerostet.
Vielleicht hole ich am WE mal wieder mein Zeug raus.
Bis auf den 18Bit DAC hab ich eigentlich alles hier.
@APW
hehe, so ähnlich habe ich auch gedacht und habe mir die Woche was zum
Basteln bestellt ;-)
Wenn ich Anfang Juni für ein par Tage in D bin hoffe ich alles zusammen
zu haben das ich das Zeugs mitnehmen kann. Wird spannend nach fast 20
Jahren mal wieder zu basteln ;-)
Grüße
Frank
Sorry war gerade anderweitig beschäftigt!
Diese Änderung hat nichts gebracht:
DACValue = (VoltValue / DACStepWidth);
leider :(
Kannst du mir nochmal sagen was ich jetzt genau nachschauen soll? Das
mit dem printf meine ich!
Danke
Hallo Jochen,
so nachdem ich mich durch diverse Meetings gequält habe gehen wir wieder
auf was sinnvolles über ;-)
printf ist eigentlich ein standard C Befehl mit dem texte formatiert in
ein character array geschrieben werden können.
Ich will jetzt nicht lügen, aber ich meine das printf in der Bibliothek
"stdio" definiert ist.
Wenn Du da die Definition findest täte mir das schon helfen.
Grüße
Frank
Hallo Jochen,
ich war dann gestern Abend ein bischen fleißig und habe mal nachgelesen
was ich finden konnte. Dem zufolge sollte unser Testprogramm für die
Ausgabe so aussehen:
Was hängt an SCI0 um den Text anzuzeigen?
Kannst DU das bitte mal testen ob wir so eine Anzeige bauen können?
Damit hätten wir dann wenigsten ein wenig debugging zur Verfügung.
1
#include<stdio.h>
2
3
#include<mc912d128.h>
4
5
#define RDRF 0x20 // Receive Data Register Full Bit
6
#define TDRE 0x80 // Transmit Data Register Empty Bit
7
8
constdoubleHalfRange=2.5;
9
constdoubleDACStepWidth=5/0x03ffff;
10
11
12
voidsci0_init(void){
13
SC0BDH=0;// 19200 BR=26 (MCLK=8MHz)
14
SC0BDL=26;// MCLK/(16*BaudRate)
15
SC0CR1=0;
16
SC0CR2=0x0C;//TE+RE enable
17
}
18
19
voidsci0_putc(chardata){
20
while((SC0SR1&TDRE)==0){};
21
SC0DRL=data;
22
}
23
24
voidsci0_puts(char*data){
25
while(*data)
26
sci0_putc(*data++);
27
}
28
29
voidmain(void){
30
charmycharacterarray[128];/* This is a 128 characters long array */
31
32
sci0_init();
33
sprintf(mycharacterarray,"\n Here kommt die 1. Zahl: %f",HalfRange);
34
sci0_puts(mycharacterarray);
35
sprintf(mycharacterarray,"\n Here kommt die 2. Zahl: %f",DACStepWidth);
COOOOOL!!!
Ok das mit dem Here ist meinem Job geschuldet.
Programmschnipsel basteln und gleichzeitig hier mit den Jungens englisch
reden gibt dann so ein Misch Masch :-D
So die 2. Zahl schockiert mich.
Da hätte ich was anderes erwartet ;-)
Ich denke damit haben wir den Fehler schon eingefangen.
Ändere bitte mal in unserem Ausgabe Testprogramm:
const double DACStepWidth = 5 / 0x03ffff;
zu
const double DACStepWidth = 0.00001907;
und noch mal rennen lassen ;-)
Hallo Jochen,
das ist um klassen besser als das Ergebnis vorher!!
So ich grübel mal ne runde warum die Zahl zu kurz wird!
Auch wie wir das Problem umgehen können muss ich noch rausfinden ;-)
Du baust bitte die geänderte const Zeile in das DAC Programm und machst
auf verdacht mal einen Test.
Dann schauen wir weiter
Grüße
Frank
sonst rechnet der Compiler auf der rechten Seite erst ganzzahlig,
wobei 0 rauskommt und wandelt dann erst in float/double um.
5.0 zwingt die rechte Seite als double zu rechnen
und die Ausgabe:
1
sprintf(mycharacterarray,"\n Hier kommt die 2. Zahl: %2.10f",DACStepWidth);
Na das ist doch mal ein Wort ;-)
und APW war mal wieder schneller als ich mit der Lösung.
APW ich werde langsam ein wenig neidisch ;-)
Jochen, kannst Du bitte mal APWs Lösungsvorschlag für die const Zeile
testen?
Grüße Frank
P.S. APW, Jochen, danke für die Geduld die ihr habt. Hab ja nu doch
einige Böcke geschossen in den letzten Tagen ;-)
DACValue=DACValue>>8;/* shift the next Byte into position */
34
myhighbyte=DACValue&0xff;/* High Byte preparation */
35
36
myhighbyte&=0x07;/* make sure left 5 bits are empty */
37
38
if(VoltValue<=HalfRange)/* Check for Halfrange */
39
{
40
myhighbyte|=0x08;/* to be able to set the MSB */
41
}
42
43
myhighbyte|=0x10;/* The Data Register Address Bit */
44
45
PORTS&=~0x80;/* /SS output low */
46
mySPITrans(myhighbyte);/* Analog Value Byte1 MSB first */
47
mySPITrans(mymidbyte);/* Analog Value Byte2 24 bit total */
48
mySPITrans(mylowbyte);/* Analog Value Byte3 LSB last */
49
PORTS|=0x80;/* /SS output high */
50
}
51
52
main()
53
{
54
inti=1;
55
doublemyVValue=0;
56
57
/* Init for SPI Interface */
58
PORTS|=0x80;
59
DDRS=DDRS|0xF0;/* outputs */
60
SP0CR1=0x58;/* 0b01011000 */
61
SP0CR2=0;/* Normal mode */
62
SP0BR=0x02;/* 1,0 MHz SPI clock */
63
64
/* Init to the DAC */
65
PORTS&=~0x80;/* /SS output low */
66
mySPITrans(0x20);/* Init DAC Control Register Byte1 MSB first */
67
mySPITrans(0x00);/* Init DAC Control Register Byte2 24 bit total */
68
mySPITrans(0x02);/* Init DAC Control Register Byte3 LSB last */
69
PORTS|=0x80;/* /SS output high */
70
71
while(i>0)/* Endles Data sending for testing only */
72
{
73
VValueTo18BitDAC(myVValue);
74
myVValue+=DACStepWidth;
75
if(myVValue>5)
76
myVValue=0;
77
}
78
79
return0;
80
}
Das Programm sieht nun folgendermaßen aus. Es läuft schon! Also Danke
APW ;)
Und Frank was heißt da Danke für die Geduld... ich habe bisher Danke zu
sagen ;)
Nun werde ich noch den Takt erhöhen :)
Hallo Jochen,
kannst DU noch mal die von APW kommende Ausgabezeile testen?
sprintf(mycharacterarray,"\n Hier kommt die 2. Zahl:
%2.10f",DACStepWidth);
nur das wir sicher gehen das wir keine "genauigkeit" verlieren ;-)
Tja und danach musste uns sagen was wir als nächstes machen. Weil dann
rennt der DAC wie gewünscht ;-)
Grüße
Frank
Ich habe nun den SPI-Clock auf 4 Mhz erhöht.... jedoch ist die Ausgabe
mir dann etwas spanisch^^
Wisst ihr woran das liegt?
Das: sprintf(mycharacterarray,"\n Hier kommt die 2. Zahl:
%2.10f",DACStepWidth); werde ich anschließend einmal testen ;)
Danke!
Hallo Jochen,
Du meinst weil der nicht schneller geworden ist?
Ich bin mir nicht sicher welche Takt der Prozessor selber hat, aber das
sind jetzt einige Schritte wo er durchrechnen muss um durch zu kommen.
Kann es sein das der SPI mit 4Mhz nicht mehr das begrenzende Element
ist?
Ist jetzt nur mal ein Verdacht.
Grüße
Frank
Frank Sander schrieb:> Hallo Jochen,>> Du meinst weil der nicht schneller geworden ist?> Ich bin mir nicht sicher welche Takt der Prozessor selber hat, aber das> sind jetzt einige Schritte wo er durchrechnen muss um durch zu kommen.> Kann es sein das der SPI mit 4Mhz nicht mehr das begrenzende Element> ist?>> Ist jetzt nur mal ein Verdacht.>> Grüße> Frank
Du meinst also, dass es der DAC ist? Weil der µC kann es ja net mit 8
Mhz sein ;) oder?? :)
Hallo Jochen,
8Mhz hat der HC12?
Dann haben wir seine Grenze erreicht.
Ich stelle mal ein par Behauptungen auf:
der HC12 braucht 2 Taktzyklen / Befehl (das erscheint mir optimistisch)
damit kann der HC12 effektiv nur 4 Mhz umsetzen.
Jetzt brauchen wir aber schon 3 Befehle um nur 1 byte von 3 an den DAC
zu schicken.
Gibt (wieder optimistisch) 9 Befehle. Dann boste schon bei ca. 0,5 Mhz
oder 500kHz.
Das bedeutet:
Ohne das wir auch nur einen Wert berechnet haben und ohne die reine
Übertragungszeit des SPI braucht der Prozessor schon 0,5s für einen
Zyklus.
Wenn Du jetzt noch das ganze grechne da drauf packst und die
Übertragungszeiten....
Grüße
Frank
Hmmm okay! Das stimmt. Dann muss ich mal sehen, ob das für unsere Zwecke
reicht... also brauche ich faktisch für jeden Wert an den DAC 0,5 s
mindestens?!
Aber du hast doch gesagt die 9 Befehle brauchen schon 0,5 s ??? Oder??
Wobei??? Dann kann des Oszi Bild nicht stimmen ^^ Aber alle Werte des
Sägezahns brauchen auch mehr wie 0,5 s! :)
Du kannst die Maximale Rate mit dem Oscar genau ausmessen.
Änder unser Sägezahn Programm dahingehend, das Du zwischen 0 und 5V
springst.
Damit bekommst DU am Oscar die Maximal mögliche Änderungsfrequnz
dargestellt ;-)
Hallo Jochen,
ok dann die Erkläsrung noch mal anders und ein wenig genauer:
Wir führen (dieses mal habe ich nachgezählt) 22 C Zeilen aus um einen
Wert zu schreiben.
Wenn wir behaupten das jede Zeile 2 Taktzyklen im HC12 sind (viel zu
optimistisch) dann sind wir bei einer Bearbeitungszeit von 8Mhz / 44
Zyklen = 0,18 Mhz
Das sind also ca. 0,000005 s pro Wert.
Wir verschicken pro Sägezahnzyklus 262143. Das ergibt dann schon 1,5
sec.
Das deckt sich nicht mit deinem Bild, weil meine angenommen 2 Taktzyklen
VIEEEEEEL zu optimistisch sind.
Mach ruhig mal den o.g. Versuch mit den Wertsprüngen zwischen 0 und 5
Volt, damit wissen wir dann genau was bestenfalls möglich ist ;-)
Grüße
Frank
Hallo Jochen,
das bestätigt ein wenig meine Sorge.
Ich werde da noch mal lesen müssen ;-)
Generell haben wir aber jetzt ein funktionierendes Programm.
Die "Ungenauigkeit" werden ich noch mal genauer studieren, soll uns aber
nicht davon abhalten das wir erst mal weiter basteln.
Kannst Du den Test zur maximal darstellbaren Frequenz durchführen?
Grüße
Frank
1) SPI läuft auf max Frequenz = F_Bus/2 = 4MHz
3 Bytes pro Wertausgabe an den DAC zu übertragen:
-> 24Bit * 250ns => 6us
Wenn man den vollen Sägezahn mit 18Bits macht braucht man
also für die SPI-Transfers alleine ca. 1,6s
Sollte also momentan nicht der limitierende Faktor sein.
2) Das hier ist der limitierende Faktor:
DACValue = (VoltValue / DACStepWidth);
Pro Ausgabe eine double-Division sowie eine Double zu
Longint Konvertierung. Wenn man auf Speed optimiert, muss man
Fliesspunktrechnungen vermeiden. Ganz hardcoremässig event.
sogar auf Assembler umsetzen.
3) Beim HC12 kann man nicht pauschal von 2 Clks/Maschinenbefehl
ausgehen.
Es gibt Befehle, die dauern 1 Clk, andere dauern so 12 Clks.
Ich schätze den Durchschnitt so auf 3 Clks/Befehl
Ausserdem wisst ihr ja nicht, was der C-Compiler aus euren
Konstruktionen macht.
4) Kannst du mal sowas probieren:
1
...
2
sprintf(mycharacterarray,"\n Hier kommt die 2. Zahl: %2.10f",DACStepWidth);
3
sprintf(mycharacterarray,"\n Hier kommt die 2. Zahl: %2.10f",10000*DACStepWidth);
4
5
sprintf(mycharacterarray,"\n Hier kommt die 2. Zahl: %2.12f",DACStepWidth);
6
sprintf(mycharacterarray,"\n Hier kommt die 2. Zahl: %12.12f",DACStepWidth);
7
8
sprintf(mycharacterarray,"\n Hier kommt die 2. Zahl: %e",DACStepWidth);
9
...
Einfach mal ein bischen experimentieren. Vielleicht sinds
Rundungseffekte
APW du rettest meinen Tag!!
den %e habe ich gesucht und nicht gefunden!!
Ich gehe derzeit davon aus das wir einem Rundungsfehler zum Opfer
fallen.
Da ich aber gerade an eben der Vermeidung der double Berechnungen
arbeite (jep mir ist bewusst das die Dinger richtig Zeit kosten) werde
ich auf dem Weg auch den Rundungsfehler los.
Ich stimme Dir übrigens zu was die 2 Zyklen betrifft. Habe derweil mal
ein wenig im Netz gestöbert. Da sprach sogar jemand von 4 Zyklen im
Mittel (bei Assembler code).
Ob ob Jochen aber wirklich viel schneller werden muss wird er uns noch
verraten müssen ;-)
Dank Dir erst mal.
Grüße
Frank
Geschwindigkeit ist für mich ziemlich wichtig! Aber ich werde als erstes
jetzt mal den Test vom Frank programmieren ;)
Und mal messen wie schnell wir momentan sind!
Hallo Jochen,
lese ich das richtig?
Von der fallenden Flanke zur fallenden Flanke ca. 450us?
Kannst Du mir sagen wie schnell Du es brauchst?
Grüße
Frank
Nächste Schritte sollen dann sein, mehrere DACs an einem µC zu
betreiben. SPI-BUS soll dazu verwendet werden. Hardware habe ich aber
noch nicht :)
Die Frage die ich deswegen habe ist, was passiert wenn der µC sein
Signal vom DAC abzieht... das heißt hält der DAC dann seinen Wert? Soll
nämlich so werden, damit mehrere DACs gleichzeitig laufen können.
Danke!
Hallo Jochen,
leider hast Du die Frage nicht ganz beantwortet ;-)
Wie schnell (je DAC) brauchst Du es denn??
Über wie viele DACs reden wir?
Ich fange gerade an mir Sorgen zu machen ;-)
Grüße
Frank
J. R. schrieb:> Die Frage die ich deswegen habe ist, was passiert wenn der µC sein> Signal vom DAC abzieht... das heißt hält der DAC dann seinen Wert?
Hä??
Ich hab keinerlei Durchblick, was du genau vorhast.
Wir brauchen ja nicht die DAC Wandlerrate von 1000/s auf 20000/s
hochtreiben, wenn 10/s ausreichen.
Also
-Was soll das Ganze eigentlich
-Wo kommen welche Daten in welchem Format / bzw. Protokoll
wie schnell rein
-Was sind die Ausgabekanäle
-Was muss der uC wie verarbeiten
-Wie schnell soll das laufen
-Reichen 30 DAC Wandlungen/s oder sollens 10000/s sein
-Sollen die DACs gleichzeitig ihre Analogausgänge updaten ?
-Wenn du mehrere DACs bedienen musst, kannst du dir es überhaupt
noch leisten, die ganze Ausgabe über zu warten ?
(während z.B. serielle Daten reinkommen)
.....usw...
Langsam gehts event. mit Interruptprogrammierung los.
Das kann noch viel lustiger werden als bisher.
Wenn das auf die 10000 Beiträge zustrebt,
bekomme ich echte Probleme mit meinem Browser.
Hallo APW,
wie viele Beiträge haben wir denn bis jetzt?
evtl. sollten wir dann demnächst einen neuen Fred aufmachen.
Die eigentliche Aufgabe (siehe Überschrift) haben wir ja gelöst ;-)
Grüße
Frank
Ich kann darüber auch noch keine genaueren Angaben machen... ist bei mir
auch alles noch im Aufbau und muss ich erst einmal selber abklären....
;)
Aber nochmal zu dem was ich meinte... wenn ich jetzt über den BUS sagen
wir 4 DACs ansteuere... dann kann ich ja immer nur eine mit den
entsprechenden Infos versorgen... wegen dem BUS... und wie ist das dann
mit den übrigen DACs die nicht SS mäßig gerade angesprochen werden?
Schalten die sich dann einfach auf 0 V oder halten die ihren vorher
übermittelten Wert? Das meine ich! Klar? :) ;)
Thx!
Hallo Jochen,
heute wird die Session etwas holperig, weil wir hier auf der Baustelle
versuchen einen 35KV Traffo scharf zu schalten.
Genauer der Kunde versucht das ;-)
Zu deiner Frage:
der DAC hält die Spannung am Ausgang.
Das kannst Du auch schon an unseren Sägezahnversuchen sehen. Weil wir ja
immer nach dem Übertragen den SS wegnehmen ;-)
So ich hol mir schnell nen Kaffee und dann kommt die Antwort zu den
Geschwindigkeiten ;-)
Grüße
Frank
Hallo Jochen,
jetzt mal zu den Geschwindigkeiten oder "sample rates".
Es gibt da kein schnell oder langsam. Es gibt nur eine Anforderung die
mit der gewählten Plattform erfüllt werden kann oder eben nicht.
Einfaches Beispiel:
wenn Du einen 2 Mhz Rechteck mit deiner gewählten Plattform darstellen
willst, wirst du feststellen das geht nicht. egal wie Du es
programmierst. Da ist dann der SPI Takt = 4Mhz zusammen mit dem 24 bit
Kontrollwort eine Physikalische Grenze ;-)
Um also sagen zu können ob und wie deine Idee umsetzbar ist, müssen wir
erst mal wissen welche Voraussetzungen wir erfüllen müssen.
Wir kennen aber schon ein par Werte die wir schaffen können.
1. Die reine Übertragung eines Wertes dauert 6us (dank an APW)
2. Derzeit verbraten wir durch Rechnereien ca. 220us pro Wert.
Diese 220us können (und müssen??) wir optimieren, nur dafür müssen wir
wissen auf was wir optimieren. Da kommen dann wieder die schon mal
gestellten Fragen zum tragen.
Ein einfaches Beispiel:
Ich glaube das wir locker 100us sparen können wenn der "Bediener" die
Spannung nicht in V sonder in uV angibt.
Dadurch können wir die doubles weg optimieren und die kosten richtig
Zeit!!
Wie APW schon sagte: Wenn Du nur eine Wertänderung alle 0,5s brauchst
dann brauchen wir gar nix optimieren und sind (fast) fertig ;-)
Alles klar soweit?
Grüße
Frank
Hallo Jochen,
ich hoffe heute fließen keine Ströme :-D
Aber wenn es mal rennt sind es einige Megawatt die da verbrannt werden
;-)
Das alles nur um irgendwelche dusseligen Steine durch die Gegend zu
kutschieren.
Grüße
Frank
Solange man nicht weiß, wieviele Wandlungen/s er braucht, ist
optimieren überflüssige Arbeit. Vielleicht braucht er ja nur 50/s.
Ich denke Jochen hat 2 Möglichkeiten, mehrere DAC an den uC anzukoppeln:
Seriell:
So etwa, wie in Figure 47 und Figure 4 des AD5781 Datasheets.
Ist dort auch erklärt wiesowas funktioniert.
Nachteil ist, dass man jedesmal N*24Bit senden muss.
Wenn man weiß, dass man meistens alle DACs gleichzeitig mit neuen Werten
versorgen wird, ist das ok. Wenn man mal einen DAC in der Reihe nicht
neu
mit Daten versorgen will, sendet man einfach ein NOP-Befehl
an der richtigen Position innerhalb der N*24Bit.
Parallel:
Da muss man nur die 24Bit des betreffenden DAC senden. Man braucht halt
individuelle Select-Leitungen. Alle DAC-SDI sind an einer Leitung und
alle DAC-SDO sind an einer Leitung. Aufpassen, dass nicht mehrere
Selects gleichzeitig aktiv sind.
Hallo Jochen,
so da ich gerade mal eine kurze Verschnaufoasue habe kommt hier ein
Programm wo ich mal versuche auf Leufzeit zu optimieren:
Ich habe die doubles durch unsigned long ersetzt. damit wir trotzdem
noch ausreichend genau rechnen musste ich dafür die Basiswert mit
1000000 mutliplizieren.
ACHTUNG der SPI Takt steht noch auf 1 MHz ;-)
(glaube ich)
1
#include<stdio.h>
2
#include<mc912d128.h>
3
4
constunsignedlongHalfRange=2500000;
5
constunsignedlongDACStepWidth=5000000/0x03ffff;
6
7
voidmySPITrans(unsignedcharmyValue)/*Transmit Byte via SPI*/
8
{
9
unsignedcharmydelete;/* was zum Datenauslesen und verwerfen */
10
11
SP0DR=myValue;/* Data goes to SPI data register*/
12
while((SP0SR&0x80)==0);/* wait for transfer to finish */
13
mydelete=SP0DR;/* Daten auslesen und verwerfen */
14
}
15
16
voidVValueTo18BitDAC(unsignedlongVoltValue)
17
{
18
unsignedlongDACValue=0;
19
unsignedcharmylowbyte=0x00;
20
unsignedcharmymidbyte=0x00;
21
unsignedcharmyhighbyte=0x00;
22
23
DACValue=VoltValue/DACStepWidth;
24
25
DACValue=DACValue<<2;/* shift 2 needed Position in 24Bit Value */
Hallo APW,
habe aus "Langeweile" trotzdem mal nen Versuch der Optimierung
gestartet.
Habe mit Schrecken gelernt das double ja 8 byte lang ist.
Schau mal was Du von meiner Optimierungsidee denkst bitte.
Interrupts möchte ich wenn es eben geht vermeiden, weil damit
überfordern wir Jochen fürchte ich. Dazu kommt das er ja offensichtlich
nix ordentliches zum debuggen hat.
Grüße
Frank
Ich habe nun ein neues Problem:
Ich möchte auf jeden Wert des Sägezahns einen Sinus geben, bei dem ich
Ampl + Frequenz und Anzahl der Perioden einstellen kann.
Das wird das neue Problem ;)
Ich bin für jede Hilfe dankbar :)
Danke!
Hallo Jochen.
schick mal mein Programm durch den geschwindigkeits test ;)
Das will ich jetzt wissen :D
Wie meinst DU auf jeden wert des Sägezahn?
Ich vermute Du willst auf den Sägezahn einen Sinus modulieren?
Grüße
Frank
Zum Thema Sinus habe ich mir überlegt, dass man ja die Amplitude, die
der Sinus haben soll, einfach so umsetzen könnte, dass man zu dem DC
Wert die Werte die man vorher errechnet hat hinzu addiert. Bloß wie man
jetzt die Frequenz umsetzt? Die Sache mit einer oder 2 Perioden könnte
man ja mit einer while-Schleife lösen oder?
Danke.
ok dann haben wir gelernt:
Es waren nicht unbedingt die Fließkommazahlen ;)
(hat der HC12 ne eingebaute FPU??)
das ist schön das hilft und wir können mit dem alten Programm weiter
arbeiten.
Jochen dir muss klar sein: schneller wird es durch den Sinus nicht ;-)
Also Sinus aufmodulieren:
Was ist die maximale amplitude?
Was ist die maximal frequenz?
Grüße
Frank
Hallo Jochen,
das mit den 2 while Schleifen ist so eine Sache:
Du hast ja schon gelernt, das wir das Zeitverhalten des uC nicht 100%
vorhersagen können. Wenn Du jetzt die Frequenz des Sinus über eine
verschachtelte Schleife (im schlimmsten fall mit Wait) erzeugst, dann
gibt das alles nur keinen Sinus mehr.
Um die position im Sinus (und damit den zugehörigen Wert) zu bestimmen
brauchen wir dann doch einen Timer. Alles andere ist halbherzig.
Grüße Frank
Frequenz max: 100 kHz
Ampl max: 19 mA... in Volt... ?? Sagen wir 0,5 V!
Ja das ist schon klar, dass es langsamer wird... es dürfte dann bis zu
0,5s brauchen ein Sinus... bzw 2 Perioden also 2 Sinuse ;)
Danke
Hallo Jochen,
so kommen wir nicht weiter.
Kannst Du mir mal ein Bild skizzieren wie das Signal was ihr am ende
braucht aussehen soll?
Ich muss verstehen was ich Dir erklären soll ;-)
Grüße
Frank
Wollen wir es nicht trotzdem für den Anfang mit einer while-Schleife
probieren? Oder könnt ihr das mit dem Timer schnell umsetzen, bzw mir
dabei helfen? Weil es soll schon nächste Woche laufen :(
Hier mal eine Skizze wie der Sinus an sich aussieht... und dieser kommt
dann auf den Sägezahn bei jeder Stufe die wir haben... dadurch wird der
Sägezahn sehr langsam...
Hallo Jochen,
ok war jetzt nicht ganz was ich erwartet habe aber macht nix.
Ich hab mir hier parallel auch mal ein wenig nen Kopf gemacht:
Ich würde gerne 360 Punkte pro Zyklus setzen (darfst raten warum)
Dann täte ich gerne erst mal nur den Sinus bauen. Das aufmodulieren
machen wir dann im 2. Schritt ;-)
Das Problem das ich jetzt habe:
Ich habe keinen blassen Schimmer über die Timer im HC12.
Da musst Du mal die passenden Passagen im Handbuch suchen und wenn es
geht ein oder 2 Beispiele.
Dann hoffe ich das es eine sin Funktion in deinen Bibliotheken gibt!?
Kannst Du das bitte rausfinden? Wenn es die nicht gibt, dann werden wir
uns ein Tabelle mit den entsprechenden Werten basteln müssen.
Alles klar?
Dann los ans Werk ;-)
Grüße
Frank
Floating-Point Math Functions
ICCV7 for CPU12 generates reentrant code including floating-point
mathematics (at V6, ICC12 floating-point code is non-reentrant due to
the use of static variables).
The following floating-point math routines are supported. You must
#include <math.h> before using these functions.
float asinf(float x)
returns the arcsine of x for x in radians.
float acosf(float x)
returns the arccosine of x for x in radians.
float atanf(float x)
returns the arctangent of x for x in radians.
float atan2f(float y, float x)
returns the angle whose tangent is y/x, in the range [-pi, +pi] radians.
float ceilf(float x)
returns the smallest integer not less than x.
float cosf(float x) )
returns the cosine of x for x in radians.
float coshf(float x)
returns the hyperbolic cosine of x for x in radians.
float expf(float x)
returns e to the x power.
float exp10f(float x)
returns 10 to the x power.
float fabsf(float x)
returns the absolute value of x.
float floorf(float x)
returns the largest integer not greater than x.
float fmodf(float x, float y)
returns the remainder of x/y.
float frexpf(float x, int *pexp)
returns a fraction f and stores a base-2 integer into *pexp that
represents the value of the input x. The return value is in the interval
of [1/2, 1) and x equals f * 2**(*pexp).
float froundf(float x)
rounds x to the nearest integer.
float ldexpf(float x, int exp)
returns x * 2**exp.
float logf(float x)
returns the natural logarithm of x.
float log10f(float x)
returns the base-10 logarithm of x.
float modff(float x, float *pint)
returns a fraction f and stores an integer into *pint that represents x.
f + (*pint) equal x. abs(f) is in the interval [0, 1) and both f and
*pint have the same sign as x.
float powf(float x, float y) )
returns x raised to the power y.
float sqrtf(float x) )
returns the square root of x.
float sinf(float x)
returns the sine of x for x in radians.
float sinhf(float x)
returns the hyperbolic sine of x for x in radians.
float tanf(float x) )
returns the tangent of x for x in radians.
float tanhf(float x)
returns the hyperbolic tangent of x for x in radians.
Since, by default, float and double have the same size (32 bits), math.h
also contains a set of macros that map the function names to be without
the f suffix form. For example, pow is the same as powf, sin is the same
as sinf, etc.
Daraus haben wir hier die Fkt:
float sinf(float x)
returns the sine of x for x in radians.
Schonmal einwas ;)
Der Timer heißt beim HC12 Enhanced Capture Timer... soweit ich weiß...
nur ich habe auch damit so gut wie noch nie gearbeitet...
Außer dieses Blink-Programm:
ok dann basteln wir erst mal einen kleinen Sinus mit unbestimmter
frequenz nur so zum üben:
kannst schon mal das Sägezahnprogramm mit fleißkomma wieder raus suchen
und oben die maths Bibliothek einfügen.
Code schnipsel kommt gleich ;-)
Frank
Uff das schockiert mich jetzt!
kannste mal eines mit 0,5 MHz machen?
ich verstehe gerade nicht was das Probelm ist das der keine 360 Schritte
pro Zyklus macht :-(
Hallo APW
da gibt es derzeit beim Jochen etwas Klärungsbedarf und es werden viele
Werte durcheinander geworfen.
Ich glaube er braucht da was Zeit um das zu klären ;)
Grüße
Frank
Überleg dir mal, mit SPI können wir max 166000 Werte/s an einen (1) DAC
senden. Wenn das dein Ernst ist, kannst du schonmal den C-Compiler
weglegen.
Das wird nur mit Integer+Hardcore Assembler was. Und selbst dann reicht
es lange nicht.
Soll der Sinus auf den Sägezahn addiert oder multipliziert werden ?
Übrigens wegen
1
VValueTo18BitDAC(myVValue);
2
myVValue=2.5+sin(GradZaehler++);
3
if(GradZaehler>360)
4
GradZaehler=1;
Das muss Radiant sein, nicht Grad.
Und der HC12 hat keine FP-Unit, nur einige Befehle, die den Compiler
dabei
unterstützen können. Wobei der ICC wahrscheinlich nicht den schnellsten
Code erzeugt.
Wenn die Speed-Anforderungen so hoch sind und es überhaupt HC12-artig
sein soll, dann würde ich nen HCS12, oder viel besser (und komplexer)
HCX12 nehmen, eine DAC event. parallel anbinden und wenn man auf C
besteht, den CodeWarrior-Compiler nehmen.
Diese Card12 gibts auch mit HCS12 und HCX12
Das heißt also besser wie so komme ich nicht mit dieser Karte... Und
wenn wir einfach die Sinus-Werte in ein Array legen und danach erst
schreiben???
Also die Sinus-Rechnung vor der eigentlichen Schreib-Operation machen?
J. R. schrieb:> @APW: Welche Frequenz meinst du dann, dass wir überhaupt schaffen?
Kommt drauf an, wie kompromisslos du programmierst.
-kein Float, wenns eilig ist
-Werte vorberechnen
-Assembler benutzen
-nicht universeller (=langsamer/komplexer/mehr code) programmieren,
als es die Aufgabenstellung (die wir nicht kennen) erfordert.
-Timings planen
Ohne Kenntnis der Aufgabenstellung kann man nichts genaues über
die Machbarkeit sagen.
@APW
Ich fürchte das wir bald erkennen werden, das selbst mit optimalster
Programmierung der HC12 seine Grenzen erreicht.
Dennoch würde ich gerne das ganze weiter treiben, nicht zuletzt damit
Jochen die Möglichkeiten kennt und das auf einen anderen (schnelleren)
Prozessor umsetzen kann.
Grüße
Frank
@ Jochen
das ist die Umrechung von Grad in Bogenmaß.
Der sinus in C (und allen anderen programmiersprachen) arbeitet mit
Bogenmaß ;-)
APW hat es geasgt und ich habe jetzt ein Beißspur im Schreibtisch ;-)
Grüße
frank
Hallo Jochen,
ok der Peak beim 0 Durchlauf da will ich jetzt mal nicht pingelig sein.
;-)
Den bekommen wir noch weg ;-)
Damit haben wir einen Sinus.
Gib mir bitte heute Abend um mal die Timernummer zu studieren.
Ich denke das ich aus dem Timer einen Sinus bauen kann und wir in der
Main routine nur den Basis wert generieren.
Ich hab da so eine Idee ;-)
Grüße
Frank
Frank Sander schrieb:> Ach ja der ist herrlich ;-)>> if (GradZaehler == 360)>> dann funkts
Naja :) einen Peak hab ich aber noch ;) manchmal auch mehr... immer beim
0-Durchgang... ???
1
while(i>0)/* Endles Data sending for testing only */
Frank Sander schrieb:> Wenn Du den Oscar weiter auflöst, kommt der dann bei jedem Zyklus?
Er kommt und geht immer bei 0-Durchgängen.... siehe Bilder...
Manchmal ist der Peak auch total weg... und im nächsten Moment ist er
wieder da... :(
Hallo Jochen,
ich vermute das der Oscar den peak nicht immer auflöst.
Den bekommen wir weg, das ist kein Problem.
Kannst DU bitte mal einen Zyklus die genaue Länge bestimmen?
Grüße
Frank
Hallo Jochen,
Hallo APW,
ich hab da mal wieder was gebastelt ;-)
Ob das funktioniert? Keine Ahnung!
Ich habe net alles verstanden was ich aus dem Timer Beispiel geklaut
habe.
Evtl. findet ja noch jemand was mehr Text zu dem Timer im HC12
Jochen ist mal wieder das Versuchstier :-D
Fehlermeldungen bitte zu mir.
Anregungen bitte auch zu mir.
Grüße
Frank
1
#include<stdio.h>
2
#include<mc912d128.h>
3
#include<math.h>
4
5
constdoubleHalfRange=2.5;
6
constdoubleDACStepWidth=5.0/0x03ffff;
7
8
doubleGradZaehler=1;
9
doubleSinusOffset=0.5;
10
doubleSinusAmplitude=0.5;
11
12
void_HC12Setup(void)/* interesting but I did not see it is called some were */
13
{
14
COPCTL=0x08;// disable Watchdog
15
}
16
17
#pragma interrupt_handler isrOC2 /* this most probably tells the Compiler about the interrupt hanlder */
18
19
voidisrOC2(void)
20
{
21
unsignedlongDACValue=0;
22
unsignedcharmylowbyte=0x00;
23
unsignedcharmymidbyte=0x00;
24
unsignedcharmyhighbyte=0x00;
25
unsignedcharmydelete;/* was zum Datenauslesen und verwerfen */
26
doubleVoltValue=0;
27
28
TFLG1=0x04;// clear OC2 Intr Flag
29
TC2+=3125u;// 1 interrupt every 3125 timer ticks (0.05s) is kind of slow but good for the start ;-)
Hallo Frank
Eine Frage. Hast du schon mal uC programmiert ?
(Ich meine mehr als 100 Zeilen und mit Interrups und so).
Bitte nicht übelnehmen.
In deinem Quellcode hats ein paar Sachen drin, da könnte ich schlaflose
Nächte bekommen ;)
Hallo APW,
jep habe ich. Ist aber 20 Jahre her. Von daher würde ich mich heute
wieder Anfänger nennen.
Habe allerdings noch nie Interrupts in C eingebunden. Dafür habe ich
früher immer Assembler pur gearbeitet.
Sag mal an was Dich beunruhigt. Ich will ja auch dazulernen.
Sorry wenn ich Dir die Nachtruhe raube. ;-)
Grüße
Frank
Ich hab gedacht ihr überlegt euch, was euch gleich um die Ohren fliegt,
und was euch erst später probleme macht.
Frage an Jochen:
Benutzt du TwinPeeks? Außerdem verwendest du ICC mit den Bibliotheken
in der Version 7?
Hallo Jochen,
Du kannst ja die Zeit nutzen und schon mal eine Tabelle mit den 360
Werten für den Sinus generieren ;-)
Damit können wir dann den sin() rauswerfen. Kommt sicherlich der
Geschwindigkeit zugute.
Grüße
Frank
Hallo APW
sag an was Dich am meisten stört und ich werde versuchen mich zu
bessern.
Leider steh ich das den HC12 betrifft etwas auf dem Schlauch, weil ich
den vorher noch nicht genutzt habe. Unterlagen habe ich nur was ich
bisher aus dem Netz gesammelt habe.
Da ich das ganze neben meinem normalen Job betreibe, bitte ich um
Nachsicht bei den diversen Böcken die ich einbaue. Ich hoffe das Jochen
trotzdem die Ideen die dahinter stecken versteht und umsetzen kann.
Grüße
Frank
Frank Sander schrieb:> Hallo APW>> sag an was Dich am meisten stört und ich werde versuchen mich zu> bessern.> Leider steh ich das den HC12 betrifft etwas auf dem Schlauch, weil ich> den vorher noch nicht genutzt habe. Unterlagen habe ich nur was ich> bisher aus dem Netz gesammelt habe.>> Da ich das ganze neben meinem normalen Job betreibe, bitte ich um> Nachsicht bei den diversen Böcken die ich einbaue. Ich hoffe das Jochen> trotzdem die Ideen die dahinter stecken versteht und umsetzen kann.>> Grüße> Frank
Ich will es versuchen Meister ;)
Frank Sander schrieb:> Hallo Jochen,>> Du kannst ja die Zeit nutzen und schon mal eine Tabelle mit den 360> Werten für den Sinus generieren ;-)>> Damit können wir dann den sin() rauswerfen. Kommt sicherlich der> Geschwindigkeit zugute.>> Grüße> Frank
Soll ich die dann mit dem Taschenrechner berechnen? Oder wie würdest du
da vorgehen?
Hallo Jochen,
Ich persönlich bin ja eine faule Sau :-D, deswegen würde ich z.B. Excel
dafür nutzen.
Geht einfacher und schneller ;)
Ausserdem kannst Du von da die Daten einfacher übernehmen.
Wenn Du dann noch sofort die 18 Bit werde generierst.... Das wäre mal ne
so schlecht ;-)
Grüße
Frank
Hallo Jochen,
das sieht doch schon net schlecht aus.
Da müssen die 0 udn max werte noch korrigiert werden ;-)
Dann das ganze mit der Schrittweite multipliziert ergibt die Werte
welche wir für den DAC brauchen.
Grüße
Frank
Da sind einige Fallen drin, kleine wie große. Und die sind nichtmal
HC12-spezifisch.
Mal der Reihe nach (kein Anspruch auf Vollständigkeit)
1) SinusOffset: Damit rechnest du in der Haupschleife UND in
der Interruptfunktion (kurz ISR)
a)Was passiert, wenn die ISR Variablen verwendet, die vielleicht
zum Interruptzeitpunkt gerade in der Haupschleife bearbeitet werden ?
-> aus ISR rauswerfen oder in der Haupschleife z.B. mit kurzen (!!)
Interruptsperren absichern
b)Wiedereintrittsfähigkeit (siehe auch Docu zum ICC6/7).
Hier habt ihr reines Glück, dass Jochen den ICC V7 verwendet,
bei ICC V6 (und auch bei einigen anderen Entwicklungsumgebungen)
kann die gleichzeitige Verwendung von Float-Rechnungen
in einer ISR und in der Haupschleife schiefgehen.
In der ICC-Doku steht:
ICCV7 for CPU12 generates reentrant code including floating-point
mathematics (at V6, ICC12 floating-point code is non-reentrant due to
the use of static variables).
2) Halte die ISR so kurz wie möglich. Das mag jetzt noch funktionieren,
aber irgendwann, wenn man nicht aufpasst ist auf einmal die Zeit
für die ISR-Abarbeitung länger als als das ISR-Timerintervall.
Das sind folgende Double-Rechnungen
1x sin(), 2x Multiplikationen,
1x Addition, 1x Division, 1x Konvertierung Double->Long
Das frisst Zeit, und sollte nich in einer ISR stehen.
Ich würde alles vorberechnen und in der ISR nur noch die
fertigen Bytes über SPI rausschieben.
3) // Timer Setup
TSCR = 0x80; // Timer enable
...(Timer Register init)
Ich würde generell empfehlen, den Timer erst zu enablen, wenn die
anderen Timer-Register initialisiert worden sind. Das kann dazu
führen, dass das erste Zeitintervall nicht stimmt.
Am WE Veruche ich mal, das Programm (mit einigen Anpassungen) auf meiner
HW (S12Compact) laufen zu lassen. Da ist ein 16Bt DAC drauf, der auch
über SPI angebunden ist.
Wegen dem Sinus: Der DT128 hat doch 8KB Ram.
Da kann man locker eine Sinustabelle im Init-Teil des
Programms vorberechnen, am besten gleich als Ganzzahl !?
Frank Sander schrieb:> Hallo Jochen,>> das sieht doch schon net schlecht aus.> Da müssen die 0 udn max werte noch korrigiert werden ;-)>> Dann das ganze mit der Schrittweite multipliziert ergibt die Werte> welche wir für den DAC brauchen.>> Grüße> Frank
Hab nochmal das Diagramm durch ein ungerundetes ergänzt ;)
Aber ich verstehe jetzt nicht was du noch gerechent haben willst?
Kannst du mir mal die Fkt dazu hinschreiben?
APW schrieb:> Da sind einige Fallen drin, kleine wie große. Und die sind nichtmal> HC12-spezifisch.>> Mal der Reihe nach (kein Anspruch auf Vollständigkeit)> 1) SinusOffset: Damit rechnest du in der Haupschleife UND in> der Interruptfunktion (kurz ISR)> a)Was passiert, wenn die ISR Variablen verwendet, die vielleicht> zum Interruptzeitpunkt gerade in der Haupschleife bearbeitet werden ?> -> aus ISR rauswerfen oder in der Haupschleife z.B. mit kurzen (!!)> Interruptsperren absichern> b)Wiedereintrittsfähigkeit (siehe auch Docu zum ICC6/7).> Hier habt ihr reines Glück, dass Jochen den ICC V7 verwendet,> bei ICC V6 (und auch bei einigen anderen Entwicklungsumgebungen)> kann die gleichzeitige Verwendung von Float-Rechnungen> in einer ISR und in der Haupschleife schiefgehen.> In der ICC-Doku steht:>> ICCV7 for CPU12 generates reentrant code including floating-point> mathematics (at V6, ICC12 floating-point code is non-reentrant due to> the use of static variables).>> 2) Halte die ISR so kurz wie möglich. Das mag jetzt noch funktionieren,> aber irgendwann, wenn man nicht aufpasst ist auf einmal die Zeit> für die ISR-Abarbeitung länger als als das ISR-Timerintervall.>
> Das sind folgende Double-Rechnungen> 1x sin(), 2x Multiplikationen,> 1x Addition, 1x Division, 1x Konvertierung Double->Long>> Das frisst Zeit, und sollte nich in einer ISR stehen.> Ich würde alles vorberechnen und in der ISR nur noch die> fertigen Bytes über SPI rausschieben.>> 3) // Timer Setup> TSCR = 0x80; // Timer enable> ...(Timer Register init)> Ich würde generell empfehlen, den Timer erst zu enablen, wenn die> anderen Timer-Register initialisiert worden sind. Das kann dazu> führen, dass das erste Zeitintervall nicht stimmt.>> Am WE Veruche ich mal, das Programm (mit einigen Anpassungen) auf meiner> HW (S12Compact) laufen zu lassen. Da ist ein 16Bt DAC drauf, der auch> über SPI angebunden ist.>> Wegen dem Sinus: Der DT128 hat doch 8KB Ram.> Da kann man locker eine Sinustabelle im Init-Teil des> Programms vorberechnen, am besten gleich als Ganzzahl !?
Zu 3. : Du würdest das also drehen...
// Timer Setup
TSCR = 0x80; // Timer enable
TMSK2 = 0x07; // Prescaler = 128 (1 timer tick every 16ìs)
TCTL2 = 0x00; // TC2 disconnected from Pin
TIOS |= 0x04; // TC2 is Output Compare
TMSK1 |= 0x04; // TC2 Interrupt enable
TSCR = .... ganz nach unten?
Hallo APW,
1a: Mist da habe ich wirklich net bedacht :-(
Ich war davon ausgegangen das ein reiner lesezugriff im Handler mir
keine Probleme bereitet.
1b: Jep verstanden! So langsam kommt es mir wieder wieso ich früher
immer gepredigt habe interrupt handler nur in assembler zu schreiben. Da
wäre ich auf die Idee gar net gekommen floating point zu nutzen ;-)
2: rechst haste, deswegen habe ich die Zeit im Moment auch noch so lang
gelassen.
Die Idee hinter dem Programm:
Sinus wird durch den timer gebaut. Damit bekomme ich den halbwegs
stabil.
Mit dieser Version wollte ich die generelle Idee testen. Optimierung
(sin() raus, floating point raus) sollten dann folgen.
3. Ups, den Teil habe ich einfach übernommen und net gesehen das da die
Reihefolge vertauscht ist. Sorry, ich gelobe Besserung, habt Geduld mit
einem alten Mann ;-)
Wäre klasse wenn Du am WE das ganze mal was mehr gerade rücken könntest.
Ich werde mit Jochen bis dahin mal versuchen alles was an floating point
weg optimiert werden kann weg zu optimieren ;-)
Grüße
Frank
const long SinusWerte[] = {0, 915, 1830, 2744, 3657, 4569, 5480, 6389,
7297, 8202, 9104, 10004, 10901... };
so fängt die Tabelle an. Kannst Du das bitte komplettieren.
Hey!
In Office werde ich gleich reingehen und mein Glück versuchen... mom
erst einmal die Screenshots vom Programm wie du es mir geschickt
hast.... ;)
Danke!
PS: Sieht man da den Sinus???
Hallo Jochen,
das die Werte negativ werden ist genau was wir wollen ;-)
Kannst Du bitte (in unserem Programm ohne Interrupt) die Tabelle
generieren?
Definition habe ich oben schon stehen ;-)
Ich werde derweil die anderen Änderungen vorbereiten.
Grüße
Frank
Hallo Jochen,
Ich denke wir warten mit der Interruptroutine noch ein wenig.
Mein Vorschlag funkt ja auch net wirklich ;-)
Wenn wir für APW das ganze vorbereiten das die floating point
Berechnungen weg sind wäre das Klasse.
Am WE werde ich versuchen mich in den Timer einzulesen.
Grüße Frank
Läuft net wie es soll??? Habe mein Programm an den entsprechenden
Stellen ausgebessert... keine Fehler gemeldet... kannst du nochmal
drüber schauen, dass auch alles stimmt?
Oben Screen vom Oszi....
lol stimmt!!!
schau mal auf den Wert i und unter welche Bedingung die while Schleife
rennt ;)
Korrigier das bitte mal, da habe ich irgendwas verdreht :-(
Dann werden wir uns mal den Peaks widmen.
Kannst Du mal mit dem Oscar spielen das wir uns so einen Peak geaneur
anschauen können?
Also den Peak vergößern
Stell mal nur eine Halbwelle auf dem Oscar dar
Ich will sicher stellen das es wirklich der 0 Durchlaf ist. Sieht mir
aber ganz feste danach aus.
da tun wir mal folgende Zeile ändern:
if (VoltValue <= 0x1ffff) /* Check for Halfrange */
wird
if (VoltValue < 0x1ffff) /* Check for Halfrange */
Peak in nah! Ich muss nun leider für heute Schluss machen! Hab noch
etwas anderes zu erledigen das wichtiger ist ;) Arbeit :(
Moin geht's von meiner Seite hier weiter!
Gruß & Danke
Hallo APW
kannst Du mir bitte deine e-mail via PN schicken?
Ich hatte gestern ein längeres Gespräch mit Jochen und wir würden Dich
gerne auch informieren, aber nicht unbedingt hier ;-)
Dank Dir
Grüße
Frank