ja stimmt ...

duplo schrieb:
> Was denkt ihr über Bascom?

Indiskutabel. Gründe ? Stehen im K&R.

Besser, ein Mod löscht diesen Thread zeitnah ;)

Wir wissen doch alle auf was dieser Thread hinausläuft - ne Menge 
Popcorn ;)

Hans Peter B. schrieb:
> Im µC-Umfeld sollte Bascom, für einen ökonomisch denkenden Generalisten,
> den gleichen Stellenwert haben wie C. Bei der Nachkalkulation fragt kein
> Mensch mehr, auf welcher linguistischen Basis das Produkt enstanden ist,
> sondern nur noch was es gekostet hat.

Dennoch stellen dieselbigen Verantwortlichen Niemanden ein, der an der 
Stelle von guten altem C nur Bascom spricht.

Gruß Oliver

Oliver J. schrieb:
> Hans Peter B. schrieb:
>> Im µC-Umfeld sollte Bascom, für einen ökonomisch denkenden Generalisten,
>> den gleichen Stellenwert haben wie C. Bei der Nachkalkulation fragt kein
>> Mensch mehr, auf welcher linguistischen Basis das Produkt enstanden ist,
>> sondern nur noch was es gekostet hat.
>
> Dennoch stellen dieselbigen Verantwortlichen Niemanden ein, der an der
> Stelle von guten altem C nur Bascom spricht.

Und das machen die auch nicht aus Witz. Jeder der schonmal ein Produkt 
entwickelt hat (kein Hobbyzeugs) der weiß wovon ich spreche. Kannst ja 
mal in einen Betrieb gehen und sagen du willst ein Prjojekt mit Bascom 
realisieren - da wird man dich auslachen. C ist eine derart triviale und 
einfach zu erlernenden Sprache - das sind einfach Mindestanforderungen. 
Wer sowas nicht mitbringt, der hat auch im beruflichen Sektor nichts zu 
suchen. Für den Hobbybereich mag das durchaus legitim sein.

duplo schrieb:
> Wenn ich mir als Assembler und C Fan die Bemerkung erlauben darf, ist
> Bascom schlichtweg ein Hammer. Musste schnell einen XMega für ein GSM
> Gateway proggen.
> Notwendig waren 3 UARTs,SPI,1Wire und I2C. Das Brutale war dann noch das
> Management einer SD Card.
>
> In C mit Studio 6 eine wissenschaftliche Arbeit und eigentlich unmöglich
> unter 40 Stunden. Mit Bascom war das ohne Kenntnis der Umgebung in 2
> Tagen erledigt.

Das ist die Frage - was genau ist denn an Bascom so unbedingt 
schwieriger als an C. Gut C ist etwas kryptischer (für Anfänger) und 
maschinennäher. Gerade bei bei der Fehlersuche ist das so hilfreich. 
Dazu bedarf es aber viel Übung. Aber dann ist C unschlagbar, spitze 
durchstrukturiert, keine riesige Codehäufen wie bei Bascom ... Ich finde 
das auch optisch schöner.

Nicht, dass wir uns falsch verstehen, ich respektiere jeden, der Bascom 
programmiert. Das muss jeder für sich selbst entscheiden. Ich finde es 
auch gut, dass z.B. mit Arduino auch dem "nicht-Programmierer" eine 
Möglichkeit geschaffen wird in die Welt der Hobbymikrocontroller 
einzusteigen. Dennoch muss man sich immer seines Wissenstandes bewusst 
sein und wissen, wo man auf der Skala der Mikrocontrollerprogrammierung 
steht.

Weg mit diesem Basic Gefrickel schrieb:
> dann klappts auch mit dem angestrebten Entwickler-Job

Wo stand da im Eingangspost etwas von einem angestrebten Entwickler-Job?
Es geht doch nur darum, ob andere Bascom auch für schnelle Projekte 
nutzen würden.

Ich selbst nutze zwar Assembler und C, da mir Bascom mit der Basic 
Syntax nicht gefällt, aber deshalb darf man das nicht alles gleich 
schlecht heisen.

Für manchen Bastler ist der schnelle Erfolg wichtiger, als das 100% 
korrekte. Mein Ziel ist zwar auch immer das 100%, aber hin und wieder 
mache ich da auch abstriche, da ich zum einen das Wissen nicht habe und 
zum anderen auch mal den schnellen erfolg wünsche.

Daher sage ich mal so, wenn ich mich mit der Basic Syntax anfreunden 
könnte und ich einen sehr schnellen erfolg haben wollte, dann würde ich 
es auch nutzen. Anstreben möchte ich aber, das ich Assembler und C 
behersche.
Assembler, da es hardware näher ist und viel mehr Wissen benötigt (habe 
ich selbst schon festgestellt, das man Assembler nicht mal eben in 2 
Wochen lernt) und C um damit schnelle erfolge zu erziehlen.

Überraschter schrieb:
>
> Stellt sich die Frage, warum es in C nach mehr als 4 Jahrzehnten noch
> immer ein goto gibt, während viele Basic Dialekte heutzutage längst
> genügend strukturierende (Schleifen-) Befehle mitbringen, die das alte
> goto überflüssig machen?

Programmiere einen Treiber und du wirst es verstehen.

Nur mal zur Ansicht:

if( register_chardev( ...) not failed ){
 if( request_region(...) failed )
  goto out_region;
 if( request_irq(...) failed )
  goto out_irq;
 return 0; // success
} 
else{
 goto out;
}

out_irq:
    free_region(...);
out_region:
    unregister_chardev( ... );  
out:
    return -EIO;

Ich programmiere PICs in PicBasic Pro

BASIC wird überall sofort verteufelt. Ist halt so !

Ich kann in PicBASIC sehr schnell Erfolge liefern. Ich nutze die 
Sprache, um meine Befehle abzuarbeiten und nur etwas Struktur (IF, 
Sprünge, etc.) einzubringen.
Ich stelle mir jeden Befehl in Assembler vor und vermeide unnötigen 
Ballast.

Gerade im Hobby-Umfeld sehe ich oft C-Programme, die einfach mal so eben 
Floating-Point nutzen um eine Zahl in einen String umzuwandeln und sich 
dann wundern, warum das Programm nicht in den Micro-uC paßt.
Das passiert mir bei PicBASIC nicht, weil es das nicht gibt. Basta.

Ich habe zur Zeit ein Projekt, das 6000 Zeilen Code umfaßt, das ich 
bestens beherrsche. Bei Programmen in C komme ich da eher durcheinader. 
Ein einziges falsches Zeichen bringt keine Fehlermeldung, sondern 
anderen Code.
Die Syntax von C aus einer kruden Vermengung einzelner Ziffern und 
Zeichen stellt gerade den Anfänger auf eine harte Probe.

Und wer glaub, C sei portabel... Gerade bei uCs hat jeder Hersteller 
seine eigenen Libs für die Ansteuerung der Hardware. Da kann man 
jedesmal alles anpassen.

Bei PicBasic (also BASIC) verzichte ich auch diesen Librarys-Wahnsinn 
und programmiere die Zugriffe auf die Hardware selbst in der Art, daß 
der erzeugte Code schon optimiert für den Assembler ist. Der Compiler 
hilft mir bei dem Mapping der Variablen (das ist echt eklig) und für 
Interrupts schreibe ich Assemblercode rein.

Wenn ich in C anfange, dann hört es für mich eigentlich schon beim 
"viod" auf und bei der Auftrennung in Header- und Source-Files. Das mag 
für den Theoretiker mit der Nickelbrille ganz toll sein, aber wir wollen 
nicht den Mondflug programmieren mit Abteilungs-übergreifenden Librarys, 
sondern es gibt eine Lösung. basta !

Am Ende gibt es ein .hex-File zum Brennen (inkl. der Fuse-Bits !!!!!).
Oder einen Menschen mit Verstand, der den Klartext eines BASIC-Programms 
lesen kann und mit den Kommentare den Sinn schnell versteht.


und jetzt könnt ihr mich verbrennen ;-)

Lueger schrieb:
> Basic war und ist sehr gut und die Mutter aller Programmiersprachen.

Nein, das ist Lisp :)


Tim T. schrieb:
> Nur mal zur Ansicht:

if( register_chardev( ...) not failed ){
 if( request_region(...) failed )
  goto out_region;
 if( request_irq(...) failed )
  goto out_irq;
 return 0; // success
} 
else{
 goto out;
}

out_irq:
    free_region(...);
out_region:
    unregister_chardev( ... );  
out:
    return -EIO;

Autsch! Das ist ja ein geradezu perfektes Paradebeispiel dafür, wie man
Gotos nicht benutzen sollte. Warum schreibst du nicht einfach

if( register_chardev(...) not failed ) {
  if( request_region(...) not failed ) {
    if( request_irq(...) not failed )
      return 0; // success
    free_region(...);
  }
  unregister_chardev(...);  
}
return -EIO;

Das tut das Gleiche, ist nur halb so lang, kommt ohne Gotos aus und ist
(zumindest für meinen Geschmack) um Welten leichter durchschaubar.

Hättest du in deiner Goto-Orgie wenigstens alle drei Abfragen gleich-
artig formuliert, dann wäre sie trotz der Gotos gut lesbar:

  if( register_chardev(...) failed )
    goto out;

  if( request_region(...) failed )
    goto out_region;

  if( request_irq(...) failed )
    goto out_irq;

  return 0; // success

out_irq:
  free_region(...);
out_region:
  unregister_chardev(...);  
out:
  return -EIO;

