Lieber Besucher, herzlich willkommen bei: RCLine Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Chris Benndorf

RCLine User

  • »Chris Benndorf« ist der Autor dieses Themas

Wohnort: 67317 Altleiningen & 70567 Stuttgart

Beruf: Computerfredl

  • Nachricht senden

61

Sonntag, 25. Juli 2004, 12:50

Zitat

Original von moelski
Soderle, ich habe mal ein bisserl was zusammengeschrieben.


Sieht guuuut aus!

BTW: Mir fehlen noch ein paar Bytes fuer die "mehrere Fluege"-Erfassung - genaugenommen habe ich ein paar zuviel (100,5% Fuellung :( )
Heli: T-Rex 600 Pro Nitro/3G, 600 ESP/3G und 450 Pro/3G
Sender: Futaba FF-10 2,4GHz :D

Chris Benndorf

RCLine User

  • »Chris Benndorf« ist der Autor dieses Themas

Wohnort: 67317 Altleiningen & 70567 Stuttgart

Beruf: Computerfredl

  • Nachricht senden

62

Sonntag, 25. Juli 2004, 14:50

So, der Logger kann jetzt mehrere Fluege hintereinander erfassen. Er funktioniert allerdings nur noch mit EEPROMs >= 24C64, da er die 16-Bit Adressierung nutzt

Solange der Signal-Kanal ueber ca. 1/3 Weg hat, wird aufgezeichnet. Kommt das Signal darunter, wird die Aufzeichnungslaenge weggeschrieben. Kommt das Signal wieder darueber, wiederholt sich das ganze...

Das Datenformat sieht jetzt so aus (Bsp: 2 Fluege):

72;9;0;84;78
66;9;0;84;78
60;9;0;83;78
54;9;0;83;78
48;9;0;84;78
42;9;0;84;78
36;9;0;84;78
30;9;0;84;78
24;9;0;84;78
18;9;0;84;78
12;9;0;84;78
6;9;0;84;78
0;8;0;84;79
72;9;0;84;78
66;9;0;84;78
60;9;0;83;78
54;9;0;83;78
48;9;0;84;78
42;9;0;84;78
36;9;0;84;78
30;9;0;84;78
24;9;0;84;78
18;9;0;84;78
12;9;0;84;78
6;9;0;84;78
0;8;0;84;79

Die erste Zahl ist die Anzahl der noch folgenden Bytes (2 Bytes Drehzahl, 2 Bytes Strom, 1 Byte Spannung und 1 Byte Temp). Es wird also immer bis auf 0 runtergezaehlt und dann faengt ggf. der naechste Flug an (Ein EndOfData gibt's derzeit noch nicht, das baue ich aber noch rein.)

Das ist zwar gewohnungsbeduerftig :dumm: aber aufgrund einiger Optimierung ist mir nichts Besseres eingefallen (Das Basic-Programm ist aus der u.g. Webseite hinterlegt, es werden noch Opitmierungsvorschlaege angenommen :)

Ich habe mir auch mal den Assembler-Code angesehen, der vom Compiler erzeugt wird, viel ist da nicht rauszuholen, es sei denn, man geht direkt auf Assembler und spart einige Bytes an PUSH und POPs.
Heli: T-Rex 600 Pro Nitro/3G, 600 ESP/3G und 450 Pro/3G
Sender: Futaba FF-10 2,4GHz :D

thmarx

RCLine User

Wohnort: D-06108 Halle

  • Nachricht senden

63

Sonntag, 25. Juli 2004, 17:12

Hi Chris,

unser mail-server ist abgestürzt, sonst hätte ich schon mal geantwortet.
Sieht ja schon ganz gut aus. Ich habe inzwischen den Teil zur Drehzahlmessung geändert. Die Interrupts werden jetzt nur noch zur Messung aktiviert weil sie sonst das I2C-Bustiming stören können.

Zitat

_ovf0:
$asm
push zl '
in zl,SREG '
push zl '

lds zl,{Wtimer0hi} ' WTimer0 bildet einen 16Bit-Timer
inc zl ' High-Byte von WTimer0 wird
sts {Wtimer0hi},zl ' hochgezählt

pop zl '
Out Sreg , Zl '
pop zl '
$end Asm

' Incr Wtimer0hi
Return

_aci:
' Wtimer0lo = Timer0 'Version1: Timer0 und Wtimer0
' Wcompare = Wtimer0 - Wcomparesave ' laufen ständig
' Wcomparesave = Wtimer0 '

Wtimer0lo = Timer0 'Version2: Timer0 und WTimer0
Timer0 = 0 ' werden bei Comparator Int
Wcompare = Wtimer0 ' zurückgesetzt
Wtimer0hi = 0 ' 12 Byte kürzer als Version1
Return

Sub Getrpm
Timer0 = 0
Wtimer0 = 0
Tifr.tov0 = 1
Enable Ovf0
Enable Aci
Wcompare = 0
_getrpm_l1:
If Wtimer0.15 = 1 Then Goto _getrpm_l3
If Wcompare = 0 Then Goto _getrpm_l1
Wcompare = 0
_getrpm_l2:
If Wtimer0.15 = 1 Then Goto _getrpm_l3
If Wcompare = 0 Then Goto _getrpm_l2
_getrpm_l3:
Disable Ovf0
Disable Aci
End Sub


Am Ende steht in Wompare die Zeit zwischen zwei Impulsen. Umzurechnen:
RPM=7500000/Wcompare
RPM=RMP/2 <-- Anzahl der Impulse/Umdrehung
Die Ausführungszeit der Routine ist drehzahlabhängig, maximal ca. 530ms. Das muss bei der Pause im Hauptprogramm beachtet werden.

Die Ausgaberoutine muss noch kürzer werden, die verbraucht ein Drittel des Speichers im uC.
Gruss Thomas
Thomas Marx

Chris Benndorf

RCLine User

  • »Chris Benndorf« ist der Autor dieses Themas

Wohnort: 67317 Altleiningen &amp; 70567 Stuttgart

Beruf: Computerfredl

  • Nachricht senden

64

Sonntag, 25. Juli 2004, 18:29

Hi Thomas!

Mit der Aenderung bin ich bei 104% :( Wo sollen wir das noch wegkuerzen? Bekommt man Getrpm mit Assembler noch etwas schlanker?

BTW: Ich habe vorhin einen Testflug gemacht und Spannung und Strom laufen sauber. Temperatur muss ich noch "eichen" und Drehzahl ist eine pure Katastrophe :dumm:
Heli: T-Rex 600 Pro Nitro/3G, 600 ESP/3G und 450 Pro/3G
Sender: Futaba FF-10 2,4GHz :D

moelski

RCLine User

Wohnort: Brilon / HSK

Beruf: IT Welt

  • Nachricht senden

65

Sonntag, 25. Juli 2004, 19:42

Moin Thomas & Chris!

Zitat

Mit der Aenderung bin ich bei 104%

Sollte man nicht doch über einen anderen/größeren Chip nachdenken? Z.B. der Mega16. Der hat 2 Differential Channels with Programmable Gain at 1x, 10x, or 200x. Und 16KB Flash - also genug für evtl. Erweiterungen. Der Chip ist allerdings ein bisserl größer aber immer noch von als DIP von Hand verlötbar.
So sähe das Teil aus:
Greetz Dominik

[SIZE=4]LogView - Datenvisualisierung für Modellbauer[/SIZE]
Besucht mal unsere Webseite oder schaut mal ins Forum.

Chris Benndorf

RCLine User

  • »Chris Benndorf« ist der Autor dieses Themas

Wohnort: 67317 Altleiningen &amp; 70567 Stuttgart

Beruf: Computerfredl

  • Nachricht senden

66

Sonntag, 25. Juli 2004, 19:54

Zitat

Original von Chris Benndorf
Mit der Aenderung bin ich bei 104% :( Wo sollen wir das noch wegkuerzen?


Hab noch 11% gefunden :nuts: Bin jetzt wieder bei 93%, habe aber im Augenblick keine Wesswerte mehr :dumm:
Wie bringen wir aber eine Wartezeit ein, die abhaengig von der Laufzeit der Drehzahlroutine ist?
Heli: T-Rex 600 Pro Nitro/3G, 600 ESP/3G und 450 Pro/3G
Sender: Futaba FF-10 2,4GHz :D

Chris Benndorf

RCLine User

  • »Chris Benndorf« ist der Autor dieses Themas

Wohnort: 67317 Altleiningen &amp; 70567 Stuttgart

Beruf: Computerfredl

  • Nachricht senden

67

Sonntag, 25. Juli 2004, 19:57

Zitat

Original von moelski
Sollte man nicht doch über einen anderen/größeren Chip nachdenken? Z.B. der Mega16.


Willst Du einen Ladenhueter loswerden? Der ist vom Oktober 03 und hat das Haltbarkeitsdatum schon fast ueberschritten :evil:

Neeee, bevor wir zu schweren Geschuetzen greifen, muessen wir noch die Trickkiste ausnutzen ;)
Heli: T-Rex 600 Pro Nitro/3G, 600 ESP/3G und 450 Pro/3G
Sender: Futaba FF-10 2,4GHz :D

thmarx

RCLine User

Wohnort: D-06108 Halle

  • Nachricht senden

68

Sonntag, 25. Juli 2004, 21:06

@Dominik:

Dein Prototyp" ist praktisch fertig, nur noch Chip einsetzen und testen.

@Chris:
stell ma Deine letzte Variante online. Für die Verzögerung müssen wir einen Timer nehmen. Timer1 wäre ja noch frei, vielleicht auch Timer0 mitbenutzen (ist aber komplizierter und braucht sicher wieder mehr Platz).
Ausserdem bin ich dafür die Daten seriell ohne vorherige Aufbereitung auszugeben (also hinereinander weg byteweise was im EEProm steht). Das spart sicher nochmal eine gutes Stück.
Ausserdem habe ich gerade den
Adapter getestet. Damit kann ich in der Schaltung mit Ponyprog den EEProm auslesen - einfach Reset während des auslesens auf 0 halten. Läuft unter allen Windows-Versionen. Eine DLL für den direkten Portzugriff scheint es hier zu geben. Jetzt fehlt halt nur noch eine I2C-Routine im PC-Programm. Da müssten dann auch die Werte wieder zusammengebastelt werden. Wenn das ginge könnte man den seriellen Kram im uC ganz weglassen.

Gruß
Thomas
Thomas Marx

moelski

RCLine User

Wohnort: Brilon / HSK

Beruf: IT Welt

  • Nachricht senden

69

Sonntag, 25. Juli 2004, 21:27

Moin !

Zitat

Dein Prototyp" ist praktisch fertig, nur noch Chip einsetzen und testen.

Goile Sache :ok:

Und jetzt mal ein paar Infos wegen I2C... Also ich sach mal so. Das ganze kann funktionieren. Aber unter NT Systemen hat man mit dem Prob zu kämpfen, dass das System keinen direkten Zugriff auf die Hardware erlaubt und gerade bei den Ports ist das so eine Sache...
Irgendwie muss es ja gehen, denn PonyProg macht das ja auch ... Nur wie :dumm: Ihr stellt mich vor leichte Rätzel, aber ich arbeite dran 8)
Greetz Dominik

[SIZE=4]LogView - Datenvisualisierung für Modellbauer[/SIZE]
Besucht mal unsere Webseite oder schaut mal ins Forum.

Chris Benndorf

RCLine User

  • »Chris Benndorf« ist der Autor dieses Themas

Wohnort: 67317 Altleiningen &amp; 70567 Stuttgart

Beruf: Computerfredl

  • Nachricht senden

70

Sonntag, 25. Juli 2004, 21:41

Hi Thomas,

Listing ist online, funktioniert aber derzeit nicht ==[] Irgendwie werden nur noch Nullen gespeichert oder gelesen :dumm: Vielleicht seht ihr ja, warum das so ist, ich steh naemlich, wie Ochs vorm Berg...

> I2C/Ponyprog
Mal gucken, ob ich eine so komplitueckische Schaltung noch basteln kann... Ansonsten ist das natuerlich fein, die Serielle loszuwerden. Dann brauchen wir aber gleichzeitig eine Auswertung/Aufbereitung - das ist auch der Grund, warum ich es als ASCII ausgebe!
Heli: T-Rex 600 Pro Nitro/3G, 600 ESP/3G und 450 Pro/3G
Sender: Futaba FF-10 2,4GHz :D

moelski

RCLine User

Wohnort: Brilon / HSK

Beruf: IT Welt

  • Nachricht senden

71

Sonntag, 25. Juli 2004, 21:48

Moin !

Zitat

Ansonsten ist das natuerlich fein, die Serielle loszuwerden

Nicht zu früh freuen. Ich glaube die Inpout32.dll bringt uns erstmal nicht soviel weiter. Generell wird eh davon abgeraten, einen I2c Bus direkt mit dem Parallelport auszulesen...

Seriell ist irgendwie schöner :nuts:
Greetz Dominik

[SIZE=4]LogView - Datenvisualisierung für Modellbauer[/SIZE]
Besucht mal unsere Webseite oder schaut mal ins Forum.

Chris Benndorf

RCLine User

  • »Chris Benndorf« ist der Autor dieses Themas

Wohnort: 67317 Altleiningen &amp; 70567 Stuttgart

Beruf: Computerfredl

  • Nachricht senden

72

Sonntag, 25. Juli 2004, 21:52

Zitat

Original von moelski
Und jetzt mal ein paar Infos wegen I2C... Also ich sach mal so. Das ganze kann funktionieren. Aber unter NT Systemen hat man mit dem Prob zu kämpfen, dass das System keinen direkten Zugriff auf die Hardware erlaubt und gerade bei den Ports ist das so eine Sache...
Irgendwie muss es ja gehen, denn PonyProg macht das ja auch ... Nur wie :dumm:


Das geht genau mit der von Thomas erwaehnten DLL...

Wobei ja die PCs heute alle den SM-Bus (oder so) habe, der nichts anderes, als ein I2C/TWI ist... Aber dann sind wir richtig in der Hardware des PCs (Chipsatz direkt programmieren :nuts: Hab ich schonmal fuer Linux gemacht -> www.ganzfix.de -> txwd :D )
Heli: T-Rex 600 Pro Nitro/3G, 600 ESP/3G und 450 Pro/3G
Sender: Futaba FF-10 2,4GHz :D

thmarx

RCLine User

Wohnort: D-06108 Halle

  • Nachricht senden

73

Sonntag, 25. Juli 2004, 21:59

Hi Chris,

R4 und R5 in der Schaltung kannst Du weglassen (sind ja schon auf dem Logger). Dafür eine Verbindung von Reset(Logger) and Pin4(SubD) und eine von MISO and Pin11. Dann sollte auch Bascom funktionieren , wenn Du progs.settings anpasst. Bei mir gehts noch nicht, der Bascom Programmer schaltet die Reset-Leitung nicht. Keine Ahnung warum.

Thomas
Thomas Marx

moelski

RCLine User

Wohnort: Brilon / HSK

Beruf: IT Welt

  • Nachricht senden

74

Sonntag, 25. Juli 2004, 22:08

Moin !

Zitat

Das geht genau mit der von Thomas erwaehnten DLL...

Naja, sagen wir mal so. Die DLL gibt dir die Möglichkeit ohne Umwege direkt auf den par. Port zuzugreifen. Aber dadurch hat man noch kein I2C. Und das mal eben runterproggen ... Das übersteigt bei weitem dieses Projekt ...

Ich hoffe ich finde noch was brauchbares ... Suche weiter 8(
Greetz Dominik

[SIZE=4]LogView - Datenvisualisierung für Modellbauer[/SIZE]
Besucht mal unsere Webseite oder schaut mal ins Forum.

Chris Benndorf

RCLine User

  • »Chris Benndorf« ist der Autor dieses Themas

Wohnort: 67317 Altleiningen &amp; 70567 Stuttgart

Beruf: Computerfredl

  • Nachricht senden

75

Sonntag, 25. Juli 2004, 22:13

Zitat

Original von thmarx
Bei mir gehts noch nicht, der Bascom Programmer schaltet die Reset-Leitung nicht. Keine Ahnung warum.


Weil Du keinen PullUp drin hast :evil:
Heli: T-Rex 600 Pro Nitro/3G, 600 ESP/3G und 450 Pro/3G
Sender: Futaba FF-10 2,4GHz :D

Chris Benndorf

RCLine User

  • »Chris Benndorf« ist der Autor dieses Themas

Wohnort: 67317 Altleiningen &amp; 70567 Stuttgart

Beruf: Computerfredl

  • Nachricht senden

76

Sonntag, 25. Juli 2004, 22:15

Zitat

Original von moelski
Aber dadurch hat man noch kein I2C. Und das mal eben runterproggen ... Das übersteigt bei weitem dieses Projekt ...


I2C ist eigentlich nicht viel aufwand. Was ist Delphi eigentlich? Pascal? (Entschuldige meine Unwissenheit, bin ein Unixer, was Programmierung angeht...)
Heli: T-Rex 600 Pro Nitro/3G, 600 ESP/3G und 450 Pro/3G
Sender: Futaba FF-10 2,4GHz :D

thmarx

RCLine User

Wohnort: D-06108 Halle

  • Nachricht senden

77

Sonntag, 25. Juli 2004, 22:22

Habs probiert, macht er trotzdem nicht. ??? In dem Adapter den ich sonst benutze ist auch keiner drin.

Mit nem Testprogramm (ganz unten) kann ich Reset problemlos umschalten, Kabelfehler fällt also raus.
Thomas Marx

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »thmarx« (25. Juli 2004, 22:24)


moelski

RCLine User

Wohnort: Brilon / HSK

Beruf: IT Welt

  • Nachricht senden

78

Sonntag, 25. Juli 2004, 22:31

Moin !

Zitat

I2C ist eigentlich nicht viel aufwand

Das mag stimmen, wenn da nicht so ein böses OS zwischen Anwendung und Port wäre :D

Zitat

Was ist Delphi eigentlich? Pascal?

Jo. Delphi ist quasi Pascal für Windoof. Gibts auch als Kylix dann halt für Linux.

Und ihr wollt nicht doch lieber den seriellen Port weiternutzen :D ??? :D

btw:

Zitat

Neeee, bevor wir zu schweren Geschuetzen greifen, muessen wir noch die Trickkiste ausnutzen

Hmm, da halte ich jetzt mal gegen denn wenn ihr auf I2C geht, dann verlagert ihr den komplizierten Part auf mein Proggy 8( :D
Greetz Dominik

[SIZE=4]LogView - Datenvisualisierung für Modellbauer[/SIZE]
Besucht mal unsere Webseite oder schaut mal ins Forum.

thmarx

RCLine User

Wohnort: D-06108 Halle

  • Nachricht senden

79

Sonntag, 25. Juli 2004, 23:03

Zitat

Hmm, da halte ich jetzt mal gegen denn wenn ihr auf I2C geht, dann verlagert ihr den komplizierten Part auf mein Proggy


Da hast Du nicht ganz unrecht :evil: . Deshalb auch mein Vorschlag, die Daten erstmal seriell ohne irgendwelche Formatierung auszugeben. Dein Prog muss halt wissen welche Bytes zu welchen Werten gehören und entsprechend zusammensetzen und umrechnen. Später kann man dann I2C "nachrüsten" und erhält den gleichen Datensatz.

Thomas
Thomas Marx

Chris Benndorf

RCLine User

  • »Chris Benndorf« ist der Autor dieses Themas

Wohnort: 67317 Altleiningen &amp; 70567 Stuttgart

Beruf: Computerfredl

  • Nachricht senden

80

Sonntag, 25. Juli 2004, 23:07

Also, ich bin eigendlich auch eher fuer die I2C-Schnittstelle, da der Aufwand der Schaltung kaum hoeher ist und ich viele Uebertragungsfehler bei der Seriellen habe (mein Heli zuckt ganz gerne dabei und das gibt dann nette Sonderzeichen). Und es gibt vieeel freien Platz, wenn man die Ausgabe nicht im uC haben muss!

Deine Einwaende verstehe ich natuerlich auch, aber vielleicht kannst Du dann einfach den Kram aus einer Datei lesen, die von Ponyprog geschrieben wurde. Dann haetten wir erstmal einen Kompromiss...
Heli: T-Rex 600 Pro Nitro/3G, 600 ESP/3G und 450 Pro/3G
Sender: Futaba FF-10 2,4GHz :D