berechnungen...

Zitat:

Zitat von PicNick

Ein Wahnsinn, wenn man bedenkt, daß diese Leute dafür bezahlt werden.
Was man im Netz so alles findet, und keiner kennt Henrik

http://www.cs.washington.edu/homes/l.../cra/risc.html

Reduced Instruction Set Computers (RISC):
.

Du kleines überhebliches A:::: kannst ganz prachtvoll vermeinliche Quellen heraussuchen, scheinst aber den Unterschied zwischen Computing und Computer nicht zu kennen.

Hausaufgabe:

Erkläre die Unterschiede zwischen einem Rechner (Computer) dem Code (Befehlssatz) und einem Compiler , der sowohl den Computer als auch dessen Code benutzen muss. - Beachte hierbei die semantischen Unterschiede zwischen Computer und Computing.

Wollen wir nun diskutieren ob Wasser nass ist und 1+1 statt 2 nicht doch evtl. etwas dazwischen --- so 1,1 bis 1,9?

Henrik

Könnte bitte mal ein Moderator die Diskussion ein bisschen zusammenfassen?

Der Stil der Äußerungen wird dem Thema nicht gerecht. Wer wen zu recht oder zu unrecht als minderwertig ansieht, interessiert sonst keinen.

Ich hoffe auch, dass Teilnehmer die Kraftausdrücke benutzen wollen, den geeigneten Ort dafür finden.

sitze gerade erschrocken vor meinem pc... ;) hätte nicht gedacht das eine so kleine frage gleich so eine diskussion auslöst! ich hoffe ihr habt euch wieder ein bisschen beruhigt...

mfg bluesmash

Zitat:

Zitat von Anonymous

Könnte bitte mal ein Moderator die Diskussion ein bisschen zusammenfassen?

Der Stil der Äußerungen wird dem Thema nicht gerecht. Wer wen zu recht oder zu unrecht als minderwertig ansieht, interessiert sonst keinen.

Ich hoffe auch, dass Teilnehmer die Kraftausdrücke benutzen wollen, den geeigneten Ort dafür finden.

Na prima, feige auch noch :-) Gast...

Trotzdem:

1) Bascom kann nun mal keine mathematischen Ausdrücke verarbeiten. Basco scheitert nicht erst an hierarchisch strukturierten Ausdrücken, sondern bereits an Befehlszeilen wie:

LCD meine_variable + 1

Also muss man, wann immer dergleichen auftaucht, solchen Kladderadatsch auflösen.

z.B.

meine_variable = meine_variable + 1
LCD meine_variable

Bei Klammerrechnungen und anderen komplexen Aufgaben ist das Auslagern in eine SUB/FUNKTION sinnvoll. Zum Bleistift wenn man einen DS1621/1631 etc hochauflösend nutzen will:

Code:

Function Calc_temperature() As Word 'Value =(temperature * 100 - 25) +((slope - Counter_ds) * 100 / Slope) Local Zwischen1 As Word Local Zwischen2 As Word Local Zwischen3 As Word Temperature = Temperature * 100 Temperature = Temperature - 25 Zwischen1 = Slope - Counter_ds Zwischen2 = Zwischen1 * 100 Zwischen2 = Zwischen2 / Slope Zwischen3 = Temperature + Zwischen2 Calc_temperature = Zwischen3 End Function

Das ist lästig, aber kein Grund Bascom nicht zu nutzen.

2) Vergleiche mit Assembler zur Rechtfertigung dieser Rechenschwäche von Bascom zu gebrauchen ist unsinnig, da mit solchen Äpfel- und Birnenvergleichen jedwede Benutzung einer Hochsprache obsolet wäre.

3) RISC hat damit nun garnichts zu tun und lautet in der Langschrift nun mal Reduced Instuction Set Code. Keineswegs "Computing".

4) Es handelt sich hier bei den Punkten 1 (bezogen auf die Rechenschwäche) bis 3 nicht um "Meinungen" wie ein Moderator meinte mir mitteilen zu müssen, sondern schlicht um Tatsachen. Bezüglich der semantischen Seite der Angelegenheit gibt der Oxford Dictionary Auskunft. Demnächst würden wir uns dann eben auch darüber unterhalten müssen, wenn jeman der "Meinung" ist, die Erde sei eine Scheibe.

