mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Projekt Schaufelraddampfer


Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich bastel zur Zeit an einem Holzmodell eines Schaufelraddampfers. Jede 
der beiden Schaufeln soll am Ende durch einen eigenen Motor betrieben 
werden und Schrittmotoren halte ich wegen den Dauerbelastung für nicht 
sonderlich gut dafür geeignet?!
Wenn ich normale Elektromotoren mit einem Getriebe davor nehme, will ich 
die beiden aber unbedingt synchronisieren.
Meine Idee wäre folgende:
Eingang 1: Servosignal für die Geschwindigkeit und Richtung der Sensoren
Eingang 2: Servosignal das angibt, ob die Motoren miteinander oder 
gegeneinander drehen sollen
Eingang 3 und 4: Inkrementalgeber an den Achsen zur Synchronisation

Das Ausgangssignal für zwei Fahrtenregler müsste also entsprechent 
berechnet werden.

Meine Frage:
Ist das direkt so mit einem Microcontroller möglich? Und wenn ja, 
welchen könnte mir dafür jemand empfehlen? Ich hab auch keine 
Vorstellung, was für eine Leistung man dafür bereitstellen müsste...
Wir das Signal dann mit einer Art Stop-Uhr ausgewertet oder gibt es 
Bausteine, die das Signal messen und schon den Wert an sich weitergeben?
Was das generieren vom Servosignal angeht, so habe ich schon einen 
Servotreiber gefunden der RS232 TTL schluckt.

Ich hatte bisher noch nichts mit Microcontrollern zu tun, dafür aber 
einige Programmiererfahrung in anderen Sprachen wie Java, VB, VB.Net, 
C++, Ada...

Danke schonmal für die Hilfe!

Manuel

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das ist möglich, µC's haben Hardware Interrupts, Timer und Input 
Capture Units, welche Encoder auswerten, die Signallängen von RC 
Signalen messen und auch wieder ausgeben können.

Würd' mich mal nach einem ATMega32 umschauen, wobei ich es für möglich 
halte, daß ein kleinerer Atmel Baustein auch reichen könnte, wie z.B. 
ein Tiny2313.

Du müsstest Dich zuallererst mit dem internen Aufbau dieser Bausteine 
vertraut machen, und dann eine passende Sprache raussuchen, entweder C 
oder Basic in Deinem Fall. Könnte je nach Deiner Lernkurve recht 
anspruchsvoll sein.

Geh' mal auf die Atmel Seite, lad' Dir ein Datenblatt für den Mega32 
runter und wirf' 'nen Blick rein, damit Du eine Vorstellung davon 
bekommst, was Dich erwartet :D

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eventuell kannst du auch brushless Motoren aus dem Modelbau verwenden, 
das sind ja Synchronmotoren  und du kann die Drehzahl einfach vorgeben. 
Dann braucht du überhaupt nicht messen.

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut, dass es eine Einarbeitezeit geben wird ist mir klar und dass es 
kein Spaziergang wird auch. Aber da ich erst in 1 bis 2 Jahren mit der 
Fertigstellung vom Modell rechne, habe ich ja Zeit! :-)

Hm, arbeiten die Bürstenlosen Motoren wirklich so genau?

Gibt es Empfehlungen für ein Einsteigerboard für die Atmega32? Hier im 
Shop habe ich das gefunden: 
http://shop.embedded-projects.net/product_info.php...

Reicht es um so etwas zu entwickeln?

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, wenn das Zeit hat, dann kann das klappen. Da Du ein dynamisches 
System mit mehreren Timern erzeugen willst (musst), könnte übrigens die 
Anschaffung eines Oszilloskopes oder Logiganalyzers Sinn machen, wenn 
nicht schon vorhanden.

Zu dem Teil auf dem Link brauchst Du noch einen ISP Programmer, denn der 
ist da nicht drauf. Vorteil den ich sehe, auf der freien Fläche könnte 
noch Zusatzschaltung untergebracht werde.

Ansonsten schau' Dich nach STK500 von Atmel um, ist ein Standard 
Development Board, hat gleich einen ISP Programmer drauf, den man später 
auch für andere Boards, oder eben auch für das Verlinkte, nehmen kann. 
Braucht aber eine serielle Schnittstelle, oder einen USB/Ser Adapter, 
falls Betrieb am Notbook ohne serielle Schnittstelle erforderlich ist.

Das Problem bei denn bürstenlosen Motoren sehe ich darin, daß RC Regler 
zwar intern mit absoluten Werten arbeitet, aber dennoch per 
Pulsweitensignal des RC Empfängers angesprochen werden, und da könnte 
die Interpretation welche Drehzahl welcher Pulslänge entspricht, doch 
auseinandergehen.

Schau Dir mal das hier an: 
http://www.mikrocontroller.com/de/KopterBL.php
Das ist ein Regler für bürstenloser Motoren, der per I2C gesteuert 
werden kann. I2C ist ein seriellles Protokoll, heist nur bei Atmel TWI, 
wird vom Mega32 unterstützt, und es gibt auch Soft I2C. Mit solchen 
Reglern könnt' ich mir vorstellen, daß ein Gleichlauf möglich wird.

Es spricht im Prinzip wegen Dauerbelastung nichts gegen 
Schrittmmotorenn, wie kommst Du darauf ? Wenn die gut gekühlt werden, 
dann laufen die ewig, könnt' nur sein, daß der Wirkungsgrad 
unbefriedigend ist.

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super, vielen Dank schon mal für die ganzen Ratschläge.

Naja, ich hab ne kleine CNC Fräse und da werden die Schrittmotoren, vor 
allem die Z-Achse (relativ kleiner Motor) sehr warm.
Außerdem dachte ich immer, dass Schrittmotoren eben für ein genaues 
Verfahren ausgelegt sind und nicht um quasi als normaler Elektromotor 
genutzt zu werden.
Hatte ich mir selber zusammen gereimt. :-)
Aber wenn das kein Problem ist, könnte ich mir auch die Regler und 
Inkrementalgeber sparen und als Ausgang eben Schrittmotortreiber (nennt 
sich das so?) verwenden.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie gesagt, die Schrittmotoren haben nur einen nicht sooo günstigen 
Wirkungsgrad, ist ja für die Standardanwendung meist egal. Evtl. 
begrenzt das aber die Betriebszeit Deines Bootes. Auch die 
Maximaldrehzahl ist nicht hoch, das lässt sich aber durch die 
Getriebewahl ausgleichen.

Bei der CNC muss ggf. auch der Haltestrom höher sein, was zu 
zusätzlicher Erwärmung führt. Den Betriebsstrom kannst Du dann per 
Choppereinstellung entsprechend der benötigten Antriebskraft wählen. Auf 
eines solltest Du auch achten, Stepper baruchen oft mal mehr als 12V 
Betriebsspannung um entsprechend Kraft zu entwickeln.

Ansonsten sind Stepper äußerst dauerhaft, haben Kugellager, und da nur 
Spulen auf dem Stator sind, auch keine Stromabnehmer / Bürsten, die 
abnutzen können. Da kommst Du bis auf den Amazonas mit Deinem Boot :D

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, das Boot wird ca. 1 Meter lang und ist komplett aus Holz. Ich sehe 
also kein Problem darin, 2 Bleiakkus reinzusetzen, die für ausreichend 
Strom sorgen. Und nach ner Stunde wird man auch spätestens die Schnauze 
voll haben...

Demnach wären Stepper wohl die einfachste Lösung.
Gibt es schon fertige Bauteile, die Stepper durch PWM Signale steuern 
oder ist das jetzt mein neues Projekt? :-)

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Naja, das Boot wird ca. 1 Meter lang und ist komplett aus Holz. Ich sehe
> also kein Problem darin, 2 Bleiakkus reinzusetzen, die für ausreichend
> Strom sorgen. Und nach ner Stunde wird man auch spätestens die Schnauze
> voll haben...

Cooles Projekt :)
Auf Bleiakkus würde ich allerdings verzichten, für ein Modell (Auch wenn 
es ein Boot ist), haben die ein viel zu hohes Leistungsgewicht. Es 
müssen ja nicht gleich LiPo-Zellen sein, aber wenigstens zu NiMH würde 
ich da schon greifen.

> Demnach wären Stepper wohl die einfachste Lösung.
> Gibt es schon fertige Bauteile, die Stepper durch PWM Signale steuern
> oder ist das jetzt mein neues Projekt? :-)

Ich weiss nicht, ob du mit Steppern wirklich glücklich werden wirst. Mit 
einer synchronen Drehzahl der Schaufelräder fährt das Schiff ja noch 
nicht zwingend geradeaus (Geometrie der Schaufelräder muss genau 
übereinstimmen, evtl. Schräglage, Strömungen, ...). An deiner Stelle 
würde ich einfache Gleichstrommotoren mit H-Brücken-Steuerung verwenden 
und die Richtung mit einem Kompass-IC nachregeln. Oder gleich GPS wenn 
es ganz feudal sein darf ;)