Aber dein ursprüngliches Code-Fragment hat außerhalb des Tellers im
Ristorante wirklich nichts zu suchen  =8-[

Hat nichts mit C oder Bascom zu tun, sondern mit den verfügbaren 
Bibliotheken.

Frank schrieb:
> Ich möchte bei dieser Gelegenheit mal auf einen anderen Basic-Dialekt
> hinweisen, noch dazu vollkommen kostenlos und sogar mit OO-Ansatz:
> LunaAVR.

Kenne ich, ich helfe Richard da ab und zu etwas mit (Testen etc).

Mit Luna habe ich die ersten Gehversuche gemacht, Richard hat mich
auch dazu gebracht mich wieder mit uCs zu beschäftigen.

Luna ist ideal für die ersten Experimente und für Anfänger.

Mich engt es ein, es fehlen genau diese Includefiles, die Syntax
kann ich nicht ab, es fehlt einfach die Präzision wie ich sie von
C her kenne.

Ich glaube auch nicht, daß Luna "einfacher" wie C ist. Prinzipiell
kann ich am Anfang einfacher Unkenntnis der Hardware überdecken, das
relativiert sich dann aber. Die ersten Erfolgserlebnisse hat man
mit Luna definitiv VIEL schneller wie bei C.

PS: Ich habe mal mit eingetippten Hexcodes angefangen, Assembler,
C, GWBASIC würg, dBASE, PHP etc.

C ist wie ein klarer Schnaps, ehrlich und kernig und dabei transparent.
BASIC wie zuckersüßes Likörchen ("Schlüpferstürmer").

Sebastian Heyn schrieb:
> In einem anderen Forum wurde mal der erzeugte Code von C und Bascom
> zerpflückt. Resultat war, dass C oftmals mehr Anweisungen und damit CPU
> zeit verbraucht als Bascom.
Zeig mal den Link.

Gruß Oliver

In unserer Fa. bin ich für die Hardware zuständig.
Wenn der erste Prototyp gelötet ist brauche ich mit Bascom meist keinen 
halben Tag um alle Funktionen zu testen.
Danach bekommts der C- ler, der soll sich dann damit abplagen.

Duplo schrieb:
> Wenn es mit der zunehmenden Komplexität der MCs so weiter geht (siehe
> XMegas), reicht C in dieser Form nicht mehr aus. Es sei denn, man ist
> Masochist oder die Entwicklungszeit spielt keine Rolle.

Was hat die komplexitaet eines uC mit der Programmiersprache zu tun?
Nichts.

Den die Peripherie eines uC spricht man mit den dafuer erstellten 
Bibliotheken an. Und diese muessen egal in welcher Sprache auch immer 
erstmal erstellt werden. Das die in Bascom teilweise in rudimentaerer 
Form dabei sind hat erstmal nichts mit der Sprache an sich zu tun. Hat 
dann die vorhandene Funktion dann nicht die gewuenschte Eigenschaft dann 
stehen doch die meisten Bascom Programmierer erstmal auf dem Schlauch.

Wenn man sich um die Libs nicht zu stoeren braucht dann kann ich auch in 
5 Minuten ein C Programm auf einen x-beliebigen Controller am laufen 
bringen.

Man muss klar unterscheiden was macht die Sprache aus und was sind 
Bibliotheksfunktionen. Und das ist nunmal in C klar unterschieden. Die 
Sprache C kennt an sich keine Ein/Ausgabefunktionen. Die sind alle in 
Biblioteken enthalten.

Und von der Komplexitaet ist eine PC-CPU sammt Peripherie wohl 
wesentlich aufwendiger als ein uC. Und trotzdem kann man ihn in C/C++ 
einfach programmieren.

Dazu kommt noch, daß der C-Source-Code vieler libs frei verfügbar ist.
Ist da einen Macke drin kann ich (wenigstens theoretisch) etwas
machen.

(zB SQLite)

Yalu X. schrieb:
>
> Autsch! Das ist ja ein geradezu perfektes Paradebeispiel dafür, wie man
> Gotos nicht benutzen sollte. Warum schreibst du nicht einfach

Ja, das ist das Problem wenn man zu später Stunde einfach irgendetwas 
aus dem Netz hinrotzt ohne das Hirn einzuschalten.
Dann halt mal ein reales Beispiel aus der eigenen Feder:

static int __devinit device_init( struct pci_dev *dev, const struct pci_device_id *id ) {

#ifdef DEBUG
 printk( KERN_INFO "%s: Start initialize hardware\n", DRIVER_NAME );
#endif

 if ( dev == NULL ) {
  printk( KERN_ERR "%s: Hardware not found\n", DRIVER_NAME );
  goto cleanup;
 };

 if ( id == NULL ) {
  printk( KERN_ERR "%s: Hardware ID not found\n", DRIVER_NAME );
  goto cleanup;
 };

 // PCI device initialising (wake up from suspend, etc.)
 if ( pci_enable_device( dev ) != 0 ) {
  printk( KERN_ERR "%s: Device not enabled\n", DRIVER_NAME );
  goto cleanup;
 };

#ifdef DEBUG
 printk( KERN_INFO "%s: Device enabled\n", DRIVER_NAME ); 
#endif

 // Get Address of BARs.
 bar0.start = pci_resource_start( dev, 0 );
 if ( bar0.start < 0 ) {
  printk( KERN_ERR "%s: BAR0 address not set\n", DRIVER_NAME );
  goto cleanup;
 };

#ifdef DEBUG
 printk( KERN_INFO "%s: BAR0 address: %X\n", DRIVER_NAME, (unsigned int) bar0.start );
#endif

 // Get Size of BARs.
 bar0.len = pci_resource_len( dev, 0 );
 if ( bar0.len < 0 ) {
  printk( KERN_ERR "%s: BAR0 size not set\n", DRIVER_NAME );
  goto cleanup;
 };

#ifdef DEBUG
 printk( KERN_INFO "%s: BAR0 size: %d\n", DRIVER_NAME, (unsigned int) bar0.len );
#endif

 // Get Flags of BARs & testing resourcetypes
 bar0.flags = pci_resource_flags( dev, 0 );
 if ( !( ( bar0.flags & IORESOURCE_MEM ) ) ) {
  printk( KERN_ERR "%s: BAR0 is not Memory-type\n", DRIVER_NAME );
  goto cleanup;
 };

 // Request IRQ from OS.
 // IRQF_SHARED | IRQF_SAMPLE_RANDOM
 if ( request_irq( dev->irq, device_isr, IRQF_DISABLED/*|IRQF_SHARED*/, DRIVER_NAME, dev ) ) {
  printk( KERN_ERR "%s: Unable to allocate IRQ %d\n", DRIVER_NAME, dev->irq );
  goto cleanup;
 };

#ifdef DEBUG
 // Get (remapped) IRQ from pci_dev structure.
 printk( KERN_INFO "%s: IRQ: %d allocated\n", DRIVER_NAME, dev->irq );
#endif

 // Remap the physical address into virtual address space
 bar0.v_start = ioremap( bar0.start, bar0.len );
 if ( !bar0.v_start ) {
  printk( KERN_ERR "%s: Could not remap memory of BAR0\n", DRIVER_NAME );
  goto cleanup_irq;
 };

#ifdef DEBUG
 printk( KERN_INFO "%s: BAR0 virtual address: %X\n", DRIVER_NAME, (unsigned int) bar0.v_start );
#endif

 // Try to gain control of hardware.
 if ( request_mem_region( bar0.start, bar0.len, DRIVER_NAME ) == NULL ) {
  printk( KERN_ERR "%s: Memory of BAR0 is in use\n", DRIVER_NAME );
  goto cleanup_remap;
 };
 // gStatFlags |= HAVE_REGION;

 buffer_key = kmalloc( BLOCK_SIZE, GFP_KERNEL );
 if ( buffer_key == NULL ) {
  printk( KERN_ERR "%s: Unable to allocate key buffer\n", DRIVER_NAME );
  goto cleanup_remap;
 };

 buffer_read  = kmalloc( BLOCK_SIZE, GFP_KERNEL );
 if ( buffer_read == NULL ) {
  printk( KERN_ERR "%s: Unable to allocate read buffer\n", DRIVER_NAME );
  goto cleanup_readbuffer;
 };

 buffer_write = kmalloc( BLOCK_SIZE, GFP_KERNEL );
 if ( buffer_write == NULL ) {
  printk( KERN_ERR "%s: Unable to allocate write buffer\n", DRIVER_NAME );
  goto cleanup_writebuffer;
 };

#if 0
 buffer_key = pci_alloc_consistent( dev, BUF_SIZE, &HWKeyAddr );
 if ( buffer_key == NULL ) {
  printk( KERN_ERR "%s: Unable to allocate key buffer\n", DRIVER_NAME );
  goto cleanup_remap;
 };

#ifdef DEBUG
 printk( KERN_INFO "%s: Key buffer allocation %X->%X\n", DRIVER_NAME, ( unsigned int ) buffer_read, ( unsigned int ) HWReadAddr );
#endif

 buffer_read = pci_alloc_consistent( dev, BUF_SIZE, &HWReadAddr );
 if ( buffer_read == NULL ) {
  printk( KERN_ERR "%s: Unable to allocate read buffer\n", DRIVER_NAME );
  goto cleanup_readbuffer;
 };

#ifdef DEBUG
 printk( KERN_INFO "%s: Read buffer allocation %X->%X\n", DRIVER_NAME, ( unsigned int ) buffer_read, ( unsigned int ) HWReadAddr );
#endif

 buffer_write = pci_alloc_consistent( dev, BUF_SIZE, &HWWriteAddr );
 if ( buffer_write == NULL ) {
  printk( KERN_ERR "%s: Unable to allocate write buffer\n", DRIVER_NAME );
  goto cleanup_writebuffer;
 };

#ifdef DEBUG
 printk( KERN_INFO "%s: Write buffer allocation %X->%X\n", DRIVER_NAME, ( unsigned int ) buffer_write, ( unsigned int ) HWWriteAddr );
#endif
#endif

#ifdef DEBUG
 printk( KERN_INFO "%s: Initialize hardware done\n", DRIVER_NAME );
#endif

 return 0;

cleanup_writebuffer:
 kfree( buffer_read );
 buffer_read = NULL;
cleanup_readbuffer:
 kfree( buffer_key );
 buffer_key = NULL;
cleanup_remap:
 iounmap( bar0.v_start );
cleanup_irq:
 free_irq( dev->irq, DRIVER_NAME );
cleanup:
 printk( KERN_ERR "%s: Initialize hardware failed\n", DRIVER_NAME );

 return -ENODEV;
}

Tim T. schrieb:
> Dann halt mal ein reales Beispiel aus der eigenen Feder:

Manchmal geht es nicht ohne (und macht ein Programm übersichtlicher).

GOTO war halt in Basic schon immer für Anfänger attraktiv und
hat sich so irgendwie festgesetzt, nebenbei gibt es in Assembler
auch Jumps. In BASIC führt es aber regelmäßig zu Spaghetticode.

Ich sollte mal so ein Spaghetti-Basic-Teil sanieren, es war nicht
mehr möglich. Neuschreiben in C brachte einen Performancegewinn
Faktor 2000 (!). Ohne goto (ok, war GWBASIC).

Das ist echtes Popcorn Kino hier.
Der erste Basicfreak sagt: Basic ist die Mutter aller 
Programmiersprachen.
Sag mir doch mal wie alt IBM Assembler ist, wie alt Cobol, ...

Der nächste Basicfreak sagt: C ist schon 40 Jahre alt, kann also nix 
mehr taugen.
Wann wurde im Commodore 4008 Basic ins ROM gebrannt? War das überhaupt 
der erste?

Der dritte bringt ein C Beispiel für Goto vor das ihm in 5 Minuten als 
lausiger Code zerplückt wird und gibt dann zu das habe er ja auch aus 
dem Internet "hingerotzt".

Leute Leute, damit beweist ihr nur eines, nämlich eure geballte 
Inkompetenz.
Zum Glück gibt es auch Basic Programmierer die sowas nicht nötig haben.

Eine Frage:

In welcher Sprache wurde eigentlich Bascom geschrieben?

Joachim Drechsel schrieb:
>
> Manchmal geht es nicht ohne (und macht ein Programm übersichtlicher).
Es geht immer ohne, wird nur beliebig unübersichtlich.

> GOTO war halt in Basic schon immer für Anfänger attraktiv und
> hat sich so irgendwie festgesetzt, nebenbei gibt es in Assembler
> auch Jumps. In BASIC führt es aber regelmäßig zu Spaghetticode.

Habe auch mit Basic auf einem C64 das Programmieren angefangen, 
allerdings bin ich nie mit der Sprache warm geworden. Das war später mit 
Pascal und C was ganz anderes. Dort wurde man irgendwie zu besserem Code 
gezwungen.
Bei Assembler fehlt mir für größere Sachen einfach der Gesamtüberblick, 
brauche dafür zu viel Papier um den ganzen Kram nachzuhalten und es geht 
dem Gefühl nach dann auch in Richtung Spaghetticode.

> Ich sollte mal so ein Spaghetti-Basic-Teil sanieren, es war nicht
> mehr möglich. Neuschreiben in C brachte einen Performancegewinn
> Faktor 2000 (!). Ohne goto (ok, war GWBASIC).

Nicht das ich Basic hier in Schutz nehmen will, aber sowas kann einem 
bei allen Programmiersprachen begegnen.

Ich habe zwar nicht alle Postings gelesen...aber ich kann nur soviel 
sagen, weil ich keine Ahnung habe und ich weiss nicht was ich tue, das 
ich auch seit einem Jahr Bascom benutze und mit 0 Programmierkenntnisse 
gestartet habe, daß meine RGBs faden, Leds blinken und die Uhren 
ticken...

Ich weiss nicht ob man das Ohmsches Gesetz ißt oder trinkt...und damit 
habe für einigen einen Gefallen getan. Freut mich.

duplo schrieb:
> Wenn ich mir als Assembler und C Fan
Und ich bin Fußballfan. Aber zum selber kicken reicht es nur für den 
Kartoffelacker. Da ist natürlich die Allianz-Arena dran schuld.

mfg.

Udo Schmitt schrieb:
> Leute Leute, damit beweist ihr nur eines, nämlich eure geballte
> Inkompetenz.
Was würde denn in so einem Thread Kompetenz ausdrücken? Fürs allgemeine 
Blafasel bei diesem Thema reicht minimale Restaktivität aus, eventuell 
gibts bald mal ein Bot dafür (in BASIC oder so) geschrieben. Ein Namen 
hätte ich auch schon dafür BBB - Bascom Bashing Bot.

> Zum Glück gibt es auch Basic Programmierer die sowas nicht nötig haben.
Nö, die haben ja bald ihren Bot.

>
> Eine Frage:
>
> In welcher Sprache wurde eigentlich Bascom geschrieben?
Vom Aussehen her würde ich auf Delphi tippen.

Duplo schrieb:
> Mir kommt vor, dass die Bascom Befürworter etwas mehr Weitsicht haben,
> als die C Progger Freaks,

Wie kommst du denn darauf?

Weitsicht bzgl. der Hardwareplattform führt weg von Bascom, da die
Mikrocontrollerwelt ja nicht nur aus AVRs besteht.

Weitsicht bzgl. des beruflichen Werdegangs führt ebenfalls weg von
Bascom, da dieses fast nirgends in der Industrie eingesetzt wird.

> die zwanghaft an dem 40 Jahre alten C festhalten wollen.

Naja, Basic ist noch 8 Jahre älter :)

> Wenn es mit der zunehmenden Komplexität der MCs so weiter geht (siehe
> XMegas), reicht C in dieser Form nicht mehr aus. Es sei denn, man ist
> Masochist oder die Entwicklungszeit spielt keine Rolle.

Hmm, C hat sogar für noch sehr viel komplexere Hardware als die XMegas
ausgereicht.

Falls auch die Anwendungen deutlich komplexer und größer werden, kann
man ja darüber nachdenken, auf einen der Nachfolger von C (C++, D, Java,
C# ...) umzusteigen. Mit "deutlich komplexer und größer" meine ich hier
aber Anwendungen, die weit jenseits der Möglichkeiten eines AVR oder
XMega liegen, so dass sich die Frage, ob Bascom oder nicht, sowieso
nicht mehr stellt.

Ich möchte aber Bascom keinem madig machen. Jeder sollte das benutzen,
wo er denkt, dass er damit am weitesten kommt.


Tim T. schrieb:
> Dann halt mal ein reales Beispiel aus der eigenen Feder:

Ja, das sieht schon deutlich mehr nach sinnvollen Gotos aus. Gotos sind
vor allem dort sinnvoll, wo von verschiedenen Stellen in verschachteltem
Code das gleiche Ziel angesprungen werden soll (typisch in Fehlerbehand-
lungen). Bei deinem neuen Beispiel ist dieses Ziel das Label cleanup. In
deinem ersten Beispiel war dieser Fall nicht gegeben.

Thomas der Bastler schrieb:
> Ich weiss nicht ob man das Ohmsches Gesetz ißt oder trinkt...und damit
> habe für einigen einen Gefallen getan. Freut mich.

Dunkel deiner Rede Sinn ist...

Tim T. schrieb:
> Thomas der Bastler schrieb:
>> Ich weiss nicht ob man das Ohmsches Gesetz ißt oder trinkt...und damit
>> habe für einigen einen Gefallen getan. Freut mich.
>
> Dunkel deiner Rede Sinn ist...

Thomas ist glaube ich stolz darauf, daß er trotz diversen netten und 
auch weniger netten Hinweisen sich immer noch erfolgreich dagegen wehrst 
absolute Grundlagen zu lernen.

Yalu X. schrieb:
> Ja, das sieht schon deutlich mehr nach sinnvollen Gotos aus. Gotos sind
> vor allem dort sinnvoll, wo von verschiedenen Stellen in verschachteltem
> Code das gleiche Ziel angesprungen werden soll (typisch in Fehlerbehand-
> lungen). Bei deinem neuen Beispiel ist dieses Ziel das Label cleanup. In
> deinem ersten Beispiel war dieser Fall nicht gegeben.

Im wesentlichen wird goto immer im gleichen Konstrukt verwendet, um aus 
einer Funktion herauszuspringen und dabei alle bis dahin durchgeführten 
Initialisierungen wieder rückgängig zu machen. Ohne gotos wären die 
Deinitialisierungen entweder redundant vorhanden und bei Änderungen 
würde immer etwas vergessen zu ändern oder es wären sehr 
unübersichtliche Schleifenkonstrukte erforderlich.

Yalu X. schrieb:
> Lueger schrieb:
>> Basic war und ist sehr gut und die Mutter aller Programmiersprachen.
>
> Nein, das ist Lisp :)