Henrik

ich habe auch ca 8 monate mit bascom gearbeitet, bin dann nach winavr-c umgestiegen. der grund: bacom geht zu grosszügig mit der umsetzung um.
7 oder 8 register werden bei der kleinsten aufgabe gepusht und gepopt, das ist sehr zeitintensiv. bei jedem kleinen sensor wird ein timer genutzt, obwohl das manchmal nicht immer nötig ist. der OC1A wird für ein ir-signal-sender genommen z.b., obwohl man den auch ohne proggen kann, habe ich in winavr-c bewiesen. bascom kann man zwar per interrupt steuern lohnt aber nicht, weil die sub-routinen zu lange dauern. es ist nicht für mehrere sensoriken am robby geeignet .
als anfängersprache gut, für ein halbprofi überfordert.
mfg pebisoft

Zitat:

als anfängersprache gut, für ein halbprofi überfordert.

Warscheinlich werden viel mehr professionelle Sachen in BASCOM programmiert als man glaubt ;)
Dem Kunden ist es schließlich vollkommen egal, welche Programmiersprache sein Gerät hat, ob sie sinnvoll mit Resourcen umgeht oder was auch immer.
Heutzutage zählt eben auch die schnelle Umsetzung eines Projektes.
Und mit Bascom kommt man sehr schnell zu einem Ergebniss.

Daß Bascom Schwächen hat ist klar, aber für mich überwiegen ebenfalls die Vorteile.
Bis jetzt habe ich noch jedes Projekt mit Bascom zum benötigten Zeitpunkt (manchmal sehr knapp :) ) und mit der geforderten Funktionalität zum laufen gekriegt.

Da ich nicht der große Crack im programmieren bin, ist Bascom für mich ideal.
Mit C oder anderen Programmiersprachen konnte ich mich nie anfreunden.
Habe zwar gerne auf dem 8051 Assembler gemacht, aber das ist lange her..

Gruß
Christopher

Dem kann ich mich auch anschließen, bei mir gabs auch noch keine Aufgabe die mit Bascom nicht optimal lösbar gewesen wäre. Es mag einzelne Libary Funktionen geben die man besser oder optimierter anlegen könnte, aber das ist bei GCC auch der Fall. Bis man ein mittelgroßes Projekt mit GCC realisiert hat, hat man in der Regel bereits zwei in Bascom entwickelt. Vorausgesetzt man hat sich etwas in die Sprache eingearbeitet.

Aber das mathematischen Formeln in mehrere Zeilen gesplittet werden müssen ist ohne Frage ein Bascom Nachteil, insbesondere auch für Einsteiger. Allerdings gewöhnt man sich an dieses Manko und es hat sogar den Vorteil das man oft etwas gedankenvoller programmiet. Und da diese Vorgehensweise etwas näher der Maschinensprache ist, dürfte der Compiler bei komplexen Rechnungen auch den besseren optimierteren Code erzeugen.
Angesichts der enormen Produktivität von Bascom nehme ich dieses kleine Manko gerne in Kauf.
Das schöne an Bascom ist auch das Projekte in eier einzigen BAS Datei realisiert werden. Schaut Euch mal dagegen ein C-Projekt an, viele Header-Dateien,C-Files, Projektdateien müssen angelegt werden. Sowas ist bei Mamut PC-Projekten ja manchmal ganz nett, aber bei einem kleinen Controllerprogramm nervt es mich doch erheblich.

@hrei Übrigens möchte Dich doch bitten den Tonfall vieler Deiner Postings nochmal zu überprüfen und zukünftig zu verbessern. So ein rauhen Ton mögen wir nicht so sehr im Roboternetz, das kann man auch anders formulieren.

Gruß Frank

Zitat:

Das schöne an Bascom ist auch das Projekte in einer einzigen BAS Datei realisiert werden.

Stimmt, das ist sehr angenehm.