Zu den Schrittmotoren findest hier noch was: Schrittmotoren

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also bisher sieht es eher so aus, als ob ich Aufbalastieren müsste, 
damit ein einigermaßen originalgetreues Fahrbild entsteht. Dann kann ich 
auch Bleiakkus nehmen. Wenn ich mit meiner Rechnung daneben liege, werde 
ich auf andere Wechseln. Gleich wie, ich denke der Wirkungsgrad würde 
kein Problem sein.

Wenn man es ambitioniert sieht ist der Gedanke hinter der ganzen 
Fräserei schon, dass bei synchroner Drehzahl auch zumindest fast der 
Geradeauslauf erreicht wird. Klar, gegen Strömung und Co kann man dann 
immer noch nichts machen.
Vielleicht wäre das mit dem Kompass ne ganz nette Erweiterung, die sich 
ja auch rein an das Ruder koppeln lassen würde.

GPS kommt dann erst für die Fahrt zum Amazonas rein... ;-)

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Gibt es schon fertige Bauteile, die Stepper durch PWM Signale steuern
> oder ist das jetzt mein neues Projekt? :-)

Das könnte Dein neues Projekt werden :D

Du kannst auf normale Steppertreiber, evtl. mit Microstep ausweichen. Da 
musst Du dann nur Takt und Richtung reingeben, hast aber den Nachteil 
des Geräusches, das Du von der CNC her kennst.

Es ist prinzipiell möglich Schrittmotore mit 2 versetzten gechoppten 
Sinusschwingungen anzusteuern, da hörst Du dann gar nix mehr steppen, 
das läuft rund wie ein normaler Elektromotor.

Kannst dafür Tiny25/45 nehmen, die haben "2 High Frequency PWM Outputs", 
die mit einem Takt bis zu 64MHz laufen. So etwas hat der Mega32 nicht, 
den kannst Du aber falls notwendig als Zentralrechner nehmen.

Für diese Lösung müsstest Du wahrscheinlich die Treiberstufen für die 
Mosfets selbst entwickeln/aufbauen, weis nicht wie fit Du da bist.

Autor: Der wohl ahnungslose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Stepper gewählt werden, nimm Welche mit möglichst kleiner Spannung 
bei möglichst großem Drehmoment.
Durch den Chopper wird der Spulenstrom ja eh begrenzt und die Spannung 
'regelt' sich schon passend ein.
Je höher die Differenz zwischen Versorgungsspannung und Motorspannung 
ist, desto schneller kannst Du den Stepper ohne Schrittverluste fahren 
lassen.
Allerdings denke ich, daß man bei einem Schaufelraddampfer es nicht 
wirklich auf Drehzahl ankommt - nen starker 12V Stepper (bei 12V 
Versorgung) sollte sich auch gut machen.
Ach ja, früher, so zur Zeit der Dampfschiffe, hat der Käpt'n auch 
entsprechend am Rad gekurbelt, damit die Kiste auch geradeaus läuft ;)

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut, da kommt dann das Problem: bisher hatte ich mit Elektronik 
eigentlich nichts zu tun. Ne Treiberstufe selbst zu entwickeln würde ich 
also mal schön hinten anstellen.

Meine CNC Fräse ist glücklicher Weise relativ leise im Verfahren. Die 
Schrittmotoren daran hören sich für mich schon fast an wie 
elektromotoren, außer wenn man sie langsam fahren lässt.

Aber da es eh ein längeres Projekt wird, werde ich mich wohl mal 
durchtesten.
Bin noch nicht so sicher, ob ich Schrittmotoren (was ich momentan für 
einfach halte) oder normale Gleichstrommotoren nehmen soll.

Ich geh auch davon aus, dass ein Schrittmotor selbst im Direktantrieb 
genug Kraft entwickeln kann, um den Dampfer fahren zu lassen. Und 
sonderlich schnell darf sich die kleine Schaufel auch nicht drehen, weil 
sonst nur die Strömung abreißt.

Eines noch:
Das STK500 sieht ja recht... breit gefächert aus. Kann ich damit dann 
auch die Tinys beschreiben bzw. nennt sich ja brennen, oder?
Gibt's eigentlich ein online Shop bei dem die Masse vom Forum hier 
einkauft?

Vielen Dank nochmal an alle Ratschläge!
Werde mich hier bei Gelegenheit wieder verewigen, wenn ich ein wenig 
weiter bin. :-)

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wollte nur zur Sicherheit darauf hinweisen, denn die Fräse wird 
einigermaßen massiv aus Metall sein und so ein Boot könnte wie ein 
Klangkörper wirken, da hast Du keinen Spass, wenn so eine Kreissäge 
durchs Wasser rauscht. Beim Direktantrieb könnte man auf den 
Raddurchmesser gesehen evtl. ein Ruckeln bemerken, wenn's nicht 
Microstep ist. Aber viel Spass beim ausprobieren.

Ja, man kann damit auch Tinys beschreiben, neben einem ISP Programmer 
ist da eine einstellbare Versorgungsspannung und ein einstellbarer 
Oszillator drauf. Wenn man mal die Fuses versehentlich auf externen Takt 
gestellt hat, jedoch kein Quarz dran ist, und man somit einen nicht mehr 
ansprechbaren µC hat, weis man das zu schätzen. Geh mal auf atmel.com 
gib STK500 in die Suche ein, erster Link verweist auf Pdf's zum STK500. 
Schau' Dir die mal an.

Wo hier das Forum einkauft, kann ich Dir leider nicht sagen. Den 
embedded shop hast Du ja bereits gefunden, da gibt's aber keinen STK500, 
nur den 600, der ist teurer.

Auf E... STK500 eingeben fördert im Moment nur einen zutage, da waren 
immer mehr Angebote drin, ansonsten google benutzen.

Nur zu... ;-)

Autor: Tim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

habe auch einen Schaufelraddampfer  -  allerdings die beiden "Paddel" 
mit einer Welle verbunden  -  die ggf. minimalen Unterschiede werden 
durch das Seitenruder ausgeglichen  -  klar wenden auf der Stelle etc. 
geht natürlich nicht ;))

Gruß Tim

Autor: ms (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Geht wohl aus Prinzip nicht :)

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde auch noch raten das Prinzip der zweirädrigen Roboter 
anzuschauen, denn dort wird absolut Ähnliches gemacht. Die sind sogar 
noch instabiler als ein Schiff was den Geradeauslauf betrifft.

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich bin grad auf Atmel's Hochschul Programm gestoßen, wo Studenten 
(da fall ich ja ein Glück darunter) die Atmel Produkte bis zu 50% 
billiger bekommen. Demnach ist ein STK600 direkt erschwinglich.

Ob nun für den Dampfer oder ein anderes Ding, ich hab Lust bekommen mich 
damit zu beschäftigen. Verstehe ich das richtig, dass ich zusätzlich zum 
STK600 auch das Zusatzmodel STK600-DIP brauche, damit ich ATMega32 und 
die Tiny25 oder 45 verwenden kann?
Und versteh ich das auch richtig, dass man zusammen mit AVR Studio das 
Board recht leicht integrieren und wenn man fertig ist direkt von dort 
den Quellcode auf den Prozessor brennen kann?

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau' dir doch mal das Getriebe von den etwas teureren Panzermodellen 
an.
Dort ist ein starker Motor für den Vortrieb und ein schwächerer um das 
Differenzial dosiert zu Sperren. Damit wird ein Sauberer Gleichlauf bei 
maximaler Antriebsleistung erzielt.
Mit dem Differenzial (unterschiedliche Drehzahlen links und rechts) wird 
der Panzer gelenkt, wie im Original.

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Manuael,

das STK600 ist für die größeren AVR's geeignet, das 500er reicht für 
viele der kleinen AVR's aus. Du brauchst beim 600 den STK600-DIP 
Adapter, das würd' mich stören, außerdem finde ich das Adapterboard für 
den eigentlichen Einbau zu groß. Such' mal hier: www.elecont.de nach 
Carrierboards, hab' selbst ein paar davon gekauft, fand ich preiswert 
und gut.

Diese Boards kannst Du dann sowohl mit dem 500, als auch mit dem 600 
programmieren, natürlich auch mit jedem anderen vernünftigen ISP 
Programmer. Persönlich bevorzuge ich mittlerweile ein 
Breadboard/Steckbrett zum Aufbau und testen, hab' aber nie bereut einen 
STK500 gekauft zu haben.

Das AVR Studio arbeitet mit verschiedenen Programmern zusammen, siehe 
Screenshot, deswegen wirst Du auch bei den Nachbauten auch immer wieder 
den Hinweis: "STK500-kompatibel" finden, wenn er kompatibel ist, 
akzeptiert ihn das AVR Studio.