Das ist FORTRAN, Ihr Noobs. ;-)

Tim T. schrieb:
> Im wesentlichen wird goto immer im gleichen Konstrukt verwendet, um aus
> einer Funktion herauszuspringen und dabei alle bis dahin durchgeführten
> Initialisierungen wieder rückgängig zu machen. Ohne gotos wären die
> Deinitialisierungen entweder redundant vorhanden und bei Änderungen
> würde immer etwas vergessen zu ändern oder es wären sehr
> unübersichtliche Schleifenkonstrukte erforderlich.

Na ja eine Dummy Schleife mit break und dann am Ende alle Zeiger die 
NICHT mehr null sind entsprechend freigeben ist absolut nicht 
unübbersichtlich.
Trotz allem ist das eine absolut legitime GOTO Anwendung, in Basic und 
in C.

In moderneren Sprachen benutzt man Konstrukte wie try ... finally

Joachim Drechsel schrieb:
> Mich engt es ein, es fehlen genau diese Includefiles, die Syntax
> kann ich nicht ab, es fehlt einfach die Präzision wie ich sie von
> C her kenne.

wo du aber ehrlich sein musst ist, dass es zum Großteil aber auch an der 
eigenen Abneigung liegt. Technisch gesehen, ist es mit dieser Sprache 
möglich so präziese zu sein wie mit C. Includes sind ebenso vorhanden 
wie Strukturen usw. Bedenke das der Entwickler hier offensichtlich viele 
hilfreiche Ausdrücke verschiedener Sprachen implemeniert hat. Der 
einfachste Beispiel ist das praktische Bitshiften mit << und >>, wobei 
das sogar mit Variablen funktioniert.

> Ich glaube auch nicht, daß Luna "einfacher" wie C ist. Prinzipiell
> kann ich am Anfang einfacher Unkenntnis der Hardware überdecken, das
> relativiert sich dann aber. Die ersten Erfolgserlebnisse hat man
> mit Luna definitiv VIEL schneller wie bei C.

Meine persönliche Meinung dazu ist: es fehlen hier und dort noch kleine 
Ecken, im Großen und Ganzen muss ich aber meine Hochachtung aussprechen. 
Der erzeugte Code ist eine sinnvolle Kombination aus Geschwindigkeit und 
Codegröße, die Syntax ist leicht verständlich, der OO-Ansatz ist eine 
sinnvolle Mischung aus prozedual und objektorientiert und die IDE ist 
praktikabel, flink und übersichtlich. Wenn ich C nicht mag, würde ich 
diese Sprache wählen.

Ich muss im Übrigen gestehen, das ich ein fast militanter 
Assembler-Programmierer bin, erwische mich jedoch seit dem Erscheinen 
von Luna neuerdings überproportional oft bei der Verwendung derselben.

Wenn, wie Frank sagt, möglicherweise auch zukünftig eine MacOS-Version 
erscheinen sollte, dürfte das ziemlig einmalig sein. Die armen Mac-User 
haben da keine sonderlich große Auswahl.

Ehrhardt

Jetzt nicht speziell an Yalu, ich möchte nur den Faden aufgreifen

>> Wenn es mit der zunehmenden Komplexität der MCs so weiter geht (siehe
>> XMegas), reicht C in dieser Form nicht mehr aus. Es sei denn, man ist
>> Masochist oder die Entwicklungszeit spielt keine Rolle.
>
> Hmm, C hat sogar für noch sehr viel komplexere Hardware als die XMegas
> ausgereicht.

Hier werden doch Äpfel mit Birnen verglichen.

Was ist denn das Tolle an BASCOM? Doch nicht die Sprache an sich. Was 
mir sauer aufstösst, ist zb das man Expressions auf mehrere Zeilen 
aufdröseln muss. Das hat zwar gewisse Vorteile wenn es um die Frage der 
Operator-Reihenfolge bzw. automatische Konversionen geht (wie man im 
Forum sieht: ein Dauerbrenner), hat man diesen Themenkreis in C aber 
erst mal intus, dann ist es kein Problem mehr. Nichts desto Trotz kann 
ich in BASCOM keine 'komplexeren' Expressions in einer Zeile schreiben.

(OK, die IDE könnten sie auch mal ein wenig pimpen. Automatische 
Einrückung würde vielen Programmen guttun.
Dem Syntaxparser kann seine Vergangenheit des zeilenweisen 
Syntaxcheckens auch nicht verleugnen und ist daher keine große Hilfe, 
wenn es um strukturierte Progammierung geht.
etc. etc. In Summe aber: alles nicht so wild.
)


Nein, das Tolle an BASCOM ist, dass es die Hardware der AVR (und nicht 
nur die) in weitgehend abstrahierter Form als Sprachkonstrukt zur 
Verfügung stellt. Und soweit ich weiß, kann man an dieser Stelle die 
"Sprache" auch noch mit externen Komponenten pimpen. GLCD wurden meines 
Wissens so eingebunden.

Das alles hat den Vorteil, dass sich Neulinge erst mal um viele Dinge 
nicht kümmern müssen.
Aber: Das ist kein Vor- oder Nachteil für C. Wenn es gelingen würde, 
eine Standard-'Lib' zusammenzustellen, in der ebenfalls für die 
häufigsten Anwendungsfälle fertige Codemodule zur Verfügung stehen, dann 
ist man mit C genauso schnell wie mit BASCOM, was das Hochziehen einer 
App angeht.

Das wir diese Codemodule nicht haben hat keine technischen Gründe 
sondern ist ein Politikum. 30 oder 40 Programmierer kriegst du nun mal 
nicht unter einen Hut ohne dass es zu Kompetenzgerangel kommt, weil 
jeder seine Lösung als die bessere ansieht, die allen anderen überlegen 
ist. (Und wie man an BASCOM sieht, ist es gar nicht sooo wichtig, immer 
die allerbeste Lösung zu haben. EINE Lösung die zuverlässig ist, würde 
schon reichen)

Da hat es BASCOM ein wenig leichter. Die gibt es 1 Firma und die macht 
die Vorgabe.

Ach, und noch was.

Hütet euch bitte auch davor, dass was wir hier im Forum von BASCOM bzw. 
an BASCOM-Fragen sehen, als symptomatisch anzusehen.
Was wir hier mitkriegen, stammt zum großen Teil von Leuten, für die eine 
Aufforderung doch mal in die Hilfe zu sehen, schon fast einer 
'Einschränkung der persönlichen Freiheit' gleichkommt. Was natürlich 
kategorisch abgelehnt wird.

Ehrhardt Balstein schrieb:
> Wenn, wie Frank sagt, möglicherweise auch zukünftig eine MacOS-Version
> erscheinen sollte, dürfte das ziemlig einmalig sein. Die armen Mac-User
> haben da keine sonderlich große Auswahl.

Frank ? Ich dachte, Richard ...

Na klaro, wenn man im Leben noch nichts anderes programmiert hat, als 
ein Lauflicht dann kommt einem jede Sprache dafür gut genug vor. Es geht 
nicht um die trivialen Konstrukte. eine for schleife ist eine for 
schleife, egal wie man das in C oder BASIC schreibt. Und das Bascom für 
die AVRs eine große lib mitbringt ist ja schön, sagt aber über die 
Sprache halt nix aus.

Ich gebe zu,  Bascom im speziellen kenne ich nicht sehr gut. Lerne aber 
gerne dazu. Also schauen wir uns doch mal zwei Beispiele an:

1.)
Gibt es in BASCOM die möglichkeit, eine Referenz auf eine Funktion zu 
übergeben? Also eine sog. Callback Funktion zu implementieren? Und wie 
sieht das dann aus? Falls BASCOM OO kann, ist die Antwort natürlich 
einfach. C kann kein OO, aber dafür gibts Funktionspointer.

In einem aktuellen Projekt benötige ich eine Callback Funktion. Eine lib 
verrichtet ihren Dienst, und muss ab und zu, bei speziellen Kommandos 
die Kontrolle abgeben.

In der lib sieht das so aus:

void mb_setCommandCallback(void (*commandReceived)(uint8_t));

Das Programm welches die lib verwendet macht das so:

void special_mb_command(uint8_t cmd) {
 //Tu was
}

int main() {
  mb_setCommandCallback(&special_mb_command);
}

2.)
In C kann man alle Datenstrukturen gleich behandeln. Das ist wichtig, 
wenn man sie z.B. lediglich Byteweise speichern oder lesen oder 
versendet/empfangen möchte. Ich will nicht jede Variable einzeln 
behandeln, ich will den ganzen Haufen nehmen und einfach byte für byte 
was damit machen.

Ein Gerät kann via PC parametrisiert werden. Dazu gibt es einige Config 
Variablen, welche in einem Struct (Config_t) stecken.

Die Funktionen zum lesen und schreiben des struct aus und in den eeprom 
halten sich in Grenzen:

void loadConfig() {
  eeprom_read_block(&cfg,&config_ee,sizeof(Config_t));
}

void saveConfig() {
  eeprom_write_block(&cfg,&config_ee,sizeof(Config_t));
}

Ähnlich kompakt sind die Funktionen zum senden und empfangen der Config 
via serielle Schnittstelle. Man beachte dass hierbei das struct selber 
imd die darin definierten Variablen, gar keine Rolle spielen. Eine 
Änderung des structs, zieht keine Änderung in den genannten Funktionen 
nach sich.

Wie sehen die Korrespondierenden Lösungen in BASCOM aus?

gruß cyblord

Karl Heinz Buchegger schrieb:
> Aber: Das ist kein Vor- oder Nachteil für C. Wenn es gelingen würde,
> eine Standard-'Lib' zusammenzustellen, in der ebenfalls für die
> häufigsten Anwendungsfälle fertige Codemodule zur Verfügung stehen, dann
> ist man mit C genauso schnell wie mit BASCOM, was das Hochziehen einer
> App angeht.

Ich würde so eine "Standard-Lib" in C auch sehr begrüßen, wäre sofort 
bei der Entwicklung mit dabei, wenn sich noch eine Handvoll anderer 
Leute beteiligen würden.

> Das wir diese Codemodule nicht haben hat keine technischen Gründe
> sondern ist ein Politikum. 30 oder 40 Programmierer kriegst du nun mal
> nicht unter einen Hut ohne dass es zu Kompetenzgerangel kommt, weil
> jeder seine Lösung als die bessere ansieht, die allen anderen überlegen
> ist.

Das sehe ich als kleineres Problem an. Als damaliger Gründer des 
fli4l-Projekts kann ich dazu nur sagen, dass es einen geben muss, der 
das Grobkonzept vorgibt und bei Streitfragen entscheidet und dessen 
Meinung von allen anderen akzeptiert und mitgetragen wird. Dann klappt 
das schon. Beim fli4l-Projekt hat das sogar mit bis zu 70 (Haupt- und 
Neben-)Entwicklern funktioniert. Jeder im Team findet seine Nische, wo 
er sich austoben kann.

Gruß,

Frank

Joachim Drechsel schrieb:
> Ehrhardt Balstein schrieb:
>> Wenn, wie Frank sagt, möglicherweise auch zukünftig eine MacOS-Version
>> erscheinen sollte, dürfte das ziemlig einmalig sein. Die armen Mac-User
>> haben da keine sonderlich große Auswahl.
>
> Frank ? Ich dachte, Richard ...

der Beitrag stammt von einem Frank, ich nehme an ein Mac-User der das in 
Zuammenarbeit testet

cyblord ---- schrieb:

> Wie sehen die Korrespondierenden Lösungen in BASCOM aus?
>

Ok, die EPROM Sache ist jetzt nicht so speziell, ist in BASCOM aber auch 
kein Showstopper. Dort brauchst du keine eeprom_read_xxx Funktionen. Du 
markierst die Variable als 'im EEPROM' und gut ists.

Die andere Sache, das musst du selber auch zugeben, ist dann schon etwas 
speziell. Weil du das eben so brauchst.
Ich behaupte aber mal: Viele Programme brauchen solche Dinge gar nicht. 
Um mit einem Tiny 2 RC-Signale zu mischen und wieder auf einen 
Servoausgang zu legen, ist das alles nicht notwendig. Mit BASCOM ist das 
trivial machbar (wenn auch nicht unbedingt optimal). Da hat dein 
AVR_Studio noch nicht mal fertig gebootet, brennt der BASCOM Jünger 
schon den Tiny. Muss man neidlos anerkennen.
Und viele Programme sind in dieser Komplexitäts-Kategorie.

