PICkel! Du Lauselümmel !

Hat nicht funktioniert! Also der erste Hinweis mit ,,exp10" !
Aber der Zweite ist voll eingeschlagen: gleich im ersten Versuch mit der hochgestellten Spitze hat's den erhofften Potenzwert zurück gegeben! Man könnte demgemäß also sich der These annähern, dass du doch schon so den einen und evtl. auch anderen Erfahrungspunkt in Sachen µC-Technik mal erhascht hattest!
    
Gut, an der Formulierung arbeite ich noch! Gibt vielleicht noch' Nachschlag.

Hatte die Aufzählung aller Befehle, Funktionen etc. mehrfach gelesen, nicht nur die Befehle selbst, sondern natürlich auch die Erklärungen dazu, aber da war nichts fürs Potenzieren. Es gab auch keine Zusammenfassung, rsp. Darstellung von Operatoren, mit denen sich mathematische Funktionen ausführen ließen. Warum das nicht umgesetzt wurde für den Fall des Potenzierens...., man weiß es nicht.

Ihr ahnt nicht, was das für mich bedeutet! Natürlich war ich in die neue Welt mit einer ziemlichen Erwartungshaltung gestartet, zumal die Redakteure im Heise-Verlag so voll des Lobes über diese Art des Basic-Dialektes waren. Gerade die langen und mehrfach hintereinander geschalteten Formeln in aktuell interessierenden Projekten waren ja der Grund für den Aufbruch gewesen. Und da gleich am Anfang schon ausgebremst zu werden, hat mir gestern und heute viel Frust verschafft. Nu' aber die Erkenntnis, dass es in der Ferne doch scheinbar unbegrenzte Möglichkeiten gibt, rsp. zu geben scheint, das ist schon eine tolle Sache. Besser als so manches Weihnachtsgeschenk!

Hatte heute morgen im Vertrauen auf die Zukunft schon Temp- u. Luftfeuchte-Sensoren, Ultraschall-Entfernungsmesser, ein Servo bestellt, gestern 2 kleine Displays..... nu' kann's wirklich losgehen. Der 32-ziger-PIC ist wohl zu kaufen, allerdings nur bei den Versendern, die aus den USA liefern, jeweils für gut 20 € Frachtkosten. Da hab' ich mich noch zurück gehalten, aber das liegt schon in der Pipeline der Absichten.
Jetzt freue ich mich erst mal. Dann noch mal. Dann sowieso.
Dann noch ein Dankeschön, Bernd

Na dann viel Erfolg!

Zur Liefersituation: TME hat noch PIC32 vorrätig. Achte auf den Speicherbedarf von MMBasic!
Ich kenne die Entwicklungsumgebung nicht. Deshalb, wenn Du einzelne PICs bestellst: Der BASIC-Interpreter muss in den PIC geflasht werden können, also entsprechende Möglichkeiten vorsehen.

Gruß
PICkel

Übrigens: Das ^ (Caret) ist keine Funktion sondern wird als Operator bezeichnet (Wie +-*/>< etc.). 
Siehe
https://geoffg.net/Downloads/picomite/PicoMite_User_Manual.pdf Seite 20.

Ich frage mich warum du einen Basic Interpreter nimmst. Warum muss es Basic sein? Nimm einfach einen Compiler, z.B einen C-Compiler.

Warum jetzt einen Interpreter verstehe ich auch nicht so ganz.
Besonders weil man da doch sehr eingeschränkt ist.
Ob jetzt C, Basic oder sonst was ist eigentlich egal aber sollte schon
ein Compiler sein. Aber wenn dir die ganzen Einschränkungen und Nachteile
nichts ausmachen und du damit gut Arbeiten kannst, ist doch alles ok.

Gemach, Freunde!
Ist echt rührend, wie ihr euch kümmert!

Erst muss ich was nachtragen und auch da muss ich durch: Dieses spitzige Zeichen fürs Potenzieren ist sehr wohl in der Dokumentation vorhanden und ich hatte es auch gefunden. Dies aber erst gestern Abend nach dem Einstellen meines vorigen Textes. In der Übersicht, welche diese Operatoren aufführt, steht's drin, aber da hatte ich vorher gar nicht gesucht, sondern nur in der ewige Seiten langen Aufstellung der Befehle, denen man einen eigenen Namen und eine Beschreibung gegönnt hatte. Also an den Plätzen, an welchen u.a. die mathematische Funktionen ihren Platz haben. Vielleicht hatte ich es gesehen, konnte aber damit nichts anfangen. Die Zeiten des ,,peek" und ,,poke" aus meiner Sinclair ZX Spectrum-Periode sind zu lange her, als das da eine besondere Erinnerung noch bestünde... viel zu lange her. Und gerechnet habe ich mit den Plastik-Kisten wohl eher sowieso nicht. Also... ich bin entlastet. Also fast.