Im AVR Studio selbst kannst Du in Assembler programmieren. Um in C zu 
schreiben, benötigst Du einen C-Compiler, z.B. den AVR GCC, ein freier 
Compiler. Damit erzeugst Du das letzendes benötigte compilierte 
Hex-File, daß Du dann mit dem AVR Studio in den µC brennen kannst. AVR 
Studio eignet sich aber auch um das C-Programm zu simulieren und zu 
debuggen.

Ich persönlich mag Bascom, einen Basic Compiler, der auch das benötigte 
Hex-File erzeugt. Programmieren des Chips ist dort aus der Anwendung 
raus möglich falls ein unterstützter Programmer existiert. Ich 
persönlich schätze in Bascom das einfache Mischen von Basic und 
Assemblercode.

Du wirst hier im Forum einige Mitglieder finden, die sich abschätzig 
über Bascom äußern. Nimm die Sprache, in der Du lieber programmierst.

Sobald Du einen AVR Studio kompatiblen Programmer hast, kannst Du über 
ISP auch obige Carrierboards beschreiben. Es reichen im Prinzip ein paar 
Stückchen Draht, einen Programmer und ein AVR-IC und los geht's :-)

Wobei ich mir am Anfang eine gut funktionierende Basis wie den STK500 
oder 600 zulegen würde.

Autor: eaehavelich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Manuel

ich habe die Lorelei von Hegi, sehr einfach gehalten mit festen 
Schaufeln.
Die Lorelei (ca. 80 cm lang) fährt mit zwei normalen Getriebemotoren 
Mabuchi 280, einzeln steuerbar (die Technik ist 20 Jahre alt). Um den 
Geradeauslauf mit der Schaufelgeschwindigkeit zu ändern muß schon 
einiges passieren - die Seitenwindeinflüsse sind größer.
Zur Steuerung aus heutiger Sicht würde ich einen AVR nehmen (ATmega8), 
zur Programmierung BASCOM. Externe Fahrtregler sind nicht nötig, da der 
Prozessor alles regeln kann: Relais für die Umpolung und PWM-Ansteuerung 
für die Motordrehzahl ist mit wenigen Bauteilen realisierbar. Licht und 
Nebelhorn erfordern je nur einen Schalttransistor. Infos zum Einlesen 
der PPM-Daten findest Du unter roboternetz.de > wissen > quellcode 
bascom.
Thema Akku: Ich nehme nur noch 7,2V Racing Packs mit Tamiya Steckern, 
habe alle Schiffe und Autos darauf umgerüstet, jetzt benötige ich nicht 
mehr für jedes Modell einen eigenen Akku und ein eigenes Ladegerät. Du 
wirst nicht mehr als 6V bei 2A brauchen, nimm einen Akku den Du auch für 
andere Modelle brauchst, er hält länger wenn er öfter als zweimal im 
Jahr geladen wird.

Gruß Andreas

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, ich war auch nicht davon ausgegangen, dass der Dampfer wilde 
Kreise fährt und dass man das durch zwei Regler und zwei Motoren mit 
entsprechender Programmierung des Senders schon sehr synchron laufen 
lassen kann, ist mir auch klar.
Ich möchte es eben ein bisschen perfekter machen... nicht aus 
Notwendigkeit, sondern aus Interesse.

Ok, ich glaub es wird Zeit, dass ich mich etwas einlese in die ganze 
Materie. Ich war bisher davon ausgegangen, dass z.B. ein ATmega32 schon 
einen Taktgeber etc. hat und nach der Programmierung eigentlich um zu 
Laufen nur mit Strom versorgt werden muss.
Ich konnte sogar am Lehrstuhl ein STK600 ausgraben und werde mir mal so 
ein Carrier Board zulegen, um bisschen rumprobieren zu können.

Eines noch: ich hab ein Carrier Board mit einem ATmega32-16AU gefunden.
Kann ich davon ausgehen, dass alle ATmega32 gleich sind und -16AU nur 
die Bauform bestimmt, folglich also was für ein ATMega32 programmiert 
wurde auch auf dem -16AU läuft? Oder steckt da doch mehr dahinter?

Danke nochmal für die ganzen Ratschläge!

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

bezüglich "-16AU". Das "AU" steht für die Bauform, die "16" für die 
maximale Taktfrequenz. Bestimmte Bauformen haben unter Umständen weniger 
Anschlüsse als andere und damit nicht alle Pins extern verfügbar. 
Ansonsten sind alle ATmega32 gleich.

Kannst Dir  ja mal den folgenden Link an anschauen:
http://www.heise.de/ct/c-t-Bot-und-c-t-Sim--/projekte/133987
Ist zwar ein Roboter, aber die Ansteuerung der Motoren dürfte Deinen 
Bedürfnissen doch recht nahe kommen. Die benutzen übrigens 6V Faulhaber 
Motore (2619-006SR) mit 33:1 Untersetzungsgetriebe und einen ATmega32 
zur Steuerung.

CU

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Manuel:

> Ich war bisher davon ausgegangen, dass z.B. ein ATmega32 schon
> einen Taktgeber etc.

Da bist Du auch richtig davon ausgegangen, das hat er, einen internen RC 
Oszillator, nicht sehr genau, aber immerhin er läuft frisch aus der 
Packung.

Das Problem, daß sich dem Einen oder Anderen schon mal gestellt hat, ist 
wenn aus Versehen die Fuse per Programmer auf externen Quarz verstellt 
wurde, aber kein externer Quarz angeschlossen ist, und auch keiner 
gerade in der Schublade liegt.

In diesem Fall lässt sich der AVR, da er keinen Takt mehr hat, auch 
nicht mehr per ISP programmieren. Da ist man dann froh ein STK500 zu 
haben, das den Takt liefern kann.

Gibt noch mehr so Fallstricke, es gibt ein paar AVR's, wo man den 
Resetpins wegprogrammieren kann, dann ist er für ISP nicht mehr 
ansprechbar. Manche AVR's haben einen internen Oszillator mit 128kHz, 
den eingestellt und Clockdiv 8 eingeschaltet, dann läuft der AVR mit nur 
18kHz. Ein Problem für manche Programmer den noch irgendwie 
anzusprechen.

Aber in's STK500 rein, auf High Voltage Programming gestellt und schon 
ist der Tag gerettet. ;-)

Wenn er ATMega32 heißt, ist der innere Aufbau, damit auch die 
Programmierung gleich.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf der Intermodell 1993 (oder so) war ein UBoot-Bauer, der seine Uboote 
mit einem Optomagnet-Kompass ausgerüstet hat. Das sa so aus, dass er mit 
einer Kompassnadel eine (Gabel-)Lichtschranke abgedeckt hat. Die 
Lichtschranke konnte er noch mechanisch verfahren, so dass er einen 
bestimmten Kurs vorgeben konnte. Ein Regelkreis hat dafür gesorgt, dass 
die Lichtschranke (eigentlich waren es zwei, um auch noch die 
Drehrichtung festzustellen) immer von der Kompassnadel abgedeckt wurde, 
indem er das Seitenruder entsprechend ansteuerte.
Um für einen Geradeauslauf zu sorgen, dürfte aber ein Kreiselsystem, wie 
man es bei den Modellfliegern benutzt, reichen.

Eine der Schaufelradsteuerung ähnliche Anwendung habe ich auch vor: Ein 
Ruderboot...

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, langsam kommt Licht ins Dunkle!
Dann kann ich entweder ein STK500 und ganz normale ATmega32 verwenden. 
Die kann man ja wie ich gelesen hab auch auf dem Board testen mit paar 
LED's und Tastern oder eben dann auf dem Steckbrett.