BASCOM ist für mich wie ein Letherman. Klar: die 12 verschiedenen 
Schraubendreher in der Werkstatt sind was anderes als die beiden am 
Letherman. Klar, mit der Säge am Letherman wirst du ausser kleinen 
Stücken nicht viel schneiden können, und die Feilen sind kein wirklicher 
Ersatz für den Satz Schlüsselfeilen zu Hause. Aber trotzdem ist ein 
Letherman nützlich, wenn man sich darauf besinnt, wozu er gedacht ist, 
was er kann und wo seine Grenzen liegen.

Karl Heinz Buchegger schrieb:
> Ok, die EPROM Sache ist jetzt nicht so speziell, ist in BASCOM aber auch
> kein Showstopper. Dort brauchst du keine eeprom_read_xxx Funktionen. Du
> markierst die Variable als 'im EEPROM' und gut ists.

Das speichern im eeprom war ein Beispiel. Es geht NICHT um das schreiben 
ins eeprom. Ausserdem, wie sieht das in Bascom aus? Definiert man da 
eine oder zwei Variablen? Also eine fürs Ram und eine für den EEPROm? 
Und wie kontrolliert man wann ins eeprom geschrieben oder gelesen wird? 
Ich möchte ja vielleicht nicht sofort alles im eeprom haben.
Wie siehts mit dem versenden/empfangen aus? Also mit dem Byteweisen 
Zerpflücken? Und vorallem das gruppieren via struct? Zig Einzelvariablen 
sind nicht so übersichtlich...

Config_t cfg;

void sendConfig() {
  for (int i=0;i<sizeof(Config_t);i++) {
    send(((uint8_t*)&cfg)[i]);
  }
}

Vorallem was wenn man mehrere Konfig-Profile braucht? Dann reicht es 2x 
Variablen vom Typ Config_t anzulegen. In Bascom???

typedef struct Config {
  uint8_t var1;
  uint16_t var2;
  char[10] string;
  uint16_t[15] varArray;
} Config_t;

Config_t config1;
Config_t config2;

> Die andere Sache, das musst du selber auch zugeben, ist dann schon etwas > 
speziell
Naja, also das übergeben von Funktionen als Parameter braucht man schon 
öfters. Ist wie gesagt bei OO eigentlich standard, nur das siehts anders 
aus.
Ausserdem las ich hier durchgehend, dass mit Bascom alles gehen würde, 
was mit C auch geht. Ich las wenig davon dass Bascom beschränkt aber 
einfach ist.

gruß cyblord

cyblord ---- schrieb:

Zum Thema 'Config'.
Keine Ahnung. Bin kein BASCOM Spezialist.
Ich habs ein paar mal gestartet, ein wenig damit gespielt und das wars 
dann auch.
>> Die andere Sache, das musst du selber auch zugeben, ist dann schon etwas >
> speziell
> Naja, also das übergeben von Funktionen als Parameter braucht man schon
> öfters.

Du brauchst das.
Derjenige, der einen Ersatz für die Steuerung seiner Waschmaschine 
braucht, braucht das nicht.

Versteh mich nicht falsch: Ich sag ja nicht, dass du da jetzt hohe 
Anforderungen stellst. Ich behaupte lediglich: die Mehrzahl der Leute, 
die mit BASCOM arbeiten verspüren gar nicht den Drang dazu, sowas zu 
machen. Sie brauchen es für ihre Projekte schlicht und ergreifend nicht. 
Für den ist viel wichtiger, dass sein LCD aus dem Stand heraus 
funktioniert und er mit 2 Tasten die Vorgabetemperatur für die 
Gewächshausheizung, die er mit PWM anspricht, ändern kann. Und das alles 
in weniger als 20 Zeilen Code.

> Ausserdem las ich hier durchgehend, dass mit Bascom alles gehen würde,
> was mit C auch geht. Ich las wenig davon dass Bascom beschränkt aber
> einfach ist.

Ist es aber. Dessen muss man sich bewusst sein.
BASCOM ist keine Universalsprache sondern speziell auf die Bedürfnisse 
von Leuten abgestimmt, die µC programmieren. Alles andere wurde 
abgespeckt. Wie gut es sich für größere Projekte eignet kann ich mangels 
Erfahrung nicht beurteilen. Aber für kleinere Dinge ist es gar nicht mal 
so schlecht.

Danke Karl Heinz, ich seh das ähnlich wie du.

Dazu kommt aber noch, dass eben jemand der noch nie richtig programmiert 
hat, die Beschränktheit von Bascom gegenüber C gar nicht erkennt, aber 
dafür immer schön draufhaut und sich lautstark fragt, wozu man das 
uralte doofe C denn braucht. Und genau das ärgert mich.

Eventuell meldet sich ja noch ein BASCOM Programmierer und kann anhand 
des Config Szenarios mal eine Lösung in BASCOM vorstellen? Ich wundere 
mich ja schon ein wenig, bei allgemeinen Statements da oben reißt jeder 
das Maul auf, aber wenns EINMAL sachlich und konkret wird, dann kommt 
nix mehr.

gruß cyblord

Ich klinke mich mal einfach ein, mche vieles mit Bascom, ohne jetzt der 
Vollprofi zu sein.

Was das Zerpflücken von Strings oder anderen variablen in Bytes angeht, 
so geht das supereinfach.

Dim beliebiger_string as string *20
dim einzelne_bytes (20) as byte at beliebiger_string overlay

man kann nun mit dem String verfahren wie man will, hineinschreiben, 
herauslesen, left, right, mid etc. alles machbar. Braucht man n 
einzelnes Byte kann man das einfach bfragen als einzelne_bytes(x).

Geht genauso mit Word oder Single Variablen, dann einfach 2 Bytes bzw. 4 
Bytes deklarieren.

Funktionen mit Rückgabewert gibts natürlich auch ...

declare function irgendeine_funktion (byval / byref 
Wert_zur_funktion_hin as word) as single

function irgendeine_funktion (Wert_zur_funktion_hin)
local local_single as single

local_single = Wert_zur_funktion_hin*10
irgendeine_funktion = local_single
end function

Aufruf z.B. durch

Singlevariable = irgendeine_funktion(10)


EEPROM-Zugriffe gehen supereinfach, auch als eindimmensionales Array ...

dim eepromvariable (10) as eram byte

äquivalent gehts klaro auch mit word, single etc.

Aufruf einfach per

eepromvariable(1) = xy

cyblord ---- schrieb:
> Es geht NICHT um das schreiben
> ins eeprom. Ausserdem, wie sieht das in Bascom aus? Definiert man da
> eine oder zwei Variablen? Also eine fürs Ram und eine für den EEPROm?
> Und wie kontrolliert man wann ins eeprom geschrieben oder gelesen wird?
> Ich möchte ja vielleicht nicht sofort alles im eeprom haben.
> Wie siehts mit dem versenden/empfangen aus? Also mit dem Byteweisen
> Zerpflücken? Und vorallem das gruppieren via struct? Zig Einzelvariablen
> sind nicht so übersichtlich...

ich weiß jetzt nicht wie es in bascom funktioniert, in luna kann man 
Strukturen nutzen, Beispiel Eeprom:

eeprom hallo
  .db 100,200
  .dw &h4711
  .db 5,"hallo"
endeeprom

Zugriff über die Objektfunktionen:

 a = hallo.ByteValue(1)
 s = hallo.PString(4)

Im Arbeitsspeicher (aus den Examples):

struct point
  byte x
  byte y
endstruct

dim p(3) as point

p(0).x = 10
p(0).y = 20

Man sieht also, wenn man nicht weiß welche Möglichkeiten eine Sprache 
speziell bietet, wird das oft zu schnell abgetan.

Gruß, Ehrhardt

Fhutdhb Ufzjjuz schrieb:
> EEPROM-Zugriffe gehen supereinfach, auch als eindimmensionales Array ...

Dann wird man wohl sehr schnell die Schreibzyklenanzahl überschritten 
haben, wenn man einfach so drauf los schreibt.

In C ist daher die übliche EEPROM-Nutzung, man legt eine beliebig 
komplexe Struct (int, float, char* usw.) im SRAM an. Nach dem Reset wird 
über den EEPROM eine CRC geprüft und dann in diese Struct kopiert.
Dann wir damit gearbeitet. Und nur auf Nutzeranforderung oder bei 
Power-Fail-Erkennung wird zurück geschrieben.
Bei größeren Datensätzen erfolgt das im Interrupt, damit andere Prozesse 
nicht lange blockiert werden.

Der EEPROM wir daher nicht ständig verschliessen, wie es aber bei 
Gleichbehandlung mit SRAM der Fall wäre.

Ich habe auch einige kommerzielle Geräte, die sich nichts mehr merken 
können. Vermutlich hat auch da der Programmierer die Schreibzyklenzahl 
nicht beachtet.

Hier mal ein Beispiel:

#include <avr/io.h>
#include "eeprom.h"


#define EE_ADDR 1


struct{
  uint32_t p0;
  float p1;
  int16_t p2;
  uint8_t p3;
}eeprom_data;



int main( void )
{
  eeprom_read( &eeprom_data, EE_ADDR, sizeof(eeprom_data) );

  eeprom_data.p0++;

  eeprom_write( EE_ADDR, &eeprom_data, sizeof(eeprom_data) );

  for(;;){
  }
} 

Peter

Fhutdhb Ufzjjuz schrieb:
> declare function irgendeine_funktion (byval / byref
> Wert_zur_funktion_hin as word) as single

Äh wie ?

Fhutdhb Ufzjjuz schrieb:
>
> Was das Zerpflücken von Strings oder anderen variablen in Bytes angeht,
> so geht das supereinfach.
>
> Dim beliebiger_string as string *20
> dim einzelne_bytes (20) as byte at beliebiger_string overlay

Ok das ist praktisch. Geht das auch mit zusammengesetzten Datentypen?


> Funktionen mit Rückgabewert gibts natürlich auch ...
Die gibts überall ;-)


> function irgendeine_funktion (Wert_zur_funktion_hin)
> local local_single as single
>
> local_single = Wert_zur_funktion_hin*10
> irgendeine_funktion = local_single
> end function

Sorry kannst du das mal sauber und in [code] tags hinschreiben?

>
> EEPROM-Zugriffe gehen supereinfach, auch als eindimmensionales Array ...
>
> dim eepromvariable (10) as eram byte
Das geht in C genauso. Wie wird der zugriff gesteuert? Wird bei jedem 
schreiben auf diese Variable tatsächlich in den eeprom geschrieben?

gruß cyblord

Joachim Drechsel schrieb:
> Fhutdhb Ufzjjuz schrieb:
>> declare function irgendeine_funktion (byval / byref
>> Wert_zur_funktion_hin as word) as single
>
> Äh wie ?

declare function ... alle Funktionen müssen deklariert werden.
Man kann Werte beim Funktionsaufruf mit übergeben, entweder
byval, dann wird der Wert kopiert, Änderungen des Wertes in der Funktion 
bleiben nicht erhalten, oder
byref, dann wird der Pointer des Wertes mit übergeben, nicht der 
eigentliche Wert, bei Änderungen des Übergabewertes in der Funktion 
bleiben die dann bestehen.
as single am Ende bedeutet einfach, dass die Funktion als Rückgabewert 
eine Singlevariable darstellt.

beispiel:

declare function irgendeine_funktion (byval Wert_zur_funktion_hin as 
word) as single

dim ausgabesingle as single
dim uebergabe_wert as word

uebergabe_wert = 10
ausgabesingle = irgendeine_funktion(uebergabe_wert)
print uebergabe_wert
print ausgabesingle
do
loop
end

function irgendeine_funktion (Wert_zur_funktion_hin)
incr Wert_zur_funktion_hin
irgendeine_funktion=Wert_zur_funktion_hin * 2
end function

Hier wäre nun nach dem Funktionsaufruf uebergabe_wert immernoch 10 weil 
byval, ausgabesingle wäre 22

declare function irgendeine_funktion (byREF Wert_zur_funktion_hin as 
word) as single

dim ausgabesingle as single
dim uebergabe_wert as word

uebergabe_wert = 10
ausgabesingle = irgendeine_funktion(uebergabe_wert)
print uebergabe_wert
print ausgabesingle
do
loop
end

function irgendeine_funktion (Wert_zur_funktion_hin)
incr Wert_zur_funktion_hin
irgendeine_funktion=Wert_zur_funktion_hin * 2
end function

Hier wäre nun nach dem Funktionsaufruf uebergabe_wert 11 weil byref und 
in der Funktion incr Wert_zur_funktion_hin, ausgabesingle wäre ebenfalls 
22

Danke für dieses Exkurs in die "Tiefen" der By Value/By Reference 
Problematik. Aber ich denke die kennen wir schon ;-) Darum gehts doch 
gar nicht.

Ich dachte du wolltest die Übergabe von Funktionen als Parameter 
darstellen. Also eine Funktion wird an eine Funktion übergeben.

ps: was hast du gegen die [code] tags?

cyblord ---- schrieb:
> Fhutdhb Ufzjjuz schrieb:
>>
>> Was das Zerpflücken von Strings oder anderen variablen in Bytes angeht,
>> so geht das supereinfach.
>>
>> Dim beliebiger_string as string *20
>> dim einzelne_bytes (20) as byte at beliebiger_string overlay
>
> Ok das ist praktisch. Geht das auch mit zusammengesetzten Datentypen?