Natürlich: bislang benutzt hatte ich ein reines Terminal-Programm. Das sieht wie eine DOS-Box aus, auch pott-schwarzer Bildschirm mit winzig weißer Schrift. Das Ding war geeignet, um den allerersten Schritt zu gehen, nämlich zu prüfen, ob überhaupt eine Verbindung zustande gekommen war, und danach, ob ,,print 5*4" auch eine Zahl zurück gab, die mit meinen bescheidenen Mathekenntnissen sich in Übereinstimmung bringen ließ. Ansonsten war dieses T-Prog völlig unbrauchbar. Da konnte man nicht mal das erstellte ,,Programm", welches maximal aus 3 Zeilen bestand, speichern. Ne, das war nur der anfängliche Testbetrieb. Aber dafür war es gut, weil wirklich einfach in Betrieb zu nehmen war, und so war alles richtig. Bis dahin.

Die Inbetriebnahme des eigentlich angestrebten Basic-Progs erwies sich als holpriger. Da war die Dokumentation dann doch nicht – räusper – ,,idoten-sicher". Also heute etwas rum probieren, und – tusch – auch dieses ließ sich in Betrieb nehmen, die serielle USB-Verbindung herstellen, und endlich gabs auch keine Meckermeldung des für die Übertragung zuständigen Teil-Progs. Dann musste ich nur noch meinen HP41 anwerfen, um zu prüfen, ob denn die Zahl ,,20" dez korrekt zu erwarten gewesen wäre. Danach entstand meine allererstes Basic-Prog in dieser Umgebung und – is klar – da wurde wieder die berühmte eine LED zum Blinken überredet. Das Prog speichern, wieder aufrufen, ändern, ausführen....

Nun ist es vollbracht: der Anfang ist gesetzt und nu' könnte es losgehen. In der hatten Praxis aber nicht, stattdessen gehe ich zu meinem Elektro-Roller und roller damit zu der Einkaufsmeile. Also Entspannung für euch, für mich weniger, weil es draußen regnet, und mein Dank gilt euch allen.
Grüße, Bernd

Nachtrag: die erst gestern Mittag bei "Reichelt" bestellten u oben genannten Teile sind gerade eben via DPD angeliefert worden. Das geht schon fix heutzutage.

Schön hier..... am anderen  Ufer!

Mein zweites Programm mit der neuen MMBasic-Interpreter-Umgebung:
neun Zeilen lang, drei oder vier hätten wohl auch gereicht, und es enthielt die komplette Abarbeitung der Formel, welche aus den zwei Eingangswerten: Innentemperatur (Keller) und Außentemp (sibirische Taiga) einen Taupunkt ermittelt. Hat auf Anhieb – hüstel – geklappt, und nach Abzug der Zeit für die Korrektur der  vergessenen Klammern und der aus Gewohnheit ,,Falsch"-Schreibung des Dezimalpunktes noch in der Form als ,,Komma" vielleicht 5 min der Erstellung benötigt. Was bei meinem 18-er-Assembler-PIC Wochen der versuchten Kniffe, doch noch mit Zehner-Exponent und Logarithmus hin zu kommen, benötigte, war nun round-about nach zwanzig Minuten Geschichte.

Die Ausführungszeit wurde vom Terminalprog mit 1,5 sec angegeben, wobei ich aber davon ausgehe, dass diese Zahl die Gesamtzeit beinhaltet: Kompilieren, rüber senden des Progs, in den Speicher verfrachten, es ausführen lassen, das Ergebnis zurück senden und auf dem PC-Monitor anzeigen. Ist mir aber auch für diesen Fall vollständig Wurscht, selbst eine Ausführungszeit von 1 Minute wäre für die angestrebte Anwendung noch rasend schnell.

Ich sitze hier immer noch und wenn ich doch nicht sitze, dann halt im Laufen mit kreisrunden Augen, verstehe irgendwie  die µC-Welt nicht so richtig und staune mehr als die berühmten Bauklötze: Nix mit includieren vor dem Programmstart, kein ellenlanges Bearbeiten von Einstellungen, einfach  anfangen mit Schreiben der Prog-Zeilen, hier drei  Variable/Konstante benennen, los gehts und zack ist das Prog fertig. Auf das ,,Run-Symbol" klickern, die 1,5 sec abwarten und das Terminalprog spuckt das monatelang erhoffte Ergebnis in Gestalt der Temperatur des Taupunktes aus! Kreisrunde Augen, dass so was auch möglich ist!