Ich bin bei größeren Projekten allerdings dazu übergegangen, mehrere Dateien zu verwenden und die dann per
$include "xxxxx.bas" einzubinden.
Bei Fehlern öffnet Bascom die entsprechende Datei und zeigt den Fehler richtig an.
Das ganze ist sehr praktisch, hat allerdings den Nachteil, daß Bascom nur im jeweils geöffneten File suchen kann.
Wenn man also irgendwas sucht, muß man sich unter Umständen durch alle Files durchhangeln...

Gruß
Christopher

Zitat:

Zitat von chr-mt

..., muß man sich unter Umständen durch alle Files durchhangeln...

Is richtig, aber wenn du alles in einem Directory hast, kannst du dir das Windows-"Search" Fenster bereithalten.

Zitat:

Zitat von Frank

Es mag einzelne Libary Funktionen geben die man besser oder optimierter anlegen könnte, aber das ist bei GCC auch der Fall. Bis man ein mittelgroßes Projekt mit GCC realisiert hat, hat man in der Regel bereits zwei in Bascom entwickelt. Vorausgesetzt man hat sich etwas in die Sprache eingearbeitet.

Kommt immer auf das Projekt an. Ein Hello World hat man mit Bascom vermutlich schneller programmiert, sobald aber es aber darum geht eine komplexe Daten Ein-/Ausgabe mit mehreren Ringpuffer usw. zu realisieren ist man mit C schneller.

Außerdem kann man C mehr optimieren, da man sich mal eben den Assemblercode zu seinen C Quelltext anschauen kann. So kann man sehr schön sehen was schnell geht und was viel Platz verbraucht und es entsprechend umgestalten.

Beispiel:

Code:

void uart_put_hex(uint8_t data) { 786: cf 93 push r28 788: 98 2f mov r25, r24 uint8_t hi, low; /* Obere 4-bit */ hi = data & 0xf0; hi >>= 4; 78a: 82 95 swap r24 78c: 8f 70 andi r24, 0x0F ; 15 hi += '0'; 78e: 80 5d subi r24, 0xD0 ; 208 if ( hi > '9') 790: 8a 33 cpi r24, 0x3A ; 58 792: 08 f0 brcs .+2 ; 0x796 hi += 7; // A..F 794: 89 5f subi r24, 0xF9 ; 249 /* Untere 4-bit */ low = ( data & 0x0f ) + '0'; 796: 9f 70 andi r25, 0x0F ; 15 798: c9 2f mov r28, r25 79a: c0 5d subi r28, 0xD0 ; 208 if (low > '9') 79c: ca 33 cpi r28, 0x3A ; 58 79e: 08 f0 brcs .+2 ; 0x7a2 low += 7; // A..F 7a0: c9 5f subi r28, 0xF9 ; 249 uart_putc(hi); 7a2: 0e 94 36 03 call 0x66c uart_putc(low); 7a6: 8c 2f mov r24, r28 7a8: 0e 94 36 03 call 0x66c 7ac: cf 91 pop r28 7ae: 08 95 ret

Zitat:

Zitat von Frank

Das schöne an Bascom ist auch das Projekte in eier einzigen BAS Datei realisiert werden. Schaut Euch mal dagegen ein C-Projekt an, viele Header-Dateien,C-Files, Projektdateien müssen angelegt werden. Sowas ist bei Mamut PC-Projekten ja manchmal ganz nett, aber bei einem kleinen Controllerprogramm nervt es mich doch erheblich.

Es spricht ja nichts dagegen das bei C auch zu tun. Aber wenn man eine einzige Datei mit über 2000 Zeile Code habe verliert man vollkommen die Übersicht.
Da ist es wesentlich angenehmer das Ganze aufzusplitten in verschiedene Dateien in denen jeweils zusammenhängender Code groupiert wird. Diese Dateien stellen dann bestimmt Funktionen als Schnittstelle zur Verfügung mit denen man den Ganzen Code nutzten kann ohne direkt verstehen zu müssen wie er im Einzelnen funktioniert :-)
Wenn man einmal das Prinzip dahinter verstanden hat und diese Feature sinnvoll nutzt lässt sich damit sehr gut programmieren...

MfG Kjion

PS: Um auch nochmal auf die ursprüngliche Frage einzugehen :

Code:

red0 = (boden_value_red0[2*i]*256 | boden_value_red0[2*i + 1]) >> 2;

In C ist sowas kein Problem :-)