Bascom kennt keine zusammengesetzten Datentypen, Du kannst über ne 
Single Variable 2 Word Variablen und 4 Byte variablen drüber legen z.B.. 
Structs gibts in Bascom nicht

>
>> Funktionen mit Rückgabewert gibts natürlich auch ...
> Die gibts überall ;-)
>
>
>> function irgendeine_funktion (Wert_zur_funktion_hin)
>> local local_single as single
>>
>> local_single = Wert_zur_funktion_hin*10
>> irgendeine_funktion = local_single
>> end function
>
> Sorry kannst du das mal sauber und in [code] tags hinschreiben?
kann µC-net basic code formatieren?

>>
>> EEPROM-Zugriffe gehen supereinfach, auch als eindimmensionales Array ...
>>
>> dim eepromvariable (10) as eram byte
> Das geht in C genauso. Wie wird der zugriff gesteuert? Wird bei jedem
> schreiben auf diese Variable tatsächlich in den eeprom geschrieben?

ja, wird direkt keschrieben, mit allen Vor- und Nachteilen z.B. delay. 
Würde ich aber nicht empfehlen ... auch ist damit recht vorsichtig 
umzugehen. Die Abfrage einer ERAM-Variable in einem Interrupt hat mich 
mal einige graue Haare gekostet, weil der EEPROM-Pointer da verschoben 
wird, wird zeitgleich in der Mainloop auf das EEPROM zugegriffen gibt 
das seltsame Effekte ...
Daher zu Programmstart die ERAM in SRAM kopieren und nur von Fall zu 
Fall neu beschreiben wenn erforderlich.
Auch gehts zum beispiel nicht:

sramvariable = eramvariable * 10

das dagegen geht:
sramvariable = eramvariable
sramvariable = Singlevariable * 10

> gruß cyblord

Generell hat Bascom schon einige Pferdefüße ... Rechnen ist ein Graus

declare function irgendeine_funktion (byval Wert_zur_funktion_hin as
word) as single

dim ausgabesingle as single
dim uebergabe_wert as word

uebergabe_wert = 10
ausgabesingle = irgendeine_funktion(uebergabe_wert)
print uebergabe_wert
print ausgabesingle
do
loop
end

function irgendeine_funktion (Wert_zur_funktion_hin)
incr Wert_zur_funktion_hin
irgendeine_funktion=Wert_zur_funktion_hin * 2
end function

declare function irgendeine_funktion (byREF Wert_zur_funktion_hin as
word) as single

dim ausgabesingle as single
dim uebergabe_wert as word

uebergabe_wert = 10
ausgabesingle = irgendeine_funktion(uebergabe_wert)
print uebergabe_wert
print ausgabesingle
do
loop
end

function irgendeine_funktion (Wert_zur_funktion_hin)
incr Wert_zur_funktion_hin
irgendeine_funktion=Wert_zur_funktion_hin * 2
end function

jetzt besser? :o)

cyblord ---- schrieb:
> Danke für dieses Exkurs in die "Tiefen" der By Value/By Reference
> Problematik. Aber ich denke die kennen wir schon ;-) Darum gehts doch
> gar nicht.

ok, dann hab ich da was missverstanden

> Ich dachte du wolltest die Übergabe von Funktionen als Parameter
> darstellen. Also eine Funktion wird an eine Funktion übergeben.

ui, da muss ich passen, hab ich noch nicht probiert

> ps: was hast du gegen die [code] tags?

nix

Klar ist es besser,
so sieht man wenigstens wo code und wo text ist.


Gut es gibt in Bascom Übergabe by Reference, was schonmal gut ist, und 
es gibt overlay = union in c.
Keine zusammengesetzten Datentypen, keine Funktionspointer.

Aber das heißt auch, dass beide meiner Szenarien da oben in Bascom so 
nicht durchführbar sind?
Natürlich kann man Konfig Werte definieren, diese speicher/laden und 
senden/empfangen. Aber der Code Aufwand wäre doch viel viel größer. Das 
ganze wäre auch unübersichtlicher. Mehrere Konfigs gehen dann auch nur 
schwerlich.
Das callback würde an sich gar nicht gehen.

gruß cyblord

cyblord ---- schrieb:
> Klar ist es besser,
> so sieht man wenigstens wo code und wo text ist.
>
>
> Gut es gibt in Bascom Übergabe by Reference, was schonmal gut ist, und
> es gibt overlay = union in c.
> Keine zusammengesetzten Datentypen, keine Funktionspointer.

richtig

> Aber das heißt auch, dass beide meiner Szenarien da oben in Bascom so
> nicht durchführbar sind?

richtig

> Natürlich kann man Konfig Werte definieren, diese speicher/laden und
> senden/empfangen. Aber der Code Aufwand wäre doch viel viel größer. Das
> ganze wäre auch unübersichtlicher. Mehrere Konfigs gehen dann auch nur
> schwerlich.
?? hab ich nicht verstanden ... wie meinst Du das?

Du kannst z.B.

dim singlevar(10) as single
dim bytes(40) as byte at singlevar(1) overlay

oder

dim singlevar(10) as single
dim bytes_1(4)as byte at singlevar(1) overlay
dim bytes_2(4)as byte at singlevar(2) overlay
dim bytes_3(4)as byte at singlevar(3) overlay
etc. etc.

klar, kein Vergleich mit C

> Das callback würde an sich gar nicht gehen.
richtig

> gruß cyblord

Für ein Protokoll wäre z.B. machbar:

dim ausgabearray(30) as byte
dim slaveadresse as byte at ausgabearray(1)
dim masteradresse as byte at ausgabearray(1)+1
dim zielregister as byte at ausgabearray(1)+2
dim registerwert as single at ausgabearray(1)+3
dim stringausgabe as string*5 at ausgabearray(1)+7
dim wordvariable as word at ausgabearray(1)+12

etc.

ich verwende sowas bei nem Modbusbrotokoll

>

> dim singlevar(10) as single
> dim bytes_1(4)as byte at singlevar(1) overlay
> dim bytes_2(4)as byte at singlevar(2) overlay
> dim bytes_3(4)as byte at singlevar(3) overlay
> etc. etc.
> 

>
> klar, kein Vergleich mit C

Eben. Niemand weiß mehr für was jetzt die einzelnen Bytes stehen.
Aber wenn in C dasteht:

Config_t cfg;
cfg.maxTemp=23.5;
cfg.text="Hallo";
cfg.rpm=500;

Das ist schon ne andere Übersichtlichkeit.

Fhutdhb Ufzjjuz schrieb:
> Für ein Protokoll wäre z.B. machbar:
>

> dim ausgabearray(30) as byte
> dim slaveadresse as byte at ausgabearray(1)
> dim masteradresse as byte at ausgabearray(1)+1
> dim zielregister as byte at ausgabearray(1)+2
> dim registerwert as single at ausgabearray(1)+3
> dim stringausgabe as string*5 at ausgabearray(1)+7
> dim wordvariable as word at ausgabearray(1)+12
> 
> etc.
> 

>
> ich verwende sowas bei nem Modbusbrotokoll

Verstehe. Ist interessant.

cyblord ---- schrieb:
> Das ist schon ne andere Übersichtlichkeit.

da hat du absolut recht, wenn man aber mit aussagekräftigen 
Variablennamen arbeitet wie ich in meinem gerade erst verfassten 
Protokollbeispiel kann man dem schon nahe kommen.

Neil schrieb:
> Wäre auch in C kein Problem, wenn man konsequent während seines
> 'Entwicklerdaseins' konfigurierbare Bibliotheken für immer
> wiederkehrende Funktionalitäten aufgebaut hat.

Das kann man aber nur, wenn man sich als Entwickler nicht 
weiterentwickelt.

Wenn man lernfähig ist, wird man zugegeben müssen, dass man Funktionen 
von vor 10 Jahren so heute nicht mehr schreiben würde, weil man 
effizientere Möglichkeiten gefunden hat. Warum sollte man dann auf dem 
Stand von vor zehn Jahren stehende Bibliotheken nutzen?

Timm Thaler schrieb:
> Wenn man lernfähig ist, wird man zugegeben müssen, dass man Funktionen
> von vor 10 Jahren so heute nicht mehr schreiben würde, weil man
> effizientere Möglichkeiten gefunden hat.
Welche und wieso?
Weil man vor 10 Jahren nicht programmieren konnte und heute noch genauso 
vor sich hinwurschtelt? Es gibt auch Leute, die konnten schon vor 20 
Jahren programmieren.

> Warum sollte man dann auf dem
> Stand von vor zehn Jahren stehende Bibliotheken nutzen?
Weil 1+1 vor 10 Jahren 2 war, heute noch ist und in 11 Milliarden Jahren 
auch noch sein wird.

mfg.

Ich hab schon beides ausgiebig benutzt. Was mir an Bascom gefällt:

schreib ein Programm, schreib zwischendrin ein paar Zeilen Assembler, 
compilier das Ganze und Du kannst im Simulator (in der IDE) Schritt für 
Schritt durch den Quelltext wandern, (nicht durch ein Make- Symbol oder 
was auch immer file), egal ob Basic und Assembler-Zeile, und Du siehst 
genau, wieviele Takte bzw. Mikro/Nanosekunden das dauert. Du brennst 
das, und das Zeitverhalten ist exakt so!

Bei C musst Du (wenn Du sowas machen willst) immer die richtige 
Compiler-Eistellung kennen, ckechen, dass nichts wegoptimiert wurde, 
viele Compiler-Optionen kennen und auch noch richtig anwenden ...

Gerade wenn man die Chip-Performance voll ausreizen will, aber nicht 
alles in Assembler schreiben will, hat das viel Charme.

Ähem Fhutdhb Ufzjjuz,

mit "Äh wie" meinte ich nicht, ich hätte es nicht verstanden ;)

Rainer Unsinn schrieb:
> egal ob Basic und Assembler-Zeile, und Du siehst
> genau, wieviele Takte bzw. Mikro/Nanosekunden das dauert.

Das machte mein Keil-Compiler schon vor 20 Jahren. Also schon ein alter 
Hut.

Das Thema "Basic vs C" gibt es hier ja öfters, das letzte Mal sehr
ausführlich erst vor ein paar Monaten:

  Beitrag "Basic und/bzw. vs - C Erfahrungsumfrage"

Die Einschränkungen von Bascom, die ich dort nannte

  Beitrag "Re: Basic und/bzw. vs - C Erfahrungsumfrage"

(keine benutzerdefinierten Datenstrukturen, keine mehrdimensionalen
Arrays) zusammen mit dem Einwand von Karl Heinz:

Karl Heinz Buchegger schrieb:
> Was mir sauer aufstösst, ist zb das man Expressions auf mehrere Zeilen
> aufdröseln muss.

erinnern mich stark an das Basic des Sinclair ZX81 von 1981, das eben-
falls genau diese Einschränkungen hatte. Schon vor 30 Jahren wurde das
ZX81-Basic deswegen belächelt, da die Basic-Dialekte der Konkurrenz
(Apple und Commodore, TRS-80 usw.) mehrdimensionale Arrays und komplexe
Ausdrücke bereits beherrschten (Strukturen hatten aber auch diese nicht,
die kamen für Basic erst sehr viel später).

Thomas Eckmann schrieb:
> Weil 1+1 vor 10 Jahren 2 war, heute noch ist und in 11 Milliarden Jahren
> auch noch sein wird.

Dummfug, 1+1 war auch schon immer 10, oder kann hier jemand nicht 
programmieren?

PeterL schrieb:
> Was mir bei solchen Diskussionen immer wieder auffällt ist, dass es eher
> die C Programmierer sind, die "draufhauen" und Bascom schlechtreden.
> Umgekehrt verneigen sich die meisten demütig, vor der geballten
> Intelligenz.

Du vergleichst Äpfel mit Birnen.

C gibt es für alle Platformen, Bascom nur für ein winzigkleines Segment.

Paul Baumann schrieb:
> Zeigt man einem Außenstehenden dagegen einen Quelltext in C, dann reißt
> der
> ob dieses Kauderwelsches an jedweden verfügbaren Sonderzeichen Mund und
> Nase auf und zollt dem "Experten" Respekt vor seinen enormen Kenntnissen
> in dieser Art:

Lesen können ist immer ein Vorteil.

Ein C-Quelltext ist keine Literatur. Wenn Du die extrem einfache
und übersichtliche C-Syntax nicht kapierst bleibe bei BASIC.

Beginners All ...

Rico schrieb:
> Bibliotheken: Meine jahrelang entstandenen Bibliotheken kann ich alle
> schrotten, weil der Einsatz von XMegas erforderlich ist...Danke C.

Wie ich schon mal oben schrieb: "Was hat die Bibliothek mit der Sprache 
zu tun?"

Rico schrieb:
> Mit Bascom habe ich das nicht einmal gemerkt, außer dass nach 1 Stunde
> bereits die I2C-EEprom Funktionen liefen.

Weil jemand anderes fuer dich die Arbeit getan hat. Wenn du eine fertige 
Lib fuer den Prozessor hast ist das auch in C in 5 Minuten erledigt. Und 
einige neuere Cortex uC haben sowas von Hersteller schon auf dem Chip im 
ROM mit drauf. Aufrufen und fertig.

Rico schrieb:
> Die, die in den C Bibliotheken das Paradies sehen, haben noch nie mit
> einem XMega oder ARM gearbeitet. Wahrscheinlich nur mit Tinys. Die
> laufen auch unter C schnell.