Dem Hinweis von PICkel auf die Liefermöglichkeit des empfohlenen 32-PICs bin ich noch vor diesem Zweite-Formel-Erfolg heute Vormittag nachgekommen und habe zwei Stücke und eine winzige u evt. gar nicht notwendige Terminal-Platine gleich mit bestellt. Teuer.... Da sind fast 40 € drauf gegangen, das war ein Wechsel auf die ungewisse Zukunft. Ein sinnvolles Prog werde ich da schon rein bekommen. Ob der gewünschte Anschluss einer Anzeige und der Thermo-Sensoren klappt... Zukunft. Die winzige OLED-Anzeige (0,9") ist schon hier.

So recht glauben mag ich das alles noch nicht, es geht irgendwie zu schnell jetzt. Allerdings......
"in echt" dagegen habe ich auch nichts!
Grüße, picass

Hallo
Vielleicht mal ein eigenes Thema dafür aufmachen, wenn es hauptsächtlich
um MMBasic geht, dann geht das nicht in dem langen Thread unter.

Euer ADMIN.

Dran gedacht hatte ich gestern Abend beim Einstellen auch, aber...
Aber das wirft für mich grundsätzliche Fragen auf, wie z.B. die hier:
Je nachdem, mit welcher Einstellung man Inhalte auf einen übergeordneten Begriff - wie auch eine Überschrift - runterbricht, kann man sehr wohl zu der Auffassung gelangen, es würden Berichte über forenfremde µC's - also keine PICs - eingestellt. Da frage ich doch mal ganz vorsichtig, ob das auch erwünscht ist oder nicht.
Grüße, picass

Das ist schon richtig das es ein PIC Forum ist.
Nun gibt es Programmiersprachen und Programme die auch mehrer Controller Familien
unterstützen. Wenn du einen AVR in deiner Sprache programmierst, so kann einer der nur Pic
programmiert in deiner Sprache, dir genauso helfen weil es eine gemeinsame Basis gibt. Da sind
die Unterschiede nicht so gross und andere mit dem selben Wissen in dieser Programmiersprache
können dann Hilfe leisten.
Aber ich würde für jede neue Funktion einen eigenen Thread aufmachen. Wenn du alles in einem
Thraed machst, so ist es schwer etwas zu finden. Und keiner liest einen Thread der über 100 Beiträge
durch, nur um etwas über die Ansteuerung von einem OLED zu finden. Da ist es dann übersichtlicher
wenn du dann dies in einem eigenen Thread machst und jeder kann direkt an der Überschrift sehen
worum es in diesem geht. Aber das überlass ich euch selber wie ihr es macht. Ich gebe dazu
keine Vorgaben.

Euer ADMIN.

Ich habe jetzt auch mal in C gerechnet. Ich will zwei 8 Bit Zahlen multiplizieren und als Ergebnis eine 16 Bit Zahl. Früher hatte ich solche Sachen mit einem Assembler Programm gemacht und dieses unter C aufgerufen.
Das lief sehr gut. Nun hatte ich gedacht, der C-Compiler müsste eigentlich die Grundrechenarten beherrschen, wobei ich auch noch mit ganzen Zahlen arbeite.
Ich hatte folgenden Code probiert:

typedef struct {    //für zwischenspeicher h/min
    int hour;  // uint8_t hour   --funktioniert nicht
    int minute;// uint8_t minute -- funktioniert nicht 
}timeHM_t;
timeHM_t xminuten;
xminuten.hour = 22;
xminuten.minute = 35;
minuten = (xminuten.hour*60)+xminuten.minute;
printOut(
         "%i",
         minuten);
hex_dec_ausg(minuten);

Die printOut() Funktion ist nach dem Prinzip printf() aufgebaut und hat versagt. Es wird nur da Lo-Byte vom Ergebnis angezeigt und ein falsches Hi-Byte.
Nach langen überlegen hatte ich meine eigene Routine genommen. Ich hatte sie hex-dec-ausgabe genannt. Sie mit der Funktion itoa() und Stringausgabe programmiert. Das hat funktioniert.
Allerdings muss ich die Stunden und Minuten als Integer (16Bit) definieren. Um Speicher zu sparen läuft das ganze in meinen Programm aber mit 8 Bit und als Ergebnis will ich 16 Bit. Das bekomme ich aber so nicht gebacken. Hat jemand eine Idee wie ich zwei 8 Bit Zahlen multipliziere und als Ergebnis eine 16 Bit Zahl bekomme? Bei 8 Bits stimmt da Hi - Byte vom Ergebnis wieder nicht!

Das hat mir jetzt keine Ruhe gelassen. Ich habe es nochmal mit uint8_t (8 Bit) probiert. Überall vorher habe ich (int) davor geschrieben. Jetzt funktioniert meine printOut() Funktion und meine alternative Funktion.

            if ((UBAMonitorFast.leistungIst)==0 && (pi_alt >4)){    //>4 bei Start auf 5 initialisiert
                pi_alt = UBAMonitorFast.leistungIst;
                xminuten.hour = 22;
                xminuten.minute = 35;
                Ta.hour = RCTime.stunden;
                Ta.minute = RCTime.minuten;
                minuten = (int)(xminuten.hour*(int)60)+(int)xminuten.minute;
            printOut(
                        "\t7%bu:%bu\t>%i\n",
                        Ta.hour, Ta.minute,minuten);
            hex_dec_ausg(minuten);
            LCD_cr();
            }

Das Witzige ist, wenn ich vor der 60 (int) weglasse, dann bekomme ich als Ergebnis 75 jeweils angezeigt. Das ist der Wert des Low-Byte.

minuten = (int)(xminuten.hour*60)+(int)xminuten.minute;// Ergebnis 75, 0x4b anstatt 0x054b

Zitat von: pic18 in 06.01.2023, 22:27:12 CETDas Witzige ist, wenn ich vor der 60 (int) weglasse...

Meiner Meinung nach ist das ganz normal. Das Ergebnis einer Operation hat den größten der Datentypen der Operanden, unabhängig davon, welchen Datentyp die Variable hat, in der dieses Zwischen-Ergebnis dann gespeichert wird.

Sind beide 8-Bit, dann wird das Zwischen-Ergebnis eben auch in 8-Bit rein gequetscht und erst danach in einer Variablen mit möglicherweise ausreichend großem Typ gespeichert

Casted man einen der Operanden auf 16-Bit, dann wird auch das Zwischen-Ergebnis mit 16-Bit berechnet...

ich habe alle Möglichkeiten ausprobiert, es muß immer die 60 gecasted werden. Alle anderen Operanten sind egal.

minuten = (int)xminuten.hour*60 + xminuten.minute;

funzt nicht?

Seltsam, mit dem XC8 bekomme ich es gar nicht hin ein falsches Ergebnis zu bekommen,
egal, ob cast oder nicht.

Was für einen C-Compiler benutzt du?

nein, muß immer (int)60 sein. Wobei ich mit jetzt gar nicht sicher bin ob int 2 oder 4 Byte sind. Short sollte nämlich 2 Byte sein. Ich benutze den alten c8? Compiler.

Beim C18 sind short und int beide 16bit.

Bei mir funktioniert das mit dem cast auch beim C18 (v3.40) egal wo...

seltsam, ich habe den C18 Compiler.
Mein Programm macht auf jeden Fall das was es soll

       case ausg_schalthys:
            stdOut_mr =stdOut;
            stdOut = source_lcd;
            
            //printOut("schalthys\n");
            if ((UBAMonitorFast.leistungIst>0) && (pi_alt <20)){
                pi_alt = UBAMonitorFast.leistungIst;
                Te.hour = RCTime.stunden;
                Te.minute = RCTime.minuten;
                printOut(
                        "%bu:%bu",
                        Te.hour, Te.minute);
            }
            if ((UBAMonitorFast.leistungIst)==0 && (pi_alt >4)){    //>4 bei Start auf 5 initialisiert
                pi_alt = UBAMonitorFast.leistungIst;
                Ta.hour = RCTime.stunden;
                Ta.minute = RCTime.minuten;
                minuten = ((int)60*((int)Ta.hour-(int)Te.hour)+Ta.minute-Te.minute);
                printOut(
                            "\t7%bu:%bu\t>%i\n",
                            Ta.hour, Ta.minute,minuten);
                //hex_dec_ausg(minuten);
                //LCD_cr();
                }
            
            stdOut = stdOut_mr;
            break;

Zitat von: pic18 in 08.01.2023, 19:38:49 CETseltsam, ich habe den C18 Compiler.
Mein Programm macht auf jeden Fall das was es soll

Auch Umwege führen nach Rom