Oder ich kann ein STK600 nehmen, brauche dann aber entweder das 
STK600-DIP oder ein Carrier Board dazu wie das hier 
(http://www.elecont.de/shop/product_info.php?info=p...).
Oder ist es grundsätzlich einfacher / sinnvoller, auch mit dem STK500 
ein Carrier Board zu verwenden?

Und zu den verschiedenen Programmierarten:
Da ich mit C++ schon Erfahrung habe, werde ich mich zumindest zum 
Einstieg wohl an C halten.

@MWS
Du hast oben geschrieben, dass du BASCOM bevorzugst, weil man Basic und 
Assemlber Code einfach mischen kann.
Macht es das in vielen Bereichen für dich "nur" einfacher, oder sind 
alleine mit C sonst Funktionen nicht erreichbar?


Ich hab mir mal WinAVR und das AVR Studio runtergladen und installiert - 
damit ist ja das Programmieren der Atmels in C möglich.
Wenn ich mich auch an Bascom versuchen will, muss ich den Compiler 
kaufen? Den scheint es nicht kostenlos zu geben? Und nach dem 
installieren taucht er dann auch im AVR Studio als Auswahl für neue 
Projekte auf?

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eigentlich muss da eine dampfmaschine rein

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Du hast oben geschrieben, dass du BASCOM bevorzugst, weil man Basic und
>Assemlber Code einfach mischen kann.

Lass Bascom Bascom sein, und bleib bei C. Es gibt wirklich nichts, was 
damit nicht geht, auch Assembler mischen geht ganz einfach, falls man es 
denn wirklich mal braucht (was ich arg bezweifele). Extra dafür mit 
Basic anzufangen, ist -piep-.

Und nimm als Einstieg lieber gleich einen ATMega644. Ist pimkompatibel 
zum Mega32, hat aber doppelt so viel Speicher. Da brauchst du dir 
zunächst mal keine Sorgen zu machen. Vermutlich wird später für deine 
Anwendung ein Mega8(8) völlig ausreichen, der Umstieg ist dann aber 
einfach. Die Dinger sind bis auf Speicherbestückung und Pinanzahl alle 
ziemlich identisch.

Oliver

Autor: MWS (Gast)
Datum:
Angehängte Dateien:
  • preview image for SC.jpg
    SC.jpg
    25,8 KB, 307 Downloads

Bewertung
0 lesenswert
nicht lesenswert
Manuel,

> Du hast oben geschrieben, dass du BASCOM bevorzugst, weil man Basic
> und Assemlber Code einfach mischen kann.
> Macht es das in vielen Bereichen für dich "nur" einfacher, oder
> sind alleine mit C sonst Funktionen nicht erreichbar?

Du kannst alles mit C machen. Es ist meine persönliche Vorliebe, Basic 
da zu verwenden, wo's zeitlich unkritisch ist und Assembler da wo's 
speicher/code-effizient und zeitkritisch ist. Bei ersterem reicht mir 
die Leistung die Bascom bringt locker aus, bei letzerem kann ich das so 
schnell/effizient schreiben, wie ich will und muss mich nicht dem C 
Compiler ausliefern.

Hab' mir mal Eclipse und den AVR GCC installiert, das ist keine 
schlechte Programmierumgebung, aber um anzufangen brauchst Du erstens 
Durchsetzungs- und auch Leidensbereitschaft, zweitens ist meiner Meinung 
nach im GCC die Anwendung von Inline Assembler nur noch ein Albtraum, 
ein "Pain in the Ass", wie die englischsprachige Community dazu sagen 
würde.

Ich komm mit Bascom gut klar, dränge aber niemand meine Meinung auf, das 
wirst Du von der C Community nicht unbedingt behaupten können, die 
empfinden alles Andere als C als Quatsch.

Ohne hier einen Flamewar anzetteln zu wollen, C'ler haben eine deutlich 
geringere Toleranz gegenüber anderen Sprachen, als Basic Verwender. 
Wirst Du hier im Forum sehen. Z.B. Oliver's -piep-, was immer das jetzt 
sein soll...

Für Dich kann jedoch auch interessant sein, woher Du im Zweifelsfall 
Hilfe bekommst, hier im Forum wirst Du gute Hilfe zu C bekommen, auch 
ein Paar Bascom Programmierer sind hier unterwegs, so wie ich :D

Im Bascom Forum wirst Du gute Hilfe zu Bascom finden, eher weniger zu C. 
Deswegen such' Dir einfach aus, was Du magst.

GCC ist umsonst, Bascom kostet was in der Codegröße unbegrenzten 
Version, die kostenlose Demo geht, glaube ich, 4K Code, das reicht aus 
für die Tinys.

Daneben gibt's auch noch Micro Pascal und andere C Compiler, bei denen 
Du wiederum den AVR GCC in die Tonne klopfen würdest. Die kosten aber 
durchaus richtig Geld. Aber soviel zu dem.

Der STK600 ist sozusagen die modernere Form des STK500, vorzugsweise für 
die fortgeschritteneren/neueren AVR's gedacht, aber auch für Mega32 oder 
Tiny verwendbar. Das Carrier Board für den 500er sollte gerade eben 
erlauben, die moderneren AVR's verwenden zu können.

Nimm ein Steckbrett, und wurstel einen Tiny2313 drauf, dann sieht's so 
aus wie auf dem Bild und funktioniert auch. Aber mach' sowas, wenn Du 
fit bist, nimm für den Anfang etwas sicher Funktionierendes. Das macht 
mehr Spass und gibt weniger Frust :-)

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Amen.



... C'ler sind nicht intollerant, aber die basic-jünger werden alle in 
der hölle schmoren duckundwech ....

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... C'ler sind nicht intollerant, aber die basic-jünger werden alle in
> der hölle schmoren duckundwech ....

He, he :D

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS wrote:
> Ich komm mit Bascom gut klar, dränge aber niemand meine Meinung auf, das
> wirst Du von der C Community nicht unbedingt behaupten können, die
> empfinden alles Andere als C als Quatsch.

Das würd ich so nicht sagen.
Es ist nur so:
Wenn hier im Forum BASCOM Leute nach Hilfe fragen, dann sind die 
meistens so dermassen Blank was die Innereien ihres µC und wie man damit 
arbeitet betrifft, dass es schon nicht mehr schön ist.

Scheint so, als ob die hohe Hardware-Abstaktion, die BASCOM mitbringt, 
die Leute faul macht, sich mit der Maschinerie darunter zu beschäftigen.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Z.B. Oliver's -piep-, was immer das jetzt
>sein soll...

Es gibt überhaupt keinen Grund, für jemanden, der C und C++ kann, Basic 
zu lernen, nur weil er AVR's programmieren möchte. Und einem 
Programmieranfänger würde ich es auch nicht empfehlen.

"...ist meiner Meinung
nach im GCC die Anwendung von Inline Assembler nur noch ein Albtraum,
ein "Pain in the Ass", wie die englischsprachige Community dazu sagen
würde."

Stimmt. Das ist eine krampfartige Krücke, und mehr soll es auch gar 
nicht sein.
Sollte es tatsächlich mal erforderlich sein, etwas in Assembler zu 
schreiben, kommt das in eine eigene Datei, in reinem Assemblercode. Mit 
sauberer Struktur und definierter Schnittstelle.

Oliver

Autor: Juppi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Scheint so, als ob die hohe Hardware-Abstaktion, die BASCOM mitbringt,
> die Leute faul macht, sich mit der Maschinerie darunter zu beschäftigen.

So wie die Leute, die C++ mit dem ganzen stdlib-HighLevel-Schnickschnack 
lernen.

Ach, ist das nicht der Weg, den du immer empfiehlst? Aber Basic als 
High-Level-Sprache ist ploetzlich schlecht fuer den Einstieg?

Autor: Michael Waiblinger (wiebel42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde dir empfehlen mal alle Infos die du im Netz über den Asuro 
findest zusammenzutragen. Der hat nämlich auch zwei Motoren (incl. 
Treiber) und zwei Drehencoder (über Reflexlichtschranken) dazu sind dann 
auch alle Quellen (C, Asm, ...) offen und es gibt eine fertige AsuroLib 
(auf Sourceforge in C) worin solche Sachen wie Geradeauslauf schön 
einfach gelöst sind, hat aber auch noch Verbesserungspotential. Die 
Schaltung kannst du dann fast 1:1 übernehmen oder dir für die Motoren 
was anderes einfallen lassen, ganz wie du magst. Wenn Du dir den Atmega8 
aus dem Asuro direkt besorgst kannst du auch auf den Programmer 
verzichten, da dieser einen seriellen Bootloader hat.
Ich halte das für einen sehr schönen Einstieg, sowohl in die Elektronik 
als auch in die µC Programmierung, ob mit oder ohne die Hardware, da 
gibt es Dokus satt und man kann beliebig viel lernen dabei. Und in 
deinem Fall kannst du schon fast eine fertige Lösung rausziehen und über 
die Dekodierung eines Servo/Empfängersignals findet man an anderen 
Stellen auch schon sehr viel Infos.

Ich finde deinen Idee das so exakt und elegant wie möglich machen zu 
wollen super, da es ein überschaubares System ist an dem man dennoch 
sehr viel herumprobieren kann. Meine persönlichen Top 5 mit fallendem 
Anspruch (Eleganz) wären wie folgt:
1. BLDC ohne Sensoren (Back-EMF, eigener Treiber oder evtl. der vom 
Mikrokopter)
2. BLDC mit Hall Sensoren (wie bei Festplatten oder CD roms zu finden, 
vereinfacht natürlich die Regelung)
3. DC-Motoren + Encoder (s. Asuro, dürfte die einfachste Lösung sein mit 
einer echten Regelung)
4. Schrittmotoren (funktioniert sicher toll fände ich aber fast ein 
bisschen Langweilig weil es keine Regelung ist. Wenn du aber natürlich 
selbst an der mikrostep Ansteuerung schraubst entfällt jede Art von 
Langeweile, mit zusätzlichen Encodern zur Erkennung von Schrittverlusten 
wird dann sogar wieder richtiger Spass draus.)
5. Jede Lösung die fertige Fahrtenregler verwendet. (das ist jetzt 
natürlich schon sehr subjektiv)

Die Liste müsste so eigentlich auch fast die Effizienz der Antriebe 
wiedergeben. Ach ja wenn du die BLDCs dann auch noch mit einer 
Sinusoidal modulierten PWM ansteuerst wäre das natürlich doppelplus Gut 
aber dann ist dein erstes Jahr vermutlich auch schon fast vorbei.

Außer Konkurrenz: Das geregelte Sperrdifferenzial von dem Panzer, ist 
elektrisch natürlich stumpf, entbehrt aber nicht eines gewissen Reizes, 
zusammen mit Encodern kann das aber natürlich auch ein heiterer 
Regelspass werden. ;) -wiebel

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwie ist das alles oversized. Wenn das Schiff nicht sowieso schon 
ungeregelt geradeaus fährt, reicht doch ein Sensor mit sehr wenigen 
Impulsen pro Umdrehung, um die Drehzahlen ausreichend genau aneinander 
anzugleichen. Das ist ja alles nicht hochdynamisch.