Quatsch. ARM/Cortex sind schon dafuer ausgelegt unter C programmiert zu 
werden. Von den Herstellern gibt es dazu reichlich Biliotheken als 
C-Source b.z.w. in ROM.

C wurde zur Entwicklung von Betriebssystem erschaffen 
UNIX,LINUX,WINDOWS,OS9 etc.

Zeig mir ein Betriebssystem das in BASIC programmiert ist.

Rico schrieb:
> Ich hab einfach nicht immer Zeit und Lust, mich durch 500 Seiten
> Datenblätter zu arbeiten. Das muß eine gute Programmierumgebung für mich
> machen. Sonst ist sie für mich nicht zu gebrauchen.

Niemand liest 500 Seiten Datenblatt durch. Man schaut sich kurz das 
Kapitel an und dann die Registerbelegung. Ein paar Bits gesetzt und 
schon laueft die Funktion. Danach weiss ich auch wie die Hardware an 
dieser Stelle funktioniert. Ist wie mit Auto fahren: Kannst du einen 
fahren, kannst du alle fahren.
Die Peripherie ist doch bei den meisten uC sehr aenlich.

Paul Baumann schrieb:
> Nein, es ist nur komplizierter, sich statt Klartext (z.B. Shift left, or
> and) Sachen wie <<, ||, && einzuprägen.

Schreib mal Programme mit 20000+ Zeilen Code. Da bist du fuer jedes 
Zeichen das du nicht eintippen must dankbar. Alles andere ist nur 
redutantes Geschwaffel.

Rico schrieb:
> Bibliotheken: Meine jahrelang entstandenen Bibliotheken kann ich alle
> schrotten, weil der Einsatz von XMegas erforderlich ist...Danke C.

Das liegt nicht an C, sondern daß Du etwas grundsätzlich falsch gemacht 
hast. Wechselt man den CPU-Typ, muß man nur die wenigen Hardwarezugriffe 
anpassen.
Das soll aber kein Vorwurf sein, es braucht schon etwas 
Programmiererfahrung, um modulare Bibliotheken zu erstellen.
Hilfreich war für mich, daß ich 8051 und AVR in C programmiere. Da 
kriegt man quasi einen Blick dafür, wie man die Hardwareunterschiede 
kapselt.


Rico schrieb:
> Mit Bascom habe ich das nicht einmal gemerkt, außer dass nach 1 Stunde
> bereits die I2C-EEprom Funktionen liefen.

Doch so lange?
Ich hatte auch mal meine I2C-Lib vom 8051 auf den AVR angepaßt, dürfte 
etwa 10min gedauert haben (SW-I2C).
Der Hauptaufwand war die Anpassung der Portzugriffe, der 8051 hat schon 
Open-Drain, der AVR muß das mit dem Directionbit simulieren.
Letzendlich definiert man nur ein paar Macros um (sda_low, sda_high, 
sda_in).


Peter

Paul Baumann schrieb:

> Nein, es ist nur komplizierter, sich statt Klartext (z.B. Shift left, or
> and) Sachen wie <<, ||, && einzuprägen.

Logisch zu Ende gedacht kommen wir bei COBOL an:

    ADD 5 TO A GIVING B

liest sich ja auch gleich viel einfacher als

    b = a + 5

(Ernster Hintergrund: Jede domänenspezifische Notation ist ein 
trade-off: Einmaliger Lernaufwand gegen kontinuierliche 
Aufwandsersparnis in der Anwendung, wenn man es einmal verstanden und 
verinnerlicht hat. Für die klassischen Grundrechenarten haben die 
meisten von uns das in der Grundschule getan. Andere Sachen lohnen sich 
erst, wenn man sie oft genug einsetzt.)

Helmut Lenzen schrieb:

> Zeig mir ein Betriebssystem das in BASIC programmiert ist.

Nein, lieber nicht... ;-)

jau schrieb:
> PeterL schrieb:
>> Was mir bei solchen Diskussionen immer wieder auffällt ist, dass es eher
>> die C Programmierer sind, die "draufhauen" und Bascom schlechtreden.
>
> Die draufhauenden C-Leute haben schon so viel Mühe für "ihre"
> Programmiersprache aufgewendet und stehen wohl immer noch vor neuen
> Überraschungen, daß sie sich nicht vorstellen können, daß es auch
> einfacher geht.

Ihr dreht das Ganze ja wohl zu 180 Grad um.
Was ich hier schon gesehen habe sind immer wieder Threads wo sich Basic 
Freaks gegenseitig hochziehen, daß die 'Profis' die C nutzen Basic nur 
schlechtmachen wollen weil Basic ja eigentlich besser ist.
Im Endeffekt kommt dann das wohlbekannte heraus was Yalu treffend 
zusammengefasst hat. Die eigentlichen Profis nehmen sowiso die Sprache 
die für das Problem gerade passt weil sie nämlich beide Sprachen können 
und Assembler dazu.
Und wehe wenn man jemandem der Basic anfangen möchte zu C rät, dann wird 
man sowas mit Unrat überschüttet.
Also gibt es dann wieder einige, die sich einen Spass daraus machen die 
Basic Jünger mit entsprechenden Postings anzufixen, die reagieren dann 
ja auch so schön vorhersehbar.

Leute Leute, versucht doch einfach mal euren Horizont zu erweitern.
Ich hatte oben schon mal gefragt:
Mit welcher Programmiersprache ist denn BASCOM geschrieben?

Wenn man das auf beliebiges Basic ausweiten will kann man jetzt fragen:
Welches Betriebssystem wurde mit Basic geschrieben?
Welche Datenbank wurde mit Basic geschrieben??
Und umgedreht:
In was wurde MS Office entwickelt?
In was wurde Open Office entwickelt?
In was wurde Oracle, DB/2, MS SQl Server, Notepad++, Firefox, Java 
Compiler, Eclipse, das MS Dev Studio, C#, etc etc etc geschrieben?

Paul Baumann schrieb:
> Wenn BASIC nicht Basic sondern vielleicht "HORST" hieße, hätten nicht so
> viele Leute regelrecht Angst davor zuzugeben, daß sie es benutzen.

Hab ich nicht. Ich schreibe Programme für WinXP in PureBasic. Vom 
einfachen Terminalprogramm bis zu komplexen Bedienoberflächen. Mit 
Callbacks. Mit Structures. Mit mehrdimensionalen Arrays. In Farbe und 
Bunt.

Ich hab angefangen mit Amiga-Basic. Ich konnte mal Pascal, aber das ist 
wohl tot. Ich hatte auch mal GWBasic, grauenvoll. Ich hab mir auch C 
angesehen und mich mit einer Mischung aus Mitleid und Entsetzen 
abgewandt.

AVRs werden trotzdem in ASM programmiert.

Timm Thaler schrieb:

> Ich hab mir auch C
> angesehen und mich mit einer Mischung aus Mitleid und Entsetzen
> abgewandt.

Das lässt tief blicken, was ist an C denn so schrecklich? Vorallem auf 
den ersten Blick? Oberflächlich betrachtet ist doch lediglich der Syntax 
etwas anders und weniger geschwätzig im Vergleich zu Basic. Das große 
AHA Erlebniss kommt doch bei C erst mit komplexeren Aufgaben.

> AVRs werden trotzdem in ASM programmiert.
Was halt auch keinen Sinn macht. Komplexe Programme werden dadurch 
unüberisichtlich, fehleranfällig und null portabel.

gruß cyblord

Udo Schmitt schrieb:
> Also gibt es dann wieder einige, die sich einen Spass daraus machen die
> Basic Jünger mit entsprechenden Postings anzufixen, die reagieren dann
> ja auch so schön vorhersehbar
http://www.o-bizz.de/qbtuts/omastut/index.htm

mfg.

Hab schon einiges in C gemacht, nicht sehr viel zugegeben, meist in 
Basic, weil es meine Anforderungen erfüllt hat, die IDE aus meiner Sicht 
recht gut ist und ich mit Basic auf dem 64er damals begonnen habe.

Bascom hat einen wie ich finde gravierenden Vorteil.

Die Zeit bis zum ersten Erfolg ist extrem kurz ... ein "Hallo Welt" oder 
LED-blink ist in Sekunden zusammengecoded was Bascom für Einsteiger 
durchaus sehr attraktiv macht.
Bis man die C-Umgebung, Make-Files etc. zusammen hat blinkt die LED 
unter Bascom schon.
Gerade für Einsteiger ist dies ein wichtiger Faktor, ob man dran bleibt 
oder das Gerümpel in die Ecke wirft entschiedet sich u.U. innerhalb von 
Minuten.

Wenn die Erfahrung wächst kann der Neuling ja dann in die 
Registerzugriffe und ASM einsteigen, geht alles auch unter Bascom. Mit 
der Zeit und wachsender Erfahrung wird die Syntax eigentlich 
nebensächlich, ob dann C PHP Java-Script oder Bascom für die jeweilige 
Problemlösung verwendet wird spielt immer weniger eine Rolle.

PS: für ARM entwickelt sich das HBBR-Basic

Fhutdhb Ufzjjuz schrieb:
> Die Zeit bis zum ersten Erfolg ist extrem kurz ... ein "Hallo Welt" oder
> LED-blink ist in Sekunden zusammengecoded was Bascom für Einsteiger
> durchaus sehr attraktiv macht.

Das geht in C genauso gut.

> Bis man die C-Umgebung, Make-Files etc. zusammen hat blinkt die LED
> unter Bascom schon.

Die Installation einer Entwicklungsumgebung gilt aber fuer beide 
Sprachen.
AVR-Studio ist genauso einfach zu installieren und Make-Files habe ich 
da auch noch nie direkt angefasst.

Fhutdhb Ufzjjuz schrieb:
> ob dann C PHP Java-Script oder Bascom für die jeweilige
> Problemlösung verwendet wird spielt immer weniger eine Rolle.

Doch die Protabilitaet spielt eine grosse Rolle. Und jetzt nicht wieder 
damit kommen das dass immer wieder angefuehrt wird und doch nicht 
funktioniert. Ich setze hier zur Zeit AVR,MSP430,ARM/CORTEX ein und da 
werden schon Funktionen untereinander ausgetauscht. Man muss halt die 
Funktionen so strikt trennen das man Hardware nahe , Hardware 
unabhaengige und Applikationsspezifische Teile erhaelt. Dann klappts 
auch mit der Protierbarkeit von Funktionen.

Peter hat ja oben ein Beispiel mit seiner I2C Routine gemacht.

Fhutdhb Ufzjjuz schrieb:

> Wenn die Erfahrung wächst kann der Neuling ja dann in die
> Registerzugriffe und ASM einsteigen, geht alles auch unter Bascom. Mit
> der Zeit und wachsender Erfahrung wird die Syntax eigentlich
> nebensächlich, ob dann C PHP Java-Script oder Bascom für die jeweilige
> Problemlösung verwendet wird spielt immer weniger eine Rolle.

Völlig richtig.
Genau hier sehe ich den großen Unterschied zwischen den Usern hier. Die 
angesprochenen Vorteile von Bascom greifen nur wenn man absoluter 
Neuling ist. Als erfahrener Entwickler, Informatiker oder sonst was, 
kann man mit diesen Argumenten nicht viel anfangen. "Leichter Einstieg" 
oder "gute IDE" ziehen dort nicht als Argumente. Und wenn man sowieso 
schon 15 Programmiersprachen beherrscht, hat man für Sprüche, wie 
kompliziert und böse C doch ist, nur noch ein müdes lächeln übrig.
Darum gehen hier die Meinungen auch so derart auseinander.

PPS: Mein erstes Projekt mit µC war ein Traktometer ... ATMega32 auf 
Punktraster, Quarz etc. und LCD dran, an die Kardanwelle nen 
Reedkontakt, ins Gehäuse gepappt und die Kiste lief, Programmierung ca. 
1h Timer, Impulse zählen LCD-Ausgabe, das machte Lust auf mehr.

Fhutdhb Ufzjjuz schrieb:
> PPS: Mein erstes Projekt mit µC war ein Traktometer ... ATMega32 auf
> Punktraster, Quarz etc. und LCD dran, an die Kardanwelle nen
> Reedkontakt, ins Gehäuse gepappt und die Kiste lief, Programmierung ca.
> 1h Timer, Impulse zählen LCD-Ausgabe, das machte Lust auf mehr.

Nunja aber den Hauptteil der Arbeit haben andere für dich erledigt. Was 
ja auch ok ist, aber von "hab ich selber gemacht" kann da halt nicht die 
Rede sein.

gruß cyblord

PeterL schrieb:
> Ich habe auch einige Bücher, aber mein Hirn weigert sich standhaft die
> Syntax aufzunehmen.

Und dabei ist der Syntax einer Sprache eigentlich das kleinste Problem 
;-)

Paul Baumann schrieb:
> Wenn BASIC nicht Basic sondern vielleicht "HORST" hieße, hätten nicht so
> viele Leute regelrecht Angst davor zuzugeben, daß sie es benutzen.

Ich würde BASIC auch dann nicht benutzen, wenn es HORST hieße. Dazu
müsste es mindestens PAUL heißen ;-)

cyblord ---- schrieb:
> Fhutdhb Ufzjjuz schrieb:
>> PPS: Mein erstes Projekt mit µC war ein Traktometer ... ATMega32 auf
>> Punktraster, Quarz etc. und LCD dran, an die Kardanwelle nen
>> Reedkontakt, ins Gehäuse gepappt und die Kiste lief, Programmierung ca.
>> 1h Timer, Impulse zählen LCD-Ausgabe, das machte Lust auf mehr.
>
> Nunja aber den Hauptteil der Arbeit haben andere für dich erledigt. Was
> ja auch ok ist, aber von "hab ich selber gemacht" kann da halt nicht die
> Rede sein.
>
> gruß cyblord

Spannugsregler, Elkos und µC fertigt ein C-Progger oder ASM-Progger auch 
nicht selber ... wo ziehst Du die Grenze?

Die Grenzen ist beim Verständniss. Ein print "Hallo" und dann wird das 
auf dem LCD ausgegeben benötigt NULL Verständniss für die Materie. Ich 
würde keine lib verwenden, ohne das Gerät selbst mal direkt angesteuert 
zu haben. Wenn man es auch ohne lib kann, dann kann man eine lib nehmen 
;-)

Das Spannungsregler-Beispiel ist natürlich suboptimal. Aber die 
Schaltung eines 7805 kann man auch sehr einfach nachvollziehen und 
diskret aufbauen.

Eventuell stehe ich mit meiner Meinung ziemlich alleine da, dass der 
eigentliche Reiz immer im Verständniss für die Materie liegt, mit der 
man sich beschäftigt.

gruß cylord

Überraschter schrieb:
> @ Yalu X. (yalu) (Moderator) schrieb über das goto-Beispiel
>
>> Autsch! Das ist ja ein geradezu perfektes Paradebeispiel dafür, wie man
>> Gotos nicht benutzen sollte.
>
> Herrlicher Beitrag! Applaus!
>
> ;)

Ah kenne jetzt Bascom nicht so aber selbst bei GW/qBasic waren Gotos 
schon meist unsinnig dafür gibt es Call.

was? schrieb:
> cyblord ---- schrieb:
>> Eventuell stehe ich mit meiner Meinung ziemlich alleine da, dass der
>> eigentliche Reiz immer im Verständniss für die Materie liegt, mit der
>> man sich beschäftigt.
>
> Meinst du nicht, da bleibt noch genug "Materie", auch wenn man Programme
> in BASCOM schreibt?

Zumindest nicht auf der SW-Ebene.

cyblord ---- schrieb:
> Die Grenzen ist beim Verständniss. Ein print "Hallo" und dann wird das
> auf dem LCD ausgegeben benötigt NULL Verständniss für die Materie. Ich
> würde keine lib verwenden, ohne das Gerät selbst mal direkt angesteuert
> zu haben.

Das würde aber im Umkehrschluss bedeuten, daß du kein PC benutzen kannst 
bevor du nicht für alle Peripherie einen Systemtreiber geschrieben hast.
Ausserdem dürftest du keine Funktionen der C Library nutzen.

Ich stimme allerdings mit dir überein, daß programmieren mehr ist als 
sich ein paar Code Fragmente aus dem Internet zusammenzukopieren und 
sich diese dann in einem Forum zum funktionieren bringen zu lassen. Das 
wurde hier je schon oft genug versucht/gemacht.
Da ich nicht weiss wie Fhutdhb Ufzjjuzs Projekt ausgesehen hat ist dies 
jetzt KEINE Anspielung auf sein Traktometer, sondern allgemein gemeint.

cyblord ---- schrieb:
> Eventuell stehe ich mit meiner Meinung ziemlich alleine da, dass der
> eigentliche Reiz immer im Verständniss für die Materie liegt, mit der
> man sich beschäftigt.

Eigentlich nicht, ich sehe das genauso.
Bei den meisten Bascom Threads hier im Forum geht es doch um Probleme 
die der TO deshalb nicht verstanden hat weil er sich mit der Materie 
nicht auseinander gesetzt hat sondern nur die fertige Loesung genommen 
hat. Tritt dabei ein kleines Problemchen auf stehen die meistens auf dem 
Schlauch.

Udo Schmitt schrieb:

> Das würde aber im Umkehrschluss bedeuten, daß du kein PC benutzen kannst

Nunja, diese Entgegnung habe ich kommen sehen ;-)
Es gibt immer ein Abstraktionslevel hinter das wir nicht sehen können. 
Beim PC ist dies im täglichen Umgang sehr hoch angesiedelt.

> bevor du nicht für alle Peripherie einen Systemtreiber geschrieben hast.
Nein, aber wenn man keine Ahnung hat, was ein Treiber ist, und wie er 
grundsätzlich funktioniert und wie er mit dem System interagiert, dann 
wird eine ernsthafte Entwicklung für den PC auch schnell ihre Grenzen 
finden. Darum geht es.

> Ausserdem dürftest du keine Funktionen der C Library nutzen.
Habe früher viele Standard-Funktionen nachgebaut, teils auch aus 
Unkenntniss darüber dass es dafür fertige Funktionen gab. Sowohl beim PC 
als auch beim µC mit AVR-GCC.


> Damit stellst du jede Bibliothek und jedes Framework in Frage. Warum
> denn dann nicht gleich in Assembler?
Denkst du, Frameworks und Bibs gibt es, weil der Entwickler es ohne 
nicht könnte? Die Gründe sind doch ganz andere. Aber bei BASCOM und 
Arduino wird Unfähigkeit durch libs kaschiert. Und das ist das Problem.

@Helmut:
Ja bei BASCOM und auch bei Arduino Benutzern ist dieses Problem weit 
verbreitet. Fertige Libs für alles, der Rest per copy&paste und dann 
fliegt einem alles um die Ohren wenn eine Komma falsch gesetzt ist.



gruß cyblord

Helmut Lenzen schrieb:
> Bei den meisten Bascom Threads hier im Forum geht es doch um Probleme
> die der TO deshalb nicht verstanden hat weil er sich mit der Materie
> nicht auseinander gesetzt hat sondern nur die fertige Loesung genommen
> hat.

Das ist aber nicht Bascom-spezifisch, das sieht man C genauso oft, 
vielleich sogar noch öfter. Es gibt in diesem Forum mehr als genug 
Threads, in denen der Fragende nicht nur die Hardware nicht versteht, 
sondern auch die verwendete Programmiersprache.

Da meine AVRs weder C noch Basic können, programmiere ich sie in 
Assembler. Das ist dann wenigstens wirklich selbst gemacht. Oder 
vielleicht doch nicht? Denn irgendwer hat ja den Befehssatz definiert, 
die Innereien kreiert und den Assembler geschrieben... Scheiß Spiel, man 
bekommt wirklich nix mehr selbst gebacken...

...

cyblord ---- schrieb:
> Eventuell stehe ich mit meiner Meinung ziemlich alleine da, dass der
> eigentliche Reiz immer im Verständniss für die Materie liegt, mit der
> man sich beschäftigt.
Stehst du nicht.

Helmut Lenzen schrieb:
> Bei den meisten Bascom Threads
Fairerweise muß man aber sagen, daß das bei mindestens genauso vielen
"C-Threads" auch so ist.

Udo Schmitt schrieb:
> Das würde aber im Umkehrschluss bedeuten, daß du kein PC benutzen kannst
> bevor du nicht für alle Peripherie einen Systemtreiber geschrieben hast.
Ach komm. Dann müsste man auch die Makromoleküle, aus denen sich der 
Kunststoff der Tastatur zusammensetzt, kennen und mindestens einmal 
selbst zusammengemischt haben. Genauso hat man den Baum, aus dem der 
Stuhl gemacht wurde, auf dem man sitzt, natürlich selbst gefällt.

mfg.

cyblord ---- schrieb:
> Die Grenzen ist beim Verständniss. Ein print "Hallo" und dann wird das
> auf dem LCD ausgegeben benötigt NULL Verständniss für die Materie. Ich
> würde keine lib verwenden, ohne das Gerät selbst mal direkt angesteuert
> zu haben. Wenn man es auch ohne lib kann, dann kann man eine lib nehmen
> ;-)
> Eventuell stehe ich mit meiner Meinung ziemlich alleine da, dass der
> eigentliche Reiz immer im Verständniss für die Materie liegt, mit der
> man sich beschäftigt.
>
> gruß cylord

Nein, stehst Du nicht, ich gebe dir absolut Recht, heute verwende ich 
kaum mehr Bascom Highlevelbefehle, beim Traktometer damals schon und es 
führte zu einem scchnellen Ergebnis was für mich dann Motivation war am 
Ball zu bleiben.
Beispiel GLCD ... da hat Bascom ne schöne Lib dafür ... dumm wirds aber 
wenn man vom Routing her die Ansteuerung nicht so machen kann wie das in 
Bascom eben vorgegeben wird. Da muss man dann seinen eigenen "Treiber" 
schreiben, genauso wie in C ... idealerweise baut man sich auch nen 
header File mit den Deklarationen und die Subroutinen in eine separate 
Datei, damit man die in anderen Projekten wiederverwenden kann ... wird 
dann einfach per include eingefügt und gut ist.
Man muss die Highlevelbefehle nicht gezwungenermaßen verwenden, 
genausowenig wie in C die Libs ... liest man ja auch oft genug hier im 
Forum "Problem mit Lib von x für Aufgabe y"

pegel schrieb:
> In welcher Sprache ist eigentlich Bascom selbst geschrieben ? :-)

Bascom kann nur mit Bascom geschrieben worden sein. Das ist wie mit 
Chuck Norris. Er kann sich nur selbst gezeugt haben.

jau schrieb:
> C ist für manche das, was dem HiFi Freak seine esotherisch behandelten
> Kabel sind.

Falsch, C ist eher das Kupfer in der Leitung. Was man damit macht: 0,30 
Euro pro Meter normale Leitung oder 1000 Euro pro Meter für 
linksdrehende elektronenfreie Ultra Hip Kabel ist dann Sache desjenigen 
der das Kupfer benutzt.
Und Basic ist dann halt ne Aluleitung, vieleicht mehr Innenwiderstand 
aber leitet auch und ist in bestimmten Bereichen einsetzbar.

Und wer die 1000 Euro Leitung kauft ist der Trottel der zu wenig Wissen 
hat, egal ob von C von Basic oder von Stromleitung.

Wissen ist nur durch mehr Wissen zu ersetzen.

> Bibliotheken: Meine jahrelang entstandenen Bibliotheken kann ich
> alle schrotten, weil der Einsatz von XMegas erforderlich ist...Danke C.

Schwaches Argument.

Der BASCOM Hersteller hat dir die Umsetzung auf XMega abgenommen. 
Irgendwer muss sie schliesslich machen, das passiert auch bei BASCOM 
nicht von alleine.

Und wenn du deine Bibliotheken so aufgebaut hast, dass du davon wirklich 
nichts mehr wiederverwenden kannst, noch nicht einmal die API, dann hast 
du deine Bibliotheken schlecht aufgebaut.

In beiden Fällen kann da aber die Sprache C bzw. die Sprache BASCOM nix 
dafür.

Tröte schrieb:
> FAZIT dieses Threads:
>
> Bascom ist ein geeignetes Toy für Hobbyfummler, die ohne große
> Kenntnisse oder Lernaufwand mal schnell was zusammenstöpseln wollen,
> ohne sich für Details zu interessieren, und die nicht in der Lage sind,
> sei es aus mentalen oder zeitlichen Gründen, sich mit professionellen
> Tools auseinanderzusetzen.
>
> Also keine neuen Erkenntnisse, und alles im Lot.
>
> Bizarr wird's nur, wenn genau DIESE Leute dann jammern, daß ihnen jemand
> aus Osteuropa/Indien/China den Job wegnimmt. Mir kann nämlich keiner
> erzählen, er verhielte sich im Hobby grundlegend anders als im Job.

Du hattest woh Polemikclown zu Mittag oder was ...

nein, das Fazit ist: "Jedem Narren seine Kappe"

Was die verlagerung meines Jobs nach China angeht ... eher nicht. 18ha 
Weinberge lassen sich nicht so einfach verschieben.

Und was die Güte der Produkte mit Bascomprogrammierung angeht ...

Mich hat Bascom zum shake hands mit der Kanzlerin gebracht inklusive 
Gratulation (Bildanhang, die neben mir ist die Kanzlerin) zum 
innovativen Produkt ... und Dich?

Fhutdhb Ufzjjuz schrieb:
> Mich hat Bascom zum shake hands mit der Kanzlerin gebracht inklusive
> Gratulation

Sorry aber da liegt mir auf der Zunge:
"Da sieht man wieder daß Politiker keine Ahnung von Technik haben"
Oder
"Tja, die is halt Physiker, die haben keine Ahnung von 
Softwareentwicklung"

Nein im Ernst, Gratulation (zum Preis, nicht zum Shakehands mit dem 
weiblichen Klon vom Pfälzer Saumagen)

Tröte schrieb:
> Sagtest Du mir, die Firmware der Kanzlerin sei in Bascom geschrieben,
> glaubte ich Dir sofort ... funktioniert irgendwie und auch schon recht
> lange, aber state-of-the-art ist doch deutlich anders ;-)

Die Software der Kanzlerin sieht so aus:

while(1)
{
}

Helmut Lenzen schrieb:
>
> Die Software der Kanzlerin sieht so aus:
>
> while(1)
> {
> }

Ahhh das schmerzt in den Augen. So geht das nicht! Zeichenverschwendung 
(ja auch Whitespaces sind vollwertige Zeichen und sollten respektiert 
werden).
So ists besser:

while(1);

Geht noch kuerzer:

for(;;);

Helmut Lenzen schrieb:
> Geht noch kuerzer:
>
> for(;;);

Finde ich aber ideologisch bedenklich. Denn for impliziert eine Schleife 
mit einer maximalen Anzahl von Durchläufen. Also genau das Gegenteil 
einer Endlosschleife. Meist ist es ein Programmierfehler wenn eine 
for-Schleife zur Endlosschleife wird.