Ich sehe da auch eher die Schwierigkeit, dem Dampfer so genau zu bauen, 
daß der nicht von sich aus eine leichte Kurve fährt.

Oliver

Autor: Michael Waiblinger (wiebel42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab Manuel jetzt auch eher so verstanden, das er Spaß an der Materie 
entwickelt und richtig loslegen will. -wiebel

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Karl Heinz:

meiner Meinung nach muss ein C-Programmierer durch den prinzipiell 
schwierigeren Einstieg in die Sprache bereits ein höheres Grundwissen 
mitbringen.

Keine Ahnung vom Innenleben eines AVR's zu haben ist dagegen nicht nur 
Privileg von Bascom Programmierern, das seh' ich bei C Anwendern auch 
zur Genüge.

Das Kapseln der Register und Prozessoreinheiten ist dagegen etwas, daß 
bei Bascom den Einstieg erleichtert, möglicherweise etwas das Neulinge 
anzieht, und dann gibt's halt auch viele Neulingsfragen.

@Oliver:

Es ist halt höchst angenehm zu schreiben:
Dim a as Byte
  a = &h05
$asm
  LDS R26, {a}
  LDI R27, &h10
  ADD R26, R27
  STS {a}, R26
$end asm
  a = a / 2
...

Das Ganze ohne mir jetzt den Inline Murks des GCC anzutun, und ohne eine 
externe Datei dafür schreiben zu müssen. Aber wie gesagt, meine 
persönliche Vorliebe ist es Bascom/ASM zu mischen, wer das nicht so 
macht, für den sind möglicherweise andere Aspekte wichtiger. Ich lass' 
z.B. auch Bascom's Config Kram weg, denn genauso problemlos ist es 
möglich die Prozessorregister dort direkt zu adressieren.
Und das ist das eigentlich Schöne: Ich hab' die Wahl.
Die hab' ich mit den Inline Verrenkungen des GCC nicht wirklich.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Juppi wrote:

> Ach, ist das nicht der Weg, den du immer empfiehlst? Aber Basic als
> High-Level-Sprache ist ploetzlich schlecht fuer den Einstieg?

LOL. Da hast du nicht so unrecht.

Ich bin allerdings trotzdem der Meinung, dass jeder Programmierer seine 
Basissachen wie lineare Listen, dynamische Arrays u.dlg können muss. Im 
täglichen Programmieralltag kann er dann ja std::list, std::vector u 
dlg. benutzen. Von einem Werkzeugmacher erwarte ich ja auch, dass er 
nach wie vor mit Säge und Feile umgehen kann, auch wenn er in der 
tatsächlichen Produktion auf CNC Drehmaschinen und Fräsbänken arbeitet.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MWS wrote:

> Keine Ahnung vom Innenleben eines AVR's zu haben ist dagegen nicht nur
> Privileg von Bascom Programmierern, das seh' ich bei C Anwendern auch
> zur Genüge.
>
> Das Kapseln der Register und Prozessoreinheiten ist dagegen etwas, daß
> bei Bascom den Einstieg erleichtert, möglicherweise etwas das Neulinge
> anzieht, und dann gibt's halt auch viele Neulingsfragen.

Das ist fraglos auch eine gute Sache.
Nicht falsch verstehen: Ich hab nichts gegen BASCOM. Hab auch selber 
schon überlegt, da mal ein paar Dinge damit zu realisieren, eben weil 
ich mir dann nicht mehr aus den Datenblättern die Einzelheiten 
zusammensuchen muss. Auf der anderen Seite ging das dann immer schnell 
und war eigentlich nie das grosse Problem in einem Projekt.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Es ist halt höchst angenehm zu schreiben:
>...
Das mag ja angenehm sein, es ist aber auch höchst sinnlos. Nicht nur 
dein vereinfachtes Beispiel, sondern in den allermeisten Fällen 
generell.

Wenn dein Code Größen- oder Geschwindigkeitsmäßig von ein paar wenigen 
Inline-Assembler-Befehlen abhängt, hast du ein ernsthaftes 
Design-Problem in deiner Software. Das mag erforderlich sein, wenn man 
aus Platz- und/oder Kostengründen den allerkleinsten Tiny in riesen 
Stückzahlen einsetzten muß, aber dann nimmt man erst recht kein Bascom.

>a = a / 2
Da darf es dann wieder der Compiler übernehmen. Schade, eine lesbare, 
schnelle und fehlersichere Divisionsroutine in inline-Assembler hätte 
ich jetzt hier doch gerne gesehen.

Abgesehen davon, gcc, und vermutlich alle anderen ernsthaften 
C-Compiler, würde die Zeile in ein einfaches Rechts-Shift optimieren. 
Kürzer und schneller geht es nicht. Ganz ohne Assembler. Keine Ahnung, 
was Bascom daraus macht.

>Und das ist das eigentlich Schöne: Ich hab' die Wahl.

Nein. Anscheinend bist du gezwungen, so etwas zu nutzen. Normalerweise 
braucht man so etwas eben so gut wie nie.

Oliver

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> Das ist fraglos auch eine gute Sache.
> Nicht falsch verstehen: Ich hab nichts gegen BASCOM. Hab auch selber
> schon überlegt, da mal ein paar Dinge damit zu realisieren, eben weil
> ich mir dann nicht mehr aus den Datenblättern die Einzelheiten
> zusammensuchen muss. Auf der anderen Seite ging das dann immer schnell
> und war eigentlich nie das grosse Problem in einem Projekt.

Nachtrag:
Was mich am BASCOM eigentlich immer abgeschreckt hat ist, dass man 
arithmetische Ausdrücke so zerstückeln muss. Für mich eigentlich 
unverständlich, warum man da keinen vernünftigen Expressionparser 
reinmachen kann. Aber der/die Autoren werden schon ihre Gründe dafür 
haben.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Oliver:

> Nein. Anscheinend bist du gezwungen, so etwas zu nutzen. Normalerweise
> braucht man so etwas eben so gut wie nie.

Wenn Du weist, was ich brauche, dann ist's ja gut :D
Bin immer froh, wenn ich das selber weis.

Aber ernsthaft, ich reize die Hardware dort aus wo ich es als sinnvoll 
betrachte. Wenn das ein "Zwang" ist, dann soll'st halt recht haben.

Mein vereinfachtes Beispiel sollte auch nur die Verwendung von ASM in 
Bascom demonstrieren, für sowas Einfaches hätte das Gezeigte keinen 
Sinn.

Ein richtiger Fall ist eine zeitkritische ISR, z.B. schnelle Abfrage des 
ADC und nebenbei noch etwas Anderes, und möglichst viel davon. Da zählt 
dann schneller und kleiner Code. Für: wenn Taster gedrückt, dann schalte 
LED ein, brauch' ich's sicher nicht.

Wie Du möglicherweise bemerkt hast, verstehe ich sowohl C, als daß ich 
es auch schreiben kann. Vielleicht weniger gut als Bascom, einfach 
aufgrund der Übung. Bis jetzt habe ich keinen Grund gefunden, in C zu 
schreiben.

>Karl heinz Buchegger wrote:
>Nachtrag:
> Was mich am BASCOM eigentlich immer abgeschreckt hat ist, dass man
> arithmetische Ausdrücke so zerstückeln muss.

Das ist etwas, was ich gerne geändert wüsste.

Autor: be-cool (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
komisch das so viele Forumsbeiträge in die Diskussion um die beste 
Programmiersprache ausarten. Ist Euch schon mal aufgefallen, daß die 
bekennenden Assemblerprogrammierer da fast nie mitreden? Offenbar ist 
denen egal mit was einer proggt. Ansonsten findet doch jeder die Sprache 
besser, welche er kann. Ich programmiere die AVRs auch am liebsten mit 
Bascom, obwohl ich in der Firma C programmiere. Aber das hat alles 
nichts mehr mit der ursprünglichen Frage zu tun.
Eigentlich schade !
Gruß Jürgen

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ein richtiger Fall ist eine zeitkritische ISR, z.B. schnelle Abfrage des
>ADC und nebenbei noch etwas Anderes,

Ich sach ja, Design-Problem, oder keine Vorstellung davon, was das 
Programm und Prozessor wirklich machen. Wenn du Bascom oder C die 
ISR-Grundfunktionalität machen lässt, und dann in der ISR mit 
inline-Assembler anfängst, gehen vorher schon so viele Takte für 
Register pushen drauf, daß es auf "schnell" im Sinne von einem 
(eventuell) zusätzlich eingesparten Takt durch inline-Assembler 
garantiert nicht mehr ankommt. Abgesehen davon sind Register- und 
Portzugriffe in C (und vermutlich auch in Bascom) genausoschnell wie in 
Assembler, da die auf die entsprechenden Assmblerbefehle 1:1 umgesetzt 
werden.

Wenn es da zeitkritisch ist (und das bedeutet wirklich, das es auf 
einzelne CPU-Takte ankommt) dann hilft nur noch, das Register-Retten 
selber zu machen (was übrigends auch in C geht), die ISR so zu designen, 
daß gar keine Register gerettet werden müssen, oder eben gleich die ISR 
ganz in Assembler zu schreiben. Alles kein Grund für inline-Assembler.

>und möglichst viel davon. Da zählt
Design-Problem...

>...schneller und kleiner Code.
Richtig. Geht in C genauso, wie in Assembler.

Oliver

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
be-cool,

naja, das war dann schon irgendwie meine Schuld, nachdem ich möglichst 
dem TE noch einen neutralen Hinweis auf die verfügbaren Sprachen geben 
wollte.

Andererseits sah's aus, als ob er mit der vorher gegebenen Info durchaus 
zufrieden war. Vielleicht hilft ihm dieser Teil der Diskussion zu 
erkennen, womit er am liebsten arbeiten möchte, bzw. wie Anwender der 
einen oder anderen Sprache die Sache so sehen. Also denke ich nicht, daß 
er enttäuscht ist.

Solche Diskussionen entstehen natürlich oft mit dem Hintergrund, in 
missionarischen Eifer den zukünftigen µC Programmierer auf den rechten 
Pfad der Tugend zu führen :D

Wegen meiner kann er nehmen, was er will, die Prinzipienreiterei ist 
doch Krampf. Denn egal was den Job gut und für mich angenehm erledigt, 
ist perfekt für mich. Ist doch nur'n Werkzeug, um dieses schwarze Teil 
mit den silbernen Füßen dran zu überzeugen, das zu tun was ich will.

Und wenn eine Dikussion etwas auswandert, finde ich es zum Teil sehr 
interessant und manchmal auch amüsant. Da muss man nix schade finden.

@Oliver:

Sollt'st recht haben, klar, ein Designproblem. Sagte ja schon, es ist 
gut daß Du weist, was ich mache.

Nur, Du interpretierst meine Worte in Deinem Sinn. Offen gesagt, nach 
Deinem Eifer zu urteilen glaube ich, für Dich trifft Obengesagtes zu.

Das Keyword für Bascom heist übrigens NOSAVE, damit weist man den 
Compiler an, die Register nicht zu sichern.

Könnt' es sein, daß Du über Bascom redest, obwohl Du keine Ahnung davon 
hast ?

Und wie kommst Du eigentlich auf die irrige Idee, daß andere Leute außer 
Dir auf der Brennsuppe dahergeschwommen sind ? Ist Dir schon 
aufgefallen, daß Du der beste Beweis meines Intolleranz Argumentes bist 
?

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um aufs Thema zurückzukommen:

Neben der mechanischen Variante "Differential" reicht doch auch eine 
schaltbare Kupplung. Zum Manövrieren mit unterschiedlichen Raddrehzahlen 
wird die geöffnet, sonst verbindet die beide Räder. Damit bist du dann 
in wirklich allen Betriebszuständen synchron, selbst bei Notstopps mit 
plötzlichem "AK zurück".

Oliver

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
manuel, wenn du eine einger maßen vernünftige fernsteuerung hast, die 
einen v-mischer bietet, dann nimm einfach 2x bl-motor und 2x 
b-controller mit govenor und die sache hat sich.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Sollt'st recht haben, klar, ein Designproblem. Sagte ja schon, es ist
>gut daß Du weist, was ich mache.

Ich habe kein Ahnung davon, was du machst. Ich bestreite nicht, daß man 
mit Bascom alles auf eine AVR machen kann, was überhaupt möglich ist. 
Ich bezweifele auch nicht, daß man generell in jeder Programmiersprache 
modulare, gut strukturierte, les- und wartbare Programme schreiben kann, 
wenn man denn kann. Es darf und soll nutzen, was wer will.

Das ist gar nicht das Thema.

Das Thema ist dein Argument, daß selbst für den C-erfahrenen 
Threadersteller Bascom zur AVR-Programmierung die bessere Wahl sei, weil 
dort inline-Assembler besser unterstützt wird, als in C.

Das Argument ist nunmal Blödsinn, und du kannst es nicht belegen. 
Mischen von Hochsprache und Assembler in einer Funktion hat überhaupt 
keine Vorteile, nur Nachteile. Die Fälle, in denen es unbedingt 
erforderlich ist, sind so extrem selten, daß sie als Argument pro oder 
contra C/Bascom völlig zu vernachlässigen sind (auch wenn es bein gcc 
tatsächlich ein "pain in the ass" ist).

Bascom ist dann klar im Vorteil, wenn es um schnelle Erfolgserlebnisse 
bei der Realisierung kurzer, überschaubarer und nah an den 
Prozessorfunktionen liegender Programme geht. Eine LED blinkt mit Bascom 
schon, da ist Eclipse noch nicht mal fertig gestartet.

Oliver

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das Thema ist dein Argument, daß selbst für den C-erfahrenen
> Threadersteller Bascom zur AVR-Programmierung die bessere Wahl sei,
> weil dort inline-Assembler besser unterstützt wird, als in C.

Oliver,

Du hast ganz sicher ein Problem zu verstehen, was Dein Gesprächspartner 
sagt. Hör doch mal genau hin.

Und jetzt schaust Dir meine Posts in dem Thread an, und Du wirst 
feststellen, daß ich immer sage, es gefällt mir, verstehst Du: MIR.

Somit führe ich kein diesbezügliches Argument und ich erhebe auch keinen 
Anspruch auf Allgemeingültigkeit.

Weiter begründe ich warum mir das so gefällt, und rate ihm er solle doch 
nehmen, was ihm besser liegt.

Ich bin also tolerant gegenüber der von Dir bevorzugten 
Programmiersprache, die nicht unbedingt anfängerfreundlich ist. Zu 
dieser Toleranz bist Du offenbar nicht fähig.

Da Manuel sowohl in VB, als auch in C Erfahrung hat, soll er nehmen, was 
er möchte. Nimmt er Bascom, vielleicht gefällt's ihm nicht, dann macht 
er halt mit etwas anderem weiter. Oder umgekehrt.

Mich würde allein so ein dünbrettgebohre abschrecken, wie hier von 
Deiner Seite kommt.

War ich jetzt immer noch nicht verständlich für Dich ?

Quintessenz: ein guter Programmierer wird gute, intelligente und da wir 
hardwarenah arbeiten auch schnell Algorithmen benutzen, und eine 
passende Programmiersprache als Werkzeug seiner Wahl. Egal welche 
Sprache, die Betonung liegt hier auf "passende".

Nur wäre derjenige ein Narr, der denkt er kann C und wäre deswegen 
automatisch ein guter Programmierer. Gaaaanz falsch.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwie habe ich das Grundproblem noch nicht verstanden. Sollen die 
Schaufeln immer gleich laufen, waere ein Motor und eine Welle die ideale 
Wahl. Soll das Schiff moeglichst geradeaus laufen (ohne Rudereinsatz), 
laesst sich das IMO am besten ueber 2 komplett separate Motoren und eine 
Trimmung realisieren - da wuerde ich idealerweise einfach die vom 
(Computer)-Sender nehmen...

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gute programmierer? lol. die meisten sind zufrieden, wenn das, was sie 
vorhaben, irgendwie gelingt, und der chef nicht draufkommt, das der 
wunderwuzzi keinen tau hat.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Stegemann wrote:
> Irgendwie habe ich das Grundproblem noch nicht verstanden. Sollen die
> Schaufeln immer gleich laufen, waere ein Motor und eine Welle die ideale
> Wahl. Soll das Schiff moeglichst geradeaus laufen (ohne Rudereinsatz),
> laesst sich das IMO am besten ueber 2 komplett separate Motoren und eine
> Trimmung realisieren - da wuerde ich idealerweise einfach die vom
> (Computer)-Sender nehmen...

... solange die Motoren bei gleichen variablen Versorgungsspannungen 
auch gleiche Drehzahl haben. Und genau davor fürchtet sich der OP: Das 
bei jeder Gasstellung eine andere Trimmstellung notwendig sein könnte.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Du hast ganz sicher ein Problem zu verstehen, was Dein Gesprächspartner
>sagt. Hör doch mal genau hin.

Habe ich. Und nur ein unsinniges Argument gehört. Auch wenn es dein 
"ganz persönliches" ist, und selbstverständlich nur für dich und sonst 
niemanden gilt. Warum schreibst du es dann überhaupt? Nicht nur in einem 
Nebensatz, nein, gleich absatzweise. Mit solchen "Hinweisen":

>Du wirst hier im Forum einige Mitglieder finden, die sich abschätzig
>über Bascom äußern. Nimm die Sprache, in der Du lieber programmierst.

>C'ler haben eine deutlich
>geringere Toleranz gegenüber anderen Sprachen, als Basic Verwender.

nur, um dann deine ach so große Toleranz zu beweisen. Danke, ich habe 
den Werbefeldzug pro Bascom gehört. Nicht nur der Inhalt, auch der Ton 
macht die Musik. Für mich persönlich (!!!) ist und bleibt das Argument 
mit der besseren inline-Unterstützung ganz großer, an den Haaren 
herbeigezogener, Bullshit, aber selbtsverständlich darf jeder dazu seine 
einen Meinung haben. Ich bin ja, genauso wie du, sehr tolerant.

Und natürlich schreibe auch ich hier grundsätzlich nur meine ganz 
persönliche Meinung. Was anderes geht in solche einem Forum gar nicht.

Mir persönlich (!!!) reicht der Fakt, daß im Lauf der Zeit nach Basic 
(und FORTRAN) andere Programmiersprachen entwickelt wurden (auch 
modernere Basic-Dialekte), die sich durchgesetzt haben. Für mich 
persönlich (!!!) gibt es keine einzigen Grund, Basic in auf eine 
Mikrocontroller einzusetzen. Ich persönlich (!!!) habe vor Jahren mit 
Basic meine ersten Programmschritte gemacht (Commodore 64, Dragon 32 und 
wie sie alle hiessen), und bin heilfroh, daß sich da andere die Mühe 
gemacht haben, aus den Erfahrungen mit Fortran (und dem daraus 
abgeleitetem Basic) zu lernen, und neuere, modernere und weitaus besser 
strukturierte Programmiersprachen zu ersinnen. Ich persönlich (!!!) habe 
Jahre damit verbracht, mich in semiprofessionellen (sprich: hochschul- 
:-) steuerungsnahen Softwareprojekten durch Sourceode von anderen Leuten 
zu wühlen und zu darin zu programmieren, in FORTRAN, Pascal, C, C++, 
Eiffel, Lisp, unter Dos, Unix, Windows, Apple Mac, VxWorks, in Assembler 
auf allen mögichen Prozessoren. Nirgends perfekt, aber überall 
ausreichend. In allen Programmiersprachen gab es gut gemachte und 
schlecht gemachte Programme. Ausnahme: Fortran. Da überwiegten (nach 
meiner ganz persönlichen (!!!)Meinung) die schlechten. Basic kam da 
schon gar nicht mehr vor, ist aber leider zu nah dran an Fortran.

Alles meine ganz persönliche Meinung. Wer das anders liest, ist selber 
schuld.

>Mich würde allein so ein dünbrettgebohre abschrecken, wie hier von
>Deiner Seite kommt.

Mich würde einfach ein klitzekleines Besipiel überzeugen, in dem du 
zeigst, daß inline Assembler in Bascom ein Problem so grundsätzlich 
besser, eleganter, kürzer, einfach irgendwie überzeugend, löst, daß sich 
deine ganz persönliche Empfehlung an den Threaderöffner, C statt Bascom 
einzusetzen, nachvollziehen lässt.

Oliver



Oliver

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver,

mit Dir eine Diskussion zu führen erinnert mich an ein nörgelndes Kind, 
das glaubt sein Spielzeug ist das Beste. Großes Geschrei, wenn jemand 
etwas anderes sagt.

Wenn derjenige, der vor dem µC sitzt, ein schlauer Kopf ist, dann sucht 
er sich schon die Programmiersprache mit der er gut klarkommt. Hab' da 
beim Manuel überhaupt keine Zweifel, daß er das Richtige findet.

Auch wird seine Seele sicher nicht der Hölle anheim fallen, sollte er 
Bascom, oder etwas Anderes ausprobieren.

Nur weil Du im Laufe Deines Studiums oder Berufes eine Lösung für Dich 
gefunden hast, ist sie noch lange nicht auf Andere übertragbar. 
Eigenartigerweise gibst Du doch selbst zu, klein angefangen zu haben, 
wieso gestehst Du das nicht auch Anderen zu ?

Und jetz ist Bascom im Vergleich alles Andere als "klein".

Jetzt kann's ja sein, daß dieses Thema Dich irgendwie besonders aufregt, 
darum meinn Rat:

Mach Dich locker.

Glaubst Du im Ernst, ich such hier jetzt nach Codeschnipseln, nur um 
Dich von irgendwas zu überzeugen ? Das ist weder mein Ziel, noch hab' 
ich's nötig, ich weis was ich kann.

Selbst wenn ich Dir eine in Bascom codegewordene Desoxyribonukleinsäure 
zeigen würde, bekäm' ich das gleiche Genörgel, von wegen C ist besser, 
das wäre auch in C besser gegangen, usw. Glaubst Du ich steh' auf so was 
?

> daß sich deine ganz persönliche Empfehlung an den Threaderöffner,
> C statt Bascom einzusetzen, nachvollziehen lässt.

Nochmal gaaaaanz langsam, zum langsamen mitdenken: Ich habe die Vorzüge 
von Bascom aus meiner Sicht dargestellt und Manuel geraten, er möge 
nehmen, was ihm besser zusagt. Ich habe nicht gesagt, nimm C statt 
Bascom, und auch nirgends gesagt, nimm Bascom statt C. Ich hab' gesagt, 
nimm, was Dir gefällt. Bist Du begriffsstutzig?

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Glaubst Du im Ernst, ich such hier jetzt nach Codeschnipseln, nur um
>Dich von irgendwas zu überzeugen ? Das ist weder mein Ziel, noch hab'
>ich's nötig, ich weis was ich kann.

Es war dein Argument, nicht meins. Und es war so ungewöhnlich, daß ich 
da gerne noch etwas gelernt hätte. Ach ja, entschuldige, daß ich bei 
deiner Erwähnung, einen ADC im Interrupt auslesen zu können, nicht 
gleich in Ehrfurcht erstarre.

Die obige Antwort reicht mir persönlich. Machen wir hier einfach Schluß.

Oliver

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schön. Einverstanden.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:

> ... solange die Motoren bei gleichen variablen Versorgungsspannungen
> auch gleiche Drehzahl haben. Und genau davor fürchtet sich der OP: Das
> bei jeder Gasstellung eine andere Trimmstellung notwendig sein könnte.

Hm, das Problem sollte sich z.B. mit buerstenlosen Motoren und passenden 
Reglern (nicht Stellern, also mit Heli- oder Governer-Mode) loesen 
lassen.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Hm, das Problem sollte sich z.B. mit buerstenlosen Motoren und passenden
>Reglern (nicht Stellern, also mit Heli- oder Governer-Mode) loesen
>lassen.

Das sollte auch mit "billigen" Bürstenmotoren gehen.

[OT]
Was soll eigentlich schon wieder dieses 
Auf-Programmiersprachen-Rumgereite?
Der Algorithmus ist die Lösung des Problems, nicht die Sprache in der 
man ihm aufschreibt. Das ist dann eher eine Optimierung. (Öl ins Feuer: 
C ist das bessere Optimier-Werkzeug! ;)
[/OT]

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was machen denn die armen Modellbauer mit Mehrschrauben-Antrieben in 
ihren Modellen? Ich glaube kaum, daß da auch nur einer über 
Synchronisation nachdenkt. Da gibt es so viele Störungen durch Wellen 
und Wind, geradeaus fährt da auf Dauer sowieso nichts von alleine.

Und die "echten" Dampfschiffer, wenn sie denn überhaupt zwei 
Dampfmaschinen hatten, waren bestimmt schon froh, wenn die beide 
ungefähr in die gleiche Richtung liefen. Den Rest machte der Käptn am 
Rad. Die mit nur einer Maschine hatten zwar das Problem mit den 
Drehzahlen nicht, am Rad drehen musste der Käptn aber genauso :-)

Oliver

Autor: eaehavelich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver sieht es genau richtig.

Drehzahlunterschiede von 10% bemerkt man überhaupt nicht.

Andreas

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
STK500-Besitzer wrote:
>>Hm, das Problem sollte sich z.B. mit buerstenlosen Motoren und passenden
>>Reglern (nicht Stellern, also mit Heli- oder Governer-Mode) loesen
>>lassen.
> Das sollte auch mit "billigen" Bürstenmotoren gehen.

Nur sind die meist sowieso nicht billiger und die Regelung nicht 
integriert.

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal abgesehen davon, dass zwischenzeitlich der "Krieg" hier mehr Platz 
einnimmt als die Problemlösung  - Anfangs war ich ja überrascht, dass 
dieses Forum besser funktioniert... wie blauäugig - finde ich es 
interessant, dass immer mehr Leute erklären, warum die Idee, Aufgabe wie 
auch immer so nicht sinnvoll ist.

Natürlich kann ich eine durchgehende Welle einbauen und ich bezweifle 
auch nicht, dass ein guter Geradeauslauf ohne zusätzliche Steuerung 
möglich ist.
Fakt ist: ich will, dass die Schaufeln synchron laufen.
Ob ich das will weil ich glaube, dass damit der Dampfer am besten 
funktioniert oder ob ich das einfach will, weil mir dann mein Schnitzel 
besser schmeckt spielt doch keine Rolle!

Aber vielleicht baue ich am Ende auch einfach einen Raketenantrieb ein 
und lass die Schaufelräder durch die Wasserströmung antreiben...

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manuel wrote:

> Fakt ist: ich will, dass die Schaufeln synchron laufen.
> Ob ich das will weil ich glaube, dass damit der Dampfer am besten
> funktioniert oder ob ich das einfach will, weil mir dann mein Schnitzel
> besser schmeckt spielt doch keine Rolle!

Hier kommen die ganze Zeit Leute an, die genau wissen, was sie wollen 
und nachher kommt raus, dass sie sich nur schon voellig verfranst haben.

Du hast diverse Vorschlaege bekommen, ich habe dir auch nochmal einen 
gemacht, der sich mit Fertigteilen erledigen laesst - wie waer's mit 
einem Dankeschoen?

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Dankeschön habe ich oben schon mehrfach verbreitet - auch für einen 
Vorschlag mit Brushless Motoren...

Und wenn ich einfach nur will, dass sich die Schaufeln synchron drehen, 
kann ich mich noch nicht weit verfranzt haben.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Sei doch nicht gleich eingeschnappt. Vielleicht solltest du auch noch 
mal deinen Lösungsansatz überdenken. Wenn mich meinen Erinnerungen an 
meine (mehr passive Modellbauzeit) nicht trügen, werden 'modernere' 
Schaufelradantriebe nicht über die Drehzahl, sondern über die Stellung 
der Schaufeln gesteuert. Für einen maximalen Vortrieb werden die 
Schaufeln so gesteuert, das sie während der Eintauchzeit immer senkrecht 
zu Wasseroberfläche stehen. Die Schaufelräder drehen sich mit der 
gleichen Drehzahl (eine Achse). Allerdings stellt das einen recht hohen 
mechanischen Aufwand dar.
Aus der Historie stammen Schaufelradantriebe aus der Dampfmaschinenzeit 
und waren bei grösseren (Segel-) Schiffen als Hilfsantrieb und bei 
kleineren als Hauptantrieb mit jeweils einer Dampfmaschine bestückt. Die 
Geschwindigkeit wurde über die Drehzahl und die Richtung mit dem Ruder 
bestimmt. Eine getrennte Reglung wäre in Hinsicht auf Vorbildtreue 
eigentlich nicht notwendig.

MfG Spess

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Fakt ist: ich will, dass die Schaufeln synchron laufen.

Aussagen wie Synchron, Gleichzeitig, Sofort, Schnell, sind in 
technischen Systemen grundsätzlich ohne genauere Definition, was das 
eigentlich bedeuten soll, unbrauchbar und nicht erfüllbar.

Also: Was verstehst du unter "Synchron"?

Winkelsynchron, wie starr verbunden? Immer, in jedem 
Geradeaus-Betriebszustand? Mit welcher zulässigen Abweichung, statisch 
und dynamisch?
Winkelsynchron, zusätzlich mit dem Wunsch, daß im Geradeausbetrieb die 
Schaufeln auf beiden Seiten gleichzeitig ein- und austauchen? Und wie 
groß darf dann während des Ausregelns der Abweichung die maximale 
Drehzahldifferenz sein?
Drehzahlsynchron? Mit welcher zulässigen Abweichung, statisch und 
dynamisch?

Gehen tut (fast) alles. Aber wissen, was du wirklich willst, solltest du 
schon.

Oliver

Autor: Michael Waiblinger (wiebel42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Manuel,

ich hoffe du hast trotzdem genügend Tipps bekommen um etwas davon 
umzusetzen, wenn ja informiere uns doch bitte wie du es am Ende gelöst 
hast und wie es geklappt hat. Vielleicht behältst du, der besseren 
Lesbarkeit des Threads wegen, die Wahl der Programmiersprache für dich. 
sigh -wiebel

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt mal Hand auf's Herz: ich möchte, dass sich beide Seiten mit der 
gleichen Drehzahl drehen.
Und dass meine Beschreibung akademischen, wissenschaftlichen oder 
meinetwegen auch nach Ingenieursmäßigen Prüfungen nicht Standhält, mag 
ja sein. Aber hast du Anhand der Beschreibung wirklich nicht verstanden, 
was das Ding tun soll?

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Woher kommt eigentlich die Idee, dass einem besser geholfen wird, wenn 
man die potentiellen Helfer dumm anmacht?

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Besser geholfen wird? Besser, als mit ner Diskussion über diverse 
Programmiermöglichkeiten?

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>ich möchte, dass sich beide Seiten mit der
>gleichen Drehzahl drehen.

Hand aufs Herz: Wenn du zwei baugleiche Gleichstrommotoren nimmst, und 
auf beide an die selbe Spannungsversorgung hängst, ganz ohne Regelung, 
dann laufen die "gleichschnell". Du wirst an den Schaufelrädern mit 
blosem Auge keine Unterschied feststellen können, wenn die Mechanik 
nicht arg unterschiedlich klemmt (was ich bei deinem Perfektionsanspruch 
selbstverständlich ausschliesse :-)

Optisch gleichschnell reicht aber nun anscheinend für deine Anwendung 
nicht aus, es soll "gleicher" sein. Da es aber deine Anwendung ist, die 
nur du kennst, musst du schon mal formulieren, was denn nun in deinen 
Augen "gleich" bedeutet.

Oliver

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manuel wrote:

> Besser geholfen wird? Besser, als mit ner Diskussion über diverse
> Programmiermöglichkeiten?

Du scheisst hier vor allem die an, die konkret versucht haben, dein 
Problem zu verstehen (z.B. Oliver). Vieleicht ist es besser, du bleibst 
in deinem Bastelkeller.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:

Wie Du vielleicht erkennen kannst, wurde Manuels Thread benutzt, um 
akademische Sichtweisen über den Wert bestimmter Programmiersprachen 
unter die Leute zu bringen.

Die Diskussion hab' ich eine Zeit lang selbst mitgemacht, es hat mich 
wirklich interessiert wie weit der Schmarrn gehen kann. Nun weis ich 
Bescheid und hoffe daß unsere Wirtschaft von solchen Erbsenzählern 
verschont bleibt, viel heiße Luft aber praktisch kommt nix raus.

Mich stört selbst, wenn ein Hilfesuchender sich über gegebene Hilfe 
beschwert, hab' das bei Manuel aber in keiner Weise feststellen können, 
er ist meiner Meinung nach aus dem Gros der Fragesteller hier im Forum 
eindeutig einer der Guten. Das er sich übers Hijacking seines Threads 
beschwert, kann ich verstehen.

Ohne nun viel reinzuinterpretieren, was Manuel nun genau will, so ist 
doch unter Berücksichtigung der typischen Funktionsweise eines 
Schaufelraddampfers und unter Berücksichtigung der Aussagen von Manuel 
meiner Meinung nach folgendes richtig:

- Die Schaufeln sollen sich bei Geradeausfahrt synchron zueinander 
bewegen, in der Weise daß für das Auge kein Unterschied in der 
Umlaufgeschwindigkeit der Räder feststellbar ist.

- Für deutliche Kurskorrekturen, bzw. Wendemanöver sollen die Schaufeln 
einzeln in Geschwindigkeit und Drehrichtung gesteuert werden können.

- Bei Rädern mit vielen Schaufeln ist Winkelsynchronität nicht 
notwendig, da nicht wahrnehmbar, bei wenigen Schaufeln evtl. 
wünschenswert, Ansteuerung verkompliziert sich dadurch.

Mögliche Antriebe:

- Normale Elektromotoren mit Hallgeber und Getriebe
- Kollektorlose Motoren mit Vorgabe der Solldrehzahl per serieller 
Ansteuerung
- Schrittmotoren
- Mit Encodern auf den Schaufelrädern lässt sich bei jeder der genannten 
Lösungen Winkelsynchronität erreichen

Das sollte es einigermaßen treffen. :D

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.