Allerdings würde mich interessieren ob das Konstrukt in Bascom möglich 
ist. In alten Basics mussten for-Schleifen irgendwann enden. So gesehen 
hält sich Basic daher eigentlich strikter an die theoretische Grundlage 
von for, nämlich der Klasse der LOOP Äquivalenten Sprachen. In Basic 
wäre daher ein Programm mit for-Schleifen nicht Turing-Vollständig, was 
auch korrekt wäre nach der Theorie.


gruß cyblord

Dr. Dr. med Foo schrieb:
> cyblord ---- schrieb:
>> Meist ist es ein Programmierfehler wenn eine
>> for-Schleife zur Endlosschleife wird.
>
> Meist ist es ein Programmierfehler wenn eine while-Schleife zur
> Endlosschleife wird. Es macht keinen Unterschied.

Hmm, bei µC Programmierung sieht man aber regelmäßig Endlosschleifen.

Schlagt doch dem Standards Committee eine Spracherweiterung vor:
for ever { }

cyblord ---- schrieb:
> In alten Basics mussten for-Schleifen irgendwann enden.

Ich weiß nicht, wie alt das BASIC ist, von dem Du sprichst, aber im 
Microsoft-basierten C-64-BASIC hat z.B.

for i = 1 to 2: i=i-1: next i

eine prima Endlosschleife produziert.

Die Negation ist dann "for never () {}" ?

Udo Schmitt schrieb:

> Schlagt doch dem Standards Committee eine Spracherweiterung vor:
> for ever { }

> Die Negation ist dann "for never () {}" ?

Dafür!
/sign

Joachim Drechsel schrieb:
> Die Negation ist dann "for never () {}" ?

:-)
Dafür gibts dann die Fehlermeldung: "unreachable code". Zumindest wenn 
innerhalb der geschweiften Klammer was steht.

Ist wie bei der Digitaltechnik, wenn es da nach Strom riecht weisst du 
vorher auch nicht ob jetzt ein "immer" oder ein "nimmer" gatter 
entstanden ist.

cyblord ---- schrieb:
> Allerdings würde mich interessieren ob das Konstrukt in Bascom möglich
> ist. In alten Basics mussten for-Schleifen irgendwann enden.

Bascom hat (wie VB) die Anweisung Exit. Damit kann man aus Schleifen, 
Subs und Funktionen herausspringen, ohne den Stack zu beschädigen.

Warum hackst Du eigentlich immer auf etwas (Bascom) herum, was Du gar 
nicht kennst??

...

Hannes Lux schrieb:
> cyblord ---- schrieb:
>> Allerdings würde mich interessieren ob das Konstrukt in Bascom möglich
>> ist. In alten Basics mussten for-Schleifen irgendwann enden.
>
> Bascom hat (wie VB) die Anweisung Exit. Damit kann man aus Schleifen,
> Subs und Funktionen herausspringen, ohne den Stack zu beschädigen.
Klaro, gibts fast überall. Hat aber mit meinem Zitat nichts zu tun.

> Warum hackst Du eigentlich immer auf etwas (Bascom) herum, was Du gar
> nicht kennst??
Das war keine Kritik an BASCOM. Allerdings habe ich hinreichend viel 
Erfahrung mit allen möglichen BASICs. Aber es stimmt schon, selbst bei 
Apple Basic auf dem \\c konnte man ein STEP definieren und so 
endlosschleifen erzeugen:
for i=1 to 5 step -1

gruß cyblord

Paul Baumann schrieb:
> ich gratuliere Dir zu dem errungenen Preis, wobei es wahrscheinlich
> anstrengender ist, in einem Weinberg ein Array von Weinstöcken anzulegen

Besonders mit mehr als 2 Dimensionen :=)

Paul Baumann schrieb:
> Es ist mir leider auch nicht gelungen, herauszufinden, womit Bascom
> selbst erstellt wurde. Das ist eine interessante Frage.

Koennte man eventuell am Disassemblierten EXE File erkennen.

Helmut Lenzen schrieb:
> Paul Baumann schrieb:
>> Es ist mir leider auch nicht gelungen, herauszufinden, womit Bascom
>> selbst erstellt wurde. Das ist eine interessante Frage.
>
> Koennte man eventuell am Disassemblierten EXE File erkennen.

Ich würde da einfach mal auf MS Visual Studio, genauer Visual C++ 
tippen.

Udo Schmitt schrieb:
> Fhutdhb Ufzjjuz schrieb:
>> Mich hat Bascom zum shake hands mit der Kanzlerin gebracht inklusive
>> Gratulation
>
> Sorry aber da liegt mir auf der Zunge:
> "Da sieht man wieder daß Politiker keine Ahnung von Technik haben"
> Oder
> "Tja, die is halt Physiker, die haben keine Ahnung von
> Softwareentwicklung"
>
> Nein im Ernst, Gratulation (zum Preis, nicht zum Shakehands mit dem
> weiblichen Klon vom Pfälzer Saumagen)

Nee, die Entscheidung traf ein Gremium von Leuten aus der Branche, die 
Dame war lediglich zur Verleihung präsent. War aber dennoch eine 
interessante Erfahrung, zum Einen der Ablauf, viele Herren im schwarzen 
Anzug, die förmlich BKA auf der Stirn tätowiert hatten, zum Anderen, das 
der Preis für Verfahrens- und Prozesstechnik an mich als Onemanshow ging 
und so manche Größe in der Branche leer ausging.

Merci :o)

Wär aber auch egal gewesen ob das Ding nun in Bascom, C, Java oder 
Fortran programmiert gewesen wäre ... hat kein Aas danach gefragt, die 
Funktion musste gegeben sein, was beim Wettbewerb von der Hardware her 
nicht der Fall war.

cyblord ---- schrieb:
> Ich würde da einfach mal auf MS Visual Studio, genauer Visual C++
> tippen.

Vermute ich auch mal.

Fhutdhb Ufzjjuz schrieb:
> Wär aber auch egal gewesen ob das Ding nun in Bascom, C, Java oder
> Fortran programmiert gewesen wäre ... hat kein Aas danach gefragt, die
> Funktion musste gegeben sein, was beim Wettbewerb von der Hardware her
> nicht der Fall war.

Jepp, im Endeffekt zählt halt was hinten rauskommt :-)
Schönes Wochenende

Kopfschüttel.
Was habt ihr immer mit den C-Sonderzeichen. Soviele sinds doch gar nicht 
bzw. sind doch ohnehin immer dieselben 10 (größenordnungsmässig).
Programmiert doch mal in APL. Da könnt ihr euch über Sonderzeichen 
beschweren. Wenn da mal ein normales ASCII Zeichen auftaucht, ist das 
schon die Ausnahme, für die man eigentlich sofort ein Grillfest 
anzetteln sollte um das Ereignis zu feiern.

Eine Programmiersprache ist ein WERKZEUG mit dem man seine Arbeit macht. 
Mehr nicht. Beim Programmieren gehts doch nicht darum, ob ich jetzt

   if    then

   endif


oder

   if(  ) {

   }

schreibe. Das sind doch nur 2 verschiedene Schreibweisen. Der 
interessante Teil beim Programmieren sind die Verfahren, die 
Algorithmen. Dort steckt das Gehirnschmalz drinnen und nicht ob ich 
jetzt DO LOOP oder while(1) schreiben muss.

Helmut Lenzen schrieb:
> Die Software der Kanzlerin sieht so aus:
> while(1)
> {
> }
Und beim Koalitionspartner:
while(0);

In einigen Landesparlamenten hat der Compiler das auch schon 
wegoptimiert.
Also das ist jetzt nicht politisch gemeint.
Deshalb nochmal eine ernsthafte Frage:
Kann Bascom auch in verschiedenen Levels optimieren?

mfg.

cyblord ---- schrieb:
>> AVRs werden trotzdem in ASM programmiert.
> Was halt auch keinen Sinn macht. Komplexe Programme werden dadurch
> unüberisichtlich, fehleranfällig und null portabel.

Programme werden dadurch schnell und ressourcenschonend.

Übersichtlichkeit erreicht man durch Strukturierung, Fehleranfälligkeit 
minimiert man durch saubere Programmierung, Portierbarkeit zumindest auf 
weiterentwickelte AVRs erreicht man durch Einsatz von Konstanten statt 
direkter Adressierung. Also genau so wie bei "höheren" 
Programmiersprachen.

Dafür weiss ich in ASM genau, was der AVR im Programm macht.

Ich hab mir einfach mal eine Aufgabe in einer "höheren" Sprache 
geschrieben und das Ergebnis mit der Lösung in ASM verglichen. Wenn dann 
für einfache verkettete Rechenoperationen ständig Werte "gestort" und 
"geloadet" werden und die Ausführung in einer doch etwas zeitkritischen 
PID-Regelung dafür fünfmal solange dauert, weiss ich was ich an ASM 
habe.

Timm Thaler schrieb:
> weiss ich was ich an ASM habe.
Du bist hier im falschen Thread.
Hier läuft:
"Ewig-gestrige C-Freaks" vs "Weitsichtige Bascom-Programmierer"

Assembler-Friemler werden woanders fertig gemacht.

mfg.

Ich habe früher auch viel BASIC programmiert.
Erst aufm Sinclair ZX81, dann aufm Casio Taschenrechner, dann QBasic, 
Quickbasic und schließlich FreeBasic. Ich schäme mich so! Ich glaub ich 
brauch nächste Woche wieder ne Sitzung beim Therapeuten.

Beruflich progge ich nicht mehr, haben wir alles in die Gegend den 
Punjab aussgegliedert. Ist billiger, sagt unser Prozessoptimierer.

Marek N. schrieb:
> Ich schäme mich so! Ich glaub ich
> brauch nächste Woche wieder ne Sitzung beim Therapeuten.
Musst du nicht.
Hier sind die Bascomiker die Guten und die C-Programmierer die Deppen.

mfg.

Immer wieder zu beobachten ist das viele meinen nur weil sie eine 
bestimmte Sprache können wären sie gleich Profis.

Programmieren hat doch zu aller erst mit den Algorithmen zu tun, die 
Sprache ist erst mal zweitrangig.

Und wenn es keine Lib, Highlevelbefehl etc pp gibt, dann sollte man eben 
noch wissen wie man sich das Bastelt.

Natürlich muß man Anforderungen wie Portierbarkeit in die Auswahl bei 
bedarf mit reinnehmen, aber ich denke man sollte immer Idiologiefrei 
beim Projektstart vorgehen.

Wahnsinn, der ganze Beitrag ohne Nennung einer Sprache. :-)

Übrigens ist es auch im richtigen Leben von Vorteil wenn man mehr als 
eine Sprache kann.

Paul Baumann schrieb:
>>Ich würde BASIC auch dann nicht benutzen, wenn es HORST hieße. Dazu
>>müsste es mindestens PAUL heißen ;-)
>
> Ja, das wäre was! ;-)
> Aber ich glaube nicht, daß ich es schaffe, eine eigene
> Programmiersprache
> "herzustellen".

Blaise PASCAL hat keine eigene Programmiersprache entwickelt.
ADA Lovelace hat keine eigene Programmiersprache entwickelt.
Monty PYTHON haben keine eigene Programmiersprache entwickelt.
HASKELL Curry hat keine eigene Programmiersprache entwickelt.
Gustave EIFFEL hat keine eigene Programmiersprache entwickelt.
PAUL Baumann wird auch keine eigene Programmiersprache entwickeln,

... aber vielleicht findet sich jemand in seiner ständig wachsenden
Fangemeinde, der PAUL für ihn auf den Weg bringt.

Bitte füllen Sie dieses Feld aus. schrieb:
> Eine Sprache in der das Programm als Gedicht geschrieben werden muss,
> DAS wär doch mal was.

An so etwas hätte ich auch als erstes gedacht. Ein Ansatz, in welche
Richtung PAUL (Akronym für "Programming Artistically Using Lyricism")
gehen könnte, ist Shakespeare:

  http://shakespearelang.sourceforge.net/report/shakespeare/

Das ist doch eine schöne Programmiersprache, die besonders die Hasser
kryptischer C-Operatoren zum Schwärmen bringen dürfte. Man schaue sich
nur die Beispielprogramme auf der Webseite an. Kann da Basic auch nur im
Ansatz mithalten?

Paul ist aber nicht Shakespeare und sein Stil ist auch ein anderer.
Deswegen muss PAUL von Grund auf neu entwickelt werden, was — um dem
großen Namen halbwegs gerecht zu werden — sicher einige Jahrzehnte in
Anspruch nehmen wird. Mal sehen, ob ich mal etwas Zeit übrig habe ...



Paul Baumann schrieb:
> Es ist mir leider auch nicht gelungen, herauszufinden, womit Bascom
> selbst erstellt wurde. Das ist eine interessante Frage.

Sowohl der Compiler als auch die IDE scheinen in Delphi geschrieben zu
sein.

Guter Brauch ist es ja eigentlich, einen Compiler in seiner eigenen
Sprache zu schreiben, also einen C-Compiler in C, einen Lisp-Compiler in
Lisp usw., so dass er sich selbst übersetzen kann. Das hat neben
technischen und organisatorischen Vorteilen auch einen interessanten
philosophischen Aspekt: Er ist die Existenzberechtigung seiner selbst.

Aber ok, bei einem Cross-Compiler liegen die Dinge etwas anders. Wäre
der Autor aber ein echter Basic-Freak, hätte er Bascom wenigstens in
Visual Basic oder dergleichen geschrieben ;-)