Forum: Mikrocontroller und Digitale Elektronik PIC 32 schneller Basic Interpreter


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Micromite (Gast)


Lesenswert?

Geoff hat den schnellen Basic Interpreter in einem PIC 32 nach der 
Betaphase nun öffentlich gemacht.

DS18b20, Servomotoren, RTC, Analog In, Interrupts,SPI, LCD Displays, 
RS232.... alles integriert und mit minimalstem Aufwand programmierbar.
Funkmodule werden im nächsten Step integriert.
Eine Veröffentlichung gibt's auch in der aktuellen Silicon Chip.

Terminal (Putty o.ä. dran) und der Inline Editor lässt sich sofort 
nutzen um Programme zu schreiben und im Flash zu speichern.
Eine Autorun Funktion macht alles automatisch startbar.

http://geoffg.net/micromite.html

Schaut Euch das mal an, macht riesig Spass!

von Micromite (Gast)


Lesenswert?

Micromite Features

A fast 32 bit CPU with 128K of flash and 32K RAM running a powerful 
BASIC interpreter. 20KB of non volatile flash memory is reserved for the 
program. 22KB of RAM is available for BASIC variables, arrays, buffers, 
etc. This is sufficient for quite large BASIC programs up to 1000 lines 
or more.
The Microsoft compatible BASIC interpreter is full featured with 
floating point and string variables, long variable names, arrays of 
floats or strings with multiple dimensions, extensive string handling 
and user defined subroutines and functions. Typically it will execute a 
program at 23,000 lines per second.
Nineteen input/output pins are available on the 28 pin chip. These can 
be independently configured as digital input or output, analog input, 
frequency or period measurement and counting. Ten of the pins can be 
used to measure voltages and another seven can be used to interface with 
5V systems. MMBasic can also be installed on the 44 pin version of the 
chip providing 33 input/output pins.
Programming and control is done via a serial console (TTL voltage 
levels) at 38400 baud (configurable). Once the program has been written 
and debugged the Micromite can be instructed to automatically run the 
program on power up with no user intervention. Special software is not 
needed to develop programs.
A full screen editor is built into the Micromite. This only requires a 
VT100 terminal emulator and can edit a full 20KB program in one session. 
It includes advanced features such as search and copy, cut and paste to 
and from a clipboard.
Easy transfer of programs from another computer (Windows, Mac or Linux) 
using the XModem protocol or by streaming the program over the serial 
console input.
Input/Output functions in MMBasic will generate pulses (both positive 
and negative going) that will run in the background while the program is 
running. Other functions include timing (with 1 mS resolution), BASIC 
interrupts generated on any change on an input pin and an internal real 
time clock.
A comprehensive range of communications protocols are implemented 
including I2C, asynchronous serial, RS232, IEEE 485, SPI and 1-Wire. 
These can be used to communicate with many sensors (temperature, 
humidity, acceleration, etc) as well as for sending data to test 
equipment.
Built in commands to directly interface special devices such as infrared 
remote controls, the DS18B20 temperature sensor, LCD display modules, 
battery backed clock, distance sensors, numeric keypads and more.
Up to five PWM or SERVO outputs can be used to create various sounds, 
control servos or generate computer controlled voltages for driving 
equipment that uses an analogue input (eg, motor controllers).
Special embedded controller features in MMBasic allow the clock speed to 
be varied to balance power consumption and speed. The CPU can also be 
put to sleep with a standby current of just 80µA. While in sleep the 
program state and all variables are preserved. A watchdog feature will 
monitor the running program and can be used to restart the processor if 
the program fails with an error or is stuck in a loop.
The running program can be protected by a PIN number which will prevent 
an intruder from listing or modifying the program or changing any 
features of MMBasic.
Power requirements are 2.3 to 3.6 volts at 5 to 25mA.
Remember, all of the above features are internal to the Micromite. The 
only extra component required is a 47µF capacitor.

von Jens P. (picler)


Lesenswert?

Micromite schrieb:
> DS18b20, Servomotoren, RTC, Analog In, Interrupts,SPI, LCD Displays,
> RS232.... alles integriert und mit minimalstem Aufwand programmierbar.

Für das oben stehende brauche ich keinen umständlichen PIC32, das stemme 
ich mit dem PIC18 in ASM. Wenn ich einen 32bitter nehme brauche ich den 
für Rechenleistung pur. Das passt aber nicht mit Basic Interpreter 
zusammen. Wenn schon Hochsprache, dann C. Mag ich zwar auch nicht 
wirklich, ich will die Kontrolle über jedes Register selber haben, aber 
was solls. Klar gibt es Leute, die eine LED mit 32 Bit blinken lassen...

von ulrich (Gast)


Lesenswert?

Einen Basic Interpreter für einen µC braucht man eher nicht, wenn es 
auch Compiler gibt. Ein Compiler kann einfach schneller sein, und mehr 
Fehler vorab finden.

von old school boy (Gast)


Lesenswert?

Für das oben stehende brauche ich keinen umständlichen PIC32,
>> Was umständlicher ist liegt doch wohl auf der Hand

das stemme ich mit dem PIC18 in ASM.
>> na dann stemm mal weiter bis der Schweiß rinnt ;-)

Wenn ich einen 32bitter nehme brauche ich den
für Rechenleistung pur. Das passt aber nicht mit Basic Interpreter
zusammen.
>> Natürlich ist ein Compiler schneller, na und ?

Wenn schon Hochsprache, dann C. Mag ich zwar auch nicht
wirklich, ich will die Kontrolle über jedes Register selber haben, aber
was solls.
>> Kenn ich aus dem Bekanntenkreis, nennt man Kontrollzwang

Klar gibt es Leute, die eine LED mit 32 Bit blinken lassen...
Einen Basic Interpreter für einen µC braucht man eher nicht, wenn es
auch Compiler gibt.

>> Die LED blinkt dann schon, während dein Compiler noch compiliert
und das Flash beackert..., 8/16/32 oder 64 Bit ist Latte


Ein Compiler kann einfach schneller sein,
>> wie gesagt...


und mehr Fehler vorab finden.
>> NACK
;-)

von Micromite (Gast)


Lesenswert?

Um den DS18B290 auszulesen bedarf es einer Zeile Code:


PRINT "Temperature: " DS18B20(pin)

Ich find's cool....

Und ums auf ein LCD Display zu bringen:

LCD INIT 2, 3, 4, 5, 23, 24
LCD 1, 2, "Temperature"
LCD 2, 6, STR$(DS18B20(15))


;-)

von Micromite (Gast)


Lesenswert?

Und einen Modelbauservo lassen wir dann so Winke Winke sagen:


DO
SERVO 1, 0.8, 2.2
PAUSE 5000
SERVO 1, 2.2, 0.8
PAUSE 5000
LOOP

Das Poti durch Zwei Widerstände ersetzt, lässt die Servogeschwindigkeit 
für einen Roboterantrieb (Drehzahlregelung) herhalten.

Und mit dem Ultraschall Entfernungsmesser (HC-SR04) ein paar Cent in der 
Bucht.., messen wir Entfernungen zu Gegenständen.


d = DISTANCE(trig, echo)


Fertig ist der Roboter.

Mit dem eingebauten IR Routinen lässt er sich auch mit Deiner TV 
Fernbedienung steuern.

Profis nutzen aber Compiler dazu und Hardcore "C"..

Das hier ist natürlich nix für Männer die Bienen kauen, sondern nur für 
die Honiglutscher ;-)

von Nobby Nic (Gast)


Lesenswert?

Respekt was der Ruheständler da erschaffen hat. Die Idee mit Roboter 
usw. gefällt mir, das könnte für meinen Junior einen spielerischen 
Einstand in die Elektronikbastelei ergeben :-)

von Micromite (Gast)


Lesenswert?

Nicht das der Junior sich langweilt....

von CBRler (Gast)


Lesenswert?

@ Micromite,

sehe es eigentlich genau so, wie du es beschreibst...
Ich mache mit AVR und Bascom: und das schnell und mit den geforderten 
Resultaten.

Ich amüsiere mich immer über die Listings der C-Junkies, die es mit 2 
DIN-A4 Seiten Listing dann doch schaffen, eine COM-Schnittstelle 
anzusprechen, oder einen Servo zu steuern.

Ich tendiere da lieber zu Einzeilern und kann schnell geforderte 
Ergebnisse vorweisen....
Wenn schon ins Eingemachte gehen, dann mit Assembler; einfach ins 
Bascomlisting einbinden.

cu
CBRler

von Micromite (Gast)


Lesenswert?

Pragmatismus kann schon ne gute Sache sein;-).
Schau Dir das mal an, ist wirklich cool gemacht und rasend schnell für 
einen Interpreter.

25000 Zeilen pro Sekunde, bei meinen Basteleien werd ich da nie ein 
Geschwindigkeitsproblem haben, falls doch gibt's eben Alternativen.

RS232, PWM und der ganze Kram läuft hier eh im Hintergrund über die 
Hardware des PIC, gepuffert und stabil.

Das alles für 2.50€, das kostet der PIC, Samples rückt Microchip 
kostenlos raus, auch den 44 Pin Chip.
Hab mir in der Bucht dafür eine TQFP / DIL Adapterplatine gekauft, für 
1€;-).

DS

von Bernie (Gast)


Lesenswert?

"Das alles für 2.50€, ..."

@ Micromite

Wo kaufst du den Chip für 2,50 Euro? Wie kann kostengünstig der 
Interpreter geflasht werden?

von Max H. (hartl192)


Lesenswert?

Bernie schrieb:
> Wie kann kostengünstig der
> Interpreter geflasht werden?
PICkit3 China Clone, das ist eine einmalige Investition. Wenn du das 
dazurechnen willst, dann bitte auch den Lötkolben und vllt. auch noch 
den PC,...

: Bearbeitet durch User
von Nobby Nic (Gast)


Lesenswert?

> Nicht das der Junior sich langweilt....

Das tut er nicht, aber manche Zusammenhänge sind für 10-jährige noch 
etwas zu komplex. Und mit Basic hab ich vor Urzeit auf einem ZX81 auch 
angefangen ;-)

von Bernie (Gast)


Lesenswert?

Max H. schrieb:
> Bernie schrieb:
>> Wie kann kostengünstig der
>> Interpreter geflasht werden?
> PICkit3 China Clone, das ist eine einmalige Investition. Wenn du das
> dazurechnen willst, dann bitte auch den Lötkolben und vllt. auch noch
> den PC,...

Danke f. d. Antwort.

Wie viele Firmen hast du mit deiner Kalkulationsmethode bereits zugrunde 
gerichtet?

von Max H. (hartl192)


Lesenswert?

Bernie schrieb:
> Wie viele Firmen hast du mit deiner Kalkulationsmethode bereits zugrunde
> gerichtet?

Moment... Lass mich nachzählen...
...
...
Null.

von Joerg (Gast)


Lesenswert?

Nobby Nic schrieb:
> Das tut er nicht, aber manche Zusammenhänge sind für 10-jährige noch
> etwas zu komplex. Und mit Basic hab ich vor Urzeit auf einem ZX81 auch
> angefangen ;-)

Darum geht's doch: Schnelle Erfolgserlebnisse, mal was probieren, es 
funktioniert.

Nichts ist frustrierender, wenn man ewig frickeln muss, bis mal was 
geht, besonders in den jungen Jahren. Da fliegt das dann schnell in die 
Ecke und das Smartphone ist interessanter. Und Nachwuchs wollen wr doch, 
oder?

Grüße!

P.S.: Hab auch mit dem ZX81 (Bausatz!) angefangen...

von Micromite (Gast)


Lesenswert?

Ich mit Apple II

von Nobby Nic (Gast)


Lesenswert?

Joerg schrieb:

> Und Nachwuchs wollen wr doch, oder?

Und wenn es ihm nur als Hobby Spaß macht ist es auch ok.

> P.S.: Hab auch mit dem ZX81 (Bausatz!) angefangen...

Ne, meiner war bereits fertig aufgebaut. Dafür musste ich mir dann mit 
einem Mini-Langenscheidt die Bücher übersetzen. Das Englisch der 5. 
Klasse war damals (TM) noch nicht ausreichend um Rodney Zaks 
"Programming the Z80" zu verstehen.

von Bernd R. (Firma: Promaxx.net) (bigwumpus)


Lesenswert?

Hört sich doch geil an !
Bevor ich (als PIC-Nutzer) in die Niederungen der ASM-Programmierung 
absteige, würde ich sowas hier jedem empfehlen, der einfach eine Lösung 
sucht und nicht ein Glaubensbekenntnis.
Für kleine Quick-n-Dirty-Projekte sicher nicht falsch !

von Micromite (Gast)


Lesenswert?

Quick, ja
Dirty, nein!

von Micromite (Gast)


Lesenswert?

Ich bin mit dem Pickit 3 von Olimex sehr zufrieden.

Obgleich der auch nur ein paar Euronen preiswerter war, als das 
Original.

Für den Micromite benötigt man den PIC32 und einen externen Kondensator, 
fertig.

Firmware runterladen und mit Pickit brennen.
Serielle Schnittstelle dran, reset und der Mmbasic Prompt erscheint.
Die Servos zappeln dann nach einer Programmzeile.

Das ist Rapid deployment.

Ich erinnere mich noch an die alten ( 80'er) Nixdorf ERP Lösungen, 
welche teils komplett im Interpreter liefen.

Schwups wurde zur Laufzeit ein neues Feature implementiert.

Was bequemeres gibt's doch gar nicht;-)

von Carsten S. (dg3ycs)


Lesenswert?

Hi,

CBRler schrieb:
> Ich amüsiere mich immer über die Listings der C-Junkies, die es mit 2
> DIN-A4 Seiten Listing dann doch schaffen, eine COM-Schnittstelle
> anzusprechen, oder einen Servo zu steuern.

Ich weiß ja nicht WAS du so für Listungs gesehen hast oder für welche 
Architektur, aber zwei Seiten braucht man auch in C nicht um eine 
Schnittstelle anzusprechen.
Ein komplett lauffähiges Programm (incl. aller Einstellungen) sieht z.b. 
so aus:
1
// Includes einmalig am Quellcodebeginn
2
#include <p32xxxx.h>    // Generelle PIC32MX Lib  
3
#include <plib.h>    // Lib für Peripheriefunktionen
4
#include <uart2.h>    // Lib für die UART Schnittstelle 2  
5
6
// Defines zur korrekten Parametrierung der Schnittstelle (einmalig) 
7
#define GetSystemClock()                60000000UL
8
#define GetPeripheralClock()        60000000UL
9
#define GetInstructionClock()         (GetSystemClock() / 2)
10
 
11
#define BAUDRATE2           115200UL
12
#define BRG_DIV2            4 
13
#define BRGH2               1 
14
15
//Programmbeginn
16
void main()
17
{
18
  while(1) UART2PrintString( " *** Hallo Welt *** \r\n" );
19
}

Was natürlich noch nötig ist, das ist das setzen der Config Fuses. Das 
geschieht in diesem Fall im entsprechenden Menü von MPLAB.
Will man das im Code erledigen kommen die Zeilen halt noch dazu...

(Wenn man weitestgehende Plattformunabhängigkeit sucht, -was bei Bascom 
oder Micromite ja absolut nicht möglich ist- wird es minimal 
aufwendiger, dann würde man die µC Spezifischen Funktionen in eigenen 
Funktionen verstecken und dann im Programm nur die eigenen Funktionen 
aufrufen.
Dann müssten jeweils bei einer Portierung nur einmalig die eigenen 
Funktionen angepasst werden. Aber das ist hier wie gesagt irrelevant 
weil die Basic Varianten diese Möglichkeit ja überhaupt nicht bieten.)

Wie sähe denn ein KOMPLETTES Bascom Programm mit dieser Funktionalität 
überhaupt aus?

Aber darauf wollte ich eigentlich nicht hinaus, denn generell finde ich 
"Micromite" gar nicht so schlecht wie manche es darstellen.
Gerade für das Beispiel mit dem "Zehnjährigen Ersteinsteiger" finde ich 
solche "ready to use" Interpreter sehr gut. Vielleicht noch ein wenig 
besser als Basic Compiler. Oder halt für den Hobbyisten der nur mal kurz 
für ein einziges Projekt eine µC Funktionalität braucht und bereits 
jetzt schon weiß das er das nächste mal in vielen Monaten - wenn nicht 
sogar JAhren- wieder an diesem Punkt sein wird. Wenn überhaupt.

Dies sind alles Fälle wo "Micromite" oder meinetwegen auch "Bascom" 
durchaus das Mittel der Wahl sein können.

Völlig anders sehe ich das aber wenn jemand sich dauerhaft mit µC 
beschäftigen will und auch schon in Mathe etwas weiter als bei den 
Grundrechenarten ist...
Ich sage mal so ab 13 - 16 (je nach individueller Begabung) aufwärts...
Und erst recht wenn jemand schon weiß das er mal beruflich in diese 
Richtung gehen will! Da sollten dann die Basic Varianten sofort aussen 
vor bleiben!

Aber generell ist das ein "Äpfel mit Birnen" Vergleich, denn weder 
Bascom und erst recht nicht Micromite sind mit einer Programmentwicklung 
in C vergleichbar. Denn die "Einfachheit" der Funktionen ist nur deshalb 
gegeben weil die Ersteller der Sprache dem Programmierer eine Menge an 
Parametrierung abgenommen haben. Dadurch ist der Programmierer aber auch 
an die Vorgaben weitgehend gebunden, eine auch nur annähernd so große 
Vielfältigkeit wie in C ist einfach nicht möglich.
Solange es aber nur fürs Hobby ist und keine Ambitionen zu "mehr" 
dahinterstecken reicht das aber dann oft doch aus.

Wer allerdings ernsthaft der Meinung ist das man mit Bascom oder 
Micromite auch professionelle Entwicklungen realisieren kann, der hat 
einfach den Schuss nicht gehört! Wer soetwas in einem 
Angestelltenverhältniss oder bei Auftragsentwicklungen ernsthaft in 
erwägung zieht, der gehört definitiv schnellstens "entsorgt". Denn in 
aolchen Fällen spielt viel mehr mit als nur die Frage ob die Funktion 
irgendwie erreicht werden kann.
Deshalb: Äpfel & Birnen -> Jeder Vergleich erübrigt sich!

Gruß
Carsten

von Stefan (Gast)


Lesenswert?

Carsten Sch. schrieb:
> Wer allerdings ernsthaft der Meinung ist das man mit Bascom oder
> Micromite auch professionelle Entwicklungen realisieren kann, der hat
> einfach den Schuss nicht gehört! Wer soetwas in einem
> Angestelltenverhältniss oder bei Auftragsentwicklungen ernsthaft in
> erwägung zieht, der gehört definitiv schnellstens "entsorgt"

Selten so einen Schwachsinn gelesen.
Scheinst nicht viel Ahnung zu haben.
Aber ist ja hier mitlerweile üblich das auch
Trolle hier schreiben dürfen.

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Naja, hängt von der konkreten Aufgabenstellung ab. Ein Interpreter hängt 
nicht so leicht hin, da er eine Art Betriebssystem realisiert. Was auch 
völlig vergessen wurde: Die Arbeit die der Interpreter-Entwickler schon 
reinsteckte, kann sich der Endentwickler zumindest in einem beachtlichen 
Reamortisierungsbereich sparen!

Dieses Nixdorf-Dingens: Kannst du da noch einige Sätze zu schreiben? 
Danke! Just for fun und weil früher heute oft vergessene interessante 
Ansätze vorhanden waren. Die man eventuell wieder verfolgen könnte.

Zur Laufzeit Funktionalität ändern, ist eigentlich nur mit einem 
Interpreter wie BASIC oder Forth machbar. Außer man baut gleich ein 
komplettes BS hinzu und freundet sich dann mit Konzepten wie DLLs an.

von Micromite (Gast)


Lesenswert?

Nixdorf...

Also ich hatte nicht direkt mit der ERP Lösung zu tun.
Bin mir aber sicher das es ein Basic Dialekt war und ein Unix drunterlag 
mit dem ich dann mehr zu tun hatte.
Ein damaliger Freund von mir hatte aber tiefe Kenntnisse im ERP Bereich.
In den 70/80 er Jahren war Nixdorf europaweit Marktührer in diesen 
Segmenten.

Wer hier mit solch irrsinnigen Brandbriefen wie 2 Threads weiter oben 
gegen interpretierende Systeme wettert, an dem sind diese Zeiten 
offenbar in jeder Hinsicht einfach vorbeigegangen. Im historischen Sinne 
hat er wirklich wenig Hintergrund; schade.

Es geht halt auch viel Wissen immer wieder verloren und man kann nur 
hoffen das es nicht gänzlich verloren geht.
Eine Entwickelung die ich in vielen Bereichen der IT sehe.
Nach einem Generationenwechsel fangen ganze Unternehmensbereiche oft 
wieder "von vorn" an.

D

von patsch007 (Gast)


Lesenswert?

Stefan schrieb:
> Carsten Sch. schrieb:
>> Wer allerdings ernsthaft der Meinung ist das man mit Bascom oder
>> Micromite auch professionelle Entwicklungen realisieren kann, der hat
>> einfach den Schuss nicht gehört! Wer soetwas in einem
>> Angestelltenverhältniss oder bei Auftragsentwicklungen ernsthaft in
>> erwägung zieht, der gehört definitiv schnellstens "entsorgt"
>
> Selten so einen Schwachsinn gelesen.
> Scheinst nicht viel Ahnung zu haben.
> Aber ist ja hier mitlerweile üblich das auch
> Trolle hier schreiben dürfen.

GG Ich würde gern mal ein Produkt sehen wo jemand auf einem µC einen 
Interpreter verwendet.
Ich weiß es von meinem Job es gilt immer:
*wenig Flash und RAM zur Verfügung
*immer den kleinsten µC nehmen (größe und Performance)
*und kosten darf es auch nichts
*Spezialisierte und aufwendig getestete Bootloader usw

Daher ist C fast Standart + hin und wieder etwas Assembler.

von Nofretete (Gast)


Lesenswert?

patsch007 schrieb:
> GG Ich würde gern mal ein Produkt sehen wo jemand auf einem µC einen
> Interpreter verwendet.
> Ich weiß es von meinem Job es gilt immer:
> *wenig Flash und RAM zur Verfügung
> *immer den kleinsten µC nehmen (größe und Performance)
> *und kosten darf es auch nichts
> *Spezialisierte und aufwendig getestete Bootloader usw
>
> Daher ist C fast Standart + hin und wieder etwas Assembler.

und genau das ist im Hobbybereich völlig wurscht.
Für jungfräuliche Anfänger ist solch ein kleiner Interpreter eine prima 
Sache um damit zu spielen. Der nächste Schritt wäre dann aber 
keinesfalls bascom, nie und nimmer würde ich das meinen Kindern antun 
wollen. Bascom versaut den Stil. Das sieht man schön daran, wenn Leute 
von Bascom auf was Anderes umsteigen, z.B. C. Sie bauen dann 
Bascom-Programme in C, legen für jeden Rechenschritt neue Variablen an 
usw., da weiß man nicht ob man lachen oder weinen soll.

von Carsten S. (dg3ycs)


Lesenswert?

Micromite schrieb:
> Wer hier mit solch irrsinnigen Brandbriefen wie 2 Threads weiter oben
> gegen interpretierende Systeme wettert,

Zwei Beiträge weiter oben, also meinst du mich nehme ich an...
Ich frage mich aber ob bei dir ein völlig anderer Text angezeigt wird 
als bei mir, denn ich habe keineswegs gegen interpretierende Systeme 
gewettert, ja gerade auch Mircomite für bestimmte Anwendungen sogar für 
gut befunden!

Lediglich bei professionellen Anwendungen ist es ein NoGo und für diesen 
Bereich habe ich das ganz klar so geschrieben.

> an dem sind diese Zeiten offenbar in jeder Hinsicht einfach
> vorbeigegangen.

Hhmm, die Zeiten sind an mir vorbeigegangen weil ich der Meinung bin das 
in professionellen (kommerziellen) Entwicklungen unperformante, auf 
einen bis wenige Typen eingeschränkte Sprachen mit auch noch unbekannter 
"Lebensdauer" der Sprache einfach nichts verloren haben?

Interessante Meinung. Aber wir haben ja Meinungsfreiheit...

Ich bin schon eine Zeitlang in diesem Bereich tätig und habe schon so 
einiges Erlebt.
Sich in der Endphase plötzlich ändernde Anforderungen an die Hardware 
oder enorme Lieferverzögerungen für bestimmte µC sind da doch nun 
wirklich nichts besonderes.
Aber einfach mal den µC umschwenken ist da ja nicht! Oder was ist wenn 
-wie es häufiger vorkommt- ein neuer Nachfolgetyp für den verwendeten µC 
auf den Markt kommt der bei weniger Energieverbrauch auch noch deutlich 
weniger kostet, dazu aber noch breiter eingesetzt werden kann - Aber der 
Ersteller der Sprache keine Weiterentwicklung mehr betreibt, diesen 
Controller also nicht unterstützt?

Das würde bedeuten alles neu schreiben oder auf ewig auf dem immer 
teurer werdenden Controller sitzenbleiben und hoffen das er ja nicht 
endgültig abgekündigt wird... Und so kann man die Liste ewig fortführen.

Zudem weiß ich ganz genau was mein Cheffe (wohl praktisch jeder Chef) 
sagen würde wenn ich einen recht teuren und vor allem Energiehungrigen 
PIC32 einsetze um mit Basic dort die nötige Leistung zu haben, wo in C 
ein Feld, Wald& Wiesen 8Bit µC mit extrem wenig Energieverbrauch bereits 
ausreichende Leistung bereitstellt.

Im Hobbybereich spielen solche Überlegungen manchmal kein Rolle, deshalb 
ist der Einsatz dieser Sprache dort ja von mir ausdrücklich auch als 
Möglichkeit genannt worden. Aber im Professionellen Bereich sind das bei 
fast jedem Projekt wichtige Grundkriterien.
Und nochmal: ICh bin nur strikt gegen den Einsatz im Professionellen 
Bereich - Im Hobbybereich soll jeder das nehmen wo er am schnellsten mit 
zum Ziel kommt.

> Im historischen Sinne  hat er wirklich wenig Hintergrund;
> schade.
Auch wenn ich vom Jahrgang (79) noch nicht zum wirklich alten Eisen 
zähle, so habe schon einiges auch an historischem Hintergrund. Auch und 
gerade im Basic Bereich. Schließlich bin ich mit C64 und Schneider CPC 
aufgewachsen... Habe auch selbst schon mit Basic Interpreter auf µC 
gearbeitet. Zwei Boards mit 8052AH liegen hier noch im Schrank...
Aber ich kenne nicht nur die Historie sondern auch die Möglichkeiten der 
aktuellen Entwicklungswerkzeuge. Und weiß daher wie groß die 
Unterschiede doch sind. Wobei auch die 8052AH immer nur eine absolute 
Randerscheinung geblieben sind. Selbst zu den Zeiten wo die 
Programmentwicklung in den anderen Sprachen bei weitem nicht so einfach 
war wie heute. ASM war ja noch vielfach das Mittel der Wahl und 
ergänzende Frameworks wenn vorhanden nur sehr Rudimentär.

Aber noch einmal: Wem das Basic, egal ob Compiler oder Interpreter, fürs 
Hobby ausreicht - OK.
Fürs den Erstkontakt von interessierten Kindern bis einschließlich dem 
"Unterstufenalter" sogar sehr gut geeignet. Besonders als Interpreter.
Aber mehr ist da nicht mehr!
Denn für die Restlichen Anwendungen ist es einfach Schnee von gestern!

> Es geht halt auch viel Wissen immer wieder verloren und man kann nur
> hoffen das es nicht gänzlich verloren geht.
> Eine Entwickelung die ich in vielen Bereichen der IT sehe.
> Nach einem Generationenwechsel fangen ganze Unternehmensbereiche oft
> wieder "von vorn" an.

Ich sehe hier bei diesem Thema kein "Industrienützliches Wissen" das 
irgendwie verloren gehen könnte... Das klingt für mich einfach nur nach 
"früher war alles besser"

Stefan schrieb:
> Selten so einen Schwachsinn gelesen.
> Scheinst nicht viel Ahnung zu haben.
> Aber ist ja hier mitlerweile üblich das auch
> Trolle hier schreiben dürfen.

Schau mal: Das bellen eines getroffenen Hundes?

Gruß
Carsten

: Bearbeitet durch User
von Micromite (Gast)


Lesenswert?

Maxitexter...

von Ulrich H. (lurchi)


Lesenswert?

Wenn es einen vernünftigen Compiler gibt, ist ein Interpreter auf den µC 
eigentlich der falsche Weg. 23000 Zeilen / Sekunde mögen für einen 
Interpreter schnell sein, für einen compilierten Code ist das langsam.

Wirkliche Vorteile hat so ein Interpreter ähnlich wie BASCOM wenn da 
auch spezielle vorgefertigte Funktionen zurückgegriffen werden kann. Das 
kann man so ähnlich mit einem C++ Compiler mit dem Arduino haben - dann 
aber schneller und sogar relativ portabel.

Wenn die vorgefertigten Teile nicht passen, hat man aber mit dem 
Interpreter oder dem speziellen Basic Dialekt die A.-Karte gezogen. Für 
ein paar passende Demos ist das gut, aber für ein Produkt das ggf. 
später angepasst werden muss ist das riskant: Wenn man es dann doch von 
Hand machen muss, wird es gleich viel langsamer und länger. Auf einen 
größeren / schnelleren µC ausweichen geht dann oft auch nicht, weil es 
dafür die Sprache nicht gibt.

Das Problem ist nicht Basic an sich, sondern der Versuch eine brauchbare 
Performance des Compilers durch spezielle Spracherweiterungen zu 
ersetzen. Die Spracherweiterung können aber nicht alles abdecken, und 
eine große Sammlung spezieller Funktionen, die man nur sehr selten 
braucht sind ein Einladung für Bugs. Wenn denn die rohe Performance 
stimmen würde, wäre das noch nicht so schlimm, weil man es notfalls von 
Hand machen könnte - bei Bascom Compiler kann man wenigstens noch gut 
ASM Integrieren, aber bei einem lahmen Interpreter ...

von NoOne (Gast)


Lesenswert?

Micromite schrieb:
> Maxitexter.

Du hast aber garnichts verstanden. Du verhälst Dich wie ein blindes 
Huhn, das nichts von der Welt sehen möchte, wie sie ist.

Carsten Sch. schrieb:
> bei professionellen Anwendungen ist es ein NoGo

Volle Zustimmung!

Ulrich H. schrieb:
> dem speziellen Basic Dialekt die A.-Karte gezogen

Wenn man, wie ich, vor über 30 Jahren, mit Basic anfängt Programme zu 
schreiben, dann ist der Programmierstil mehr als versaut. Mich hat es 12 
Monate gekostet, auf C umzusteigen. Was habe ich am Anfang einen Scheiß 
in C zusammen gecoded. Ja, es war am Anfang nur Basic-C-Müll. Aber das 
will die Basic-Fraktion nicht wahrhaben. Ich sage NICHT, dass Basic 
schlecht wäre. Jedoch muss ich sagen, dass man mit Basic 400% über der 
Hardware hängt.
Vom Programmierstil ganz zu schweigen.
Aus meiner Sicht, tut sich niemand einen Gefallen, auch nicht im 
Hobbybereich, mit irgend einem Basic anzufangen. Ich spreche hier 
ausschliesslich für den Bereich uC. Großrechner, ab 100 GFlops, mal 
ausgenommen, denn dort "verdeckt" das OS die Hardware. Und auf solchen 
Systemen interessiert die HW auch keinen wirklich.

Wer aber seine Hardware, wie hier dezidiert angesprochen, wirklich zu 
100% wirklich verstehen will, der kommt an C oder dem Assembler nicht 
vorbei.
Sicher ist es richtig, dass für den Anfänger ein Basic evt. die richtige 
Wahl ist, aber er wird dadurch am Anfang nie verstehen, wie alles 
wirklich abläuft. Und wie man auf dieser Site oft verfolgen kann, sind 
es oft viele Fragen zur Architektur der uC und das Verständnis dazu.
Ich finde so Dinge wie die Arduinos ganz nett und schick. Haben was von 
einem Smartphone, das die Kontrolle dem Nutzer völlig verwehrt. Aber 
wirklich lernen und die Architektur verstehen, dazu tragen sie nicht 
bei.
Der heutige Trend ist leider: Billig, man muss selbst nix in der Birne 
haben um so ein Teil zu bedienen und dem Anwender die Kontrolle zu 100% 
entziehen.
So will es die Welt. Und wenn sie nicht mehr weiter kommen und die es 
wirklich verstehen nichts mehr sagen (dürfen), dann hat die Kontrolle 
über euch/uns zu 1000% Erfolg gehabt.

Sorry, bin ein bisschen ins vom Thema abgekommen. Aber ich denke, also 
bin ich.

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Meiner Meinung nach denken die meisten einfach zu kurz. Früher war auch 
alles viel einfacher (und relativ teurer) und ne Entwicklung hatte keine 
Schnittstelle per Internet zum Smartphone. Als ich anfing, war ein 
1KByte großes Programm schon ordentlich. Mit ein paar KB waren komplette 
Schachprogramme geschrieben! Das ist heute undenkbar. Daher muß sich mit 
der Zeit auch die Entwurfsmethodik ändern. Die Folge sind dann Sprachen 
wie NET. Und auch da denkt man schon wieder ans absägen. Der 
Hobbyanwender muß auch nicht jede Strömung mitmachen. Besser sind 
wenige(!) tiefergehende Erlebnisse und mit denen dann die Projekte auch 
mal fertig bekommen. Also z.B. BASIC, dann C für die nächsten 30 Jahre. 
Die nächste Generation fängt mit C dann schon gar nicht mehr an, sondern 
geht von C++ los.

8052AH-BASIC wurde übrigens sehr_ _viel eingesetzt. Überall da, wo die 
Leute eben nicht reinrassige Programmierer sind. Z.B. einer der 
Turmuhren baut, Mechaniker ist und Firmenchef, der hat dann die Uhren 
mit so einem BASIC abgerundet. Das waren dann die Module, die gerne mit 
geschossenen I/O-Pins zur Reparatur kamen.

Leider kommt jetzt ne Generation, die sich einen uC ohne Linux nicht 
mehr vorstellen kann. Deren Hardwarekenntnisse entsprechen meistens dem 
- was sehr zur Belustigung beitragen kann.

Und dann "Standart" als neuer Standard - Danke schöne neue Welt.

von Stefan (Gast)


Lesenswert?

Ist doch interessant, wie hier einige ihr
Halbwissen zur Sprache bringen.
Da wird Basic wissen von vor 10 Jahren oder noch älter
zur Grundlage genommen. Das  sich aber inzwischen
einiges geändert hat, das wird ignoriert und man
pocht auf sein Halbwissen, was man mal gelernt hat.
Die heutigen Basic Compiler sind dem C fast gleich.
Auch in der Geschwindigkeit tut sich da nicht mehr viel.
Macht einfach mal selber den Test und testet die
verschiedenen Sprachen. Ihr werdet euch wundern.
Es gibt natürlich bei Basic wie auch bei C, Compiler, die
es auch noch schaffen, einen langsamen Code zu
erzeugen. Aber in der heutigen Zeit muß das nicht
mehr sein. Wie gesagt, da ist kaum noch Unterschied.

von Abdul K. (ehydra) Benutzerseite


Lesenswert?

Eben. Die Schrauben im Kopf waren immer schon die härtesten.

Was die Versauung angeht, das stimmt wohl sogar wenn man das klassische 
primitiv-BASIC betrachtet. Ganz konkret könnte der Code ja aus einem 
wilden Goto-Urwald bestehen.
Leider können Menschen aber mit reiner Symbolik nicht groß werden. Es 
nützt nix gleich in der 1.Klasse mit Funktionentheorie anzufangen und 
die schnöde Mengenlehre mit Plättchen wo Zahlen drauf prangen, gleich zu 
überspringen. Gar wozu Zahlen, wenn man mit Zahlenräumen umgehen kann? 
Die Kunst ist daher geeignete einfache Modelle der Wirklichkeit zu 
lehren, die auch später noch ausbaubar bleiben. Die Frage ist daher 
nicht BASIC durch C zu ersetzen, sondern BASIC durch eine andere 
Sprache, denn C ist doch eigentlich gar keine Sprache, sondern eher eine 
Art Hochsprachen-Assembler. Keine Typüberwachung zur Laufzeit ist wie 
Autofahren ohne Sicherheitsgurt. Der Könner brauch keinen solange er 
nicht anderen begegnet.

von Uwe B. (boerge) Benutzerseite


Lesenswert?

MoinMoin,

...jetzt muss ich mich doch mal zum Wort melden.

Ich finde die Diskussion oben schon recht lustig, da sie (und auch 
ähnliche Threads in diesem Forum) in den "berüchtigten" Glaubenskrieg 
abgleitet, welche Programmiersprache (für MCUs) die beste/geeigneteste 
ist.

Ich habe auch mal einen Basic-Interpreter für MCUs geschrieben. Einige 
erinnern sich vielleicht: 
http://www.mikrocontroller.net/articles/AVR_BASIC

Der Interpreter läuft auch auf einer 8-Bit-MCU wie z.B. einem ATmega168 
oder ATmega328 ohne Probleme, allerdings keine Floating-Point-Variablen 
und ein paar weiteren Beschränkungen.

Mein Ansatz lautete damals nicht, eine MCU vollständig mit diesem Basic 
zu programmieren. Vielmehr wollte ich eine Art Plugin-Schnittstelle zu 
einer bestehenden Firmware haben, mit der man einfach dynamisch 
nachladbare Zusatzfunktionen nachträglich und ohne tiefgreifende 
Eingriffe in die Firmware einbinden kann.

Das dieses Anliegen nicht so ungewöhnlich ist, beweisen einige mehr oder 
weniger bekannte Projekte:
* chdk --> alternative Firmware für Canon-Kameras; verwendet die selbe 
Ursprungsimplementierung eines einfachen Basic-Interpreters, wie ich, um 
einfach Plugins zu integrieren
* c't-Bot --> hier wurde mein Interpreter als Scriptsprache integriert, 
um zusätzliche Verhalten und Funktionalitäten ohne Eingriffe in die 
eigentliche Firmware zu realisieren
* viele weitere Firmware-Projekte, bei denen es eine 
Script-Schnittstelle gibt, mit der man Erweiterungen einfach einbinden 
kann.

Vorteil einer solchen Script-Schnittstelle (ob es nun Basic oder etwas 
anderes ist), ist, dass man nicht gleich in die Tiefen der eigentlichen 
Firmware absteigen muss, um diese funktional zu erweitern. Vielmehr 
bietet ein solcher Interpreter eine Zwischenschicht, mit der es, wenn 
vernünftig implementiert, sogar egal ist, was für Hardware darunter 
läuft. Z.B. bei chdk ist es (fast) egal, welches Kameramodell zum 
Einsatz kommt. Mein AVR-Basic läuft auch, entsprechend übersetzt, unter 
Linux etc. bzw. ist beim Speichermedium für die Basic-Programme recht 
flexibel.

Genau für solche Geschichten finde ich eine Scriptsprache auf einer MCU 
schon recht sinnvoll und berechtigt!

Und abschliessend: Auch bei der Realisierung von Zusatzfunktionen über 
eine solche Schnittstelle wird man, ohne grundlegende Kenntnisse der 
Hard- und Firmware, recht schnell Schiffbruch erleiden. Aber das ist 
auch bei Bascom, Arduino-Zeugs etc. der Fall!

Grüße Uwe

: Bearbeitet durch User
von Helmut S. (helmuts)


Lesenswert?

> allerdings keine Floating-Point-Variablen

Ich find an den 2KB mehr FLASH Speicher für Fließkomma sollte man nicht 
sparen sonst fallen ja schon die Hälfte der Anwendungen weg. Meistens 
muss man Messwerte korrigieren und umrechnen. Dazu benötigt ein 
BASIC-Programmierer Fließkomma.

von Martin (Gast)


Lesenswert?

Habe gedacht, dass man die PIC32s mal so eben mit einem 
"selbstgestricken" Programmer flashen kann. Na ja.

Auf jeden Fall: Humor haben die PIC-Leute, da kann man sagen was man 
will. Hier das 2-Wire Interface (Quelle: PIC32 Flash Programming 
Specification):


TABLE 4-2: 2-WIRE INTERFACE PINS

Pin Name Pin Type Pin Description
MCLR MCLR P Programming Enable
ENVREG(2) N/A I Enable for On-Chip Voltage Regulator
VDD and AVDD(1) VDD P Power Supply
VSS and AVSS(1) VSS P Ground
VCAP N/A P CPU logic filter capacitor connection
PGEC1 PGEC I Primary Programming Pin Pair: Serial Clock
PGED1 PGED I/O Primary Programming Pin Pair: Serial Data
PGEC2 PGEC I Secondary Programming Pin Pair: Serial Clock
PGED2 PGED I/O Secondary Programming Pin Pair: Serial Data

von MCUA (Gast)


Lesenswert?

>Wer allerdings ernsthaft der Meinung ist das man mit Bascom oder
>Micromite auch professionelle Entwicklungen realisieren kann, der hat
>einfach den Schuss nicht gehört!
Auch in der Industrie gibt es Leute, die wollen einfach nur mal schnell 
etwas runter schreiben (bsp in Basic oder mit vorgefert. Funktionen), 
was irgentwie läuft, und es dann im fertigen Produkt einsetzen.

von Uwe B. (boerge) Benutzerseite


Lesenswert?

MoinMoin,

Helmut S. schrieb:
> Ich find an den 2KB mehr FLASH Speicher für Fließkomma sollte man nicht
> sparen sonst fallen ja schon die Hälfte der Anwendungen weg.

naja, nur 2kB Flash sind es bestimmt nicht, da man diese Zahlen vorher 
auch interpretieren muss, irgendwo im RAM verwalten muss etc., halt was 
so ein Interpreter so machen muss...

Helmut S. schrieb:
> Meistens
> muss man Messwerte korrigieren und umrechnen. Dazu benötigt ein
> BASIC-Programmierer Fließkomma.

also meine Messwerte von ADCs oder Sensoren an irgendwelchen Bussen sind 
meist immer irgendetwas Ganzzahliges. Wozu braucht man dann 
Floating-Point?

Grüße Uwe

von Mehmet K. (mkmk)


Lesenswert?

MCUA schrieb:
> Auch in der Industrie gibt es Leute, die wollen einfach nur mal schnell
> etwas runter schreiben (bsp in Basic oder mit vorgefert. Funktionen),
> was irgentwie läuft, und es dann im fertigen Produkt einsetzen.

Nur so aus Neugierde: Ist hier die Rede von der deutschen Industrie und 
dem 21. Jahrhundert?

von MCUA (Gast)


Lesenswert?

>Nur so aus Neugierde: Ist hier die Rede von der deutschen Industrie und
>dem 21. Jahrhundert?
Ja, aber das sind wenige, mit nicht grad den komplexesten Anwendungen.

von chris_ (Gast)


Lesenswert?

Die Entwicklung des Basic finde ich sehr gut. Es sollte immer versucht 
werden, etwas einfacher zu machen.

Die Frage ist aber, ob Basic eine unsere Zeit angemessene 
Programmiersprache ist. Die meisten Programmiersprachen haben ja 
objektorientiert Komponenten.

Hier ein Beispiel:
http://www.eluaproject.net/overview

von Micromite (Gast)


Lesenswert?

Jungs, beruhigt Eure Gemüter...

In diesem Forum gibt es mindestens 3 unterschiedliche Teilnehmer:

1) Vollprofis
2) Solche die es sein wollen ;-)
3) Hobbyisten


Für Typ 1 ist ein Micromite Basic sicher nicht empfehlenswert resp. 
akzeptabel. Im Industrieumfeld herrschen andere Gesetzmäßigkeiten.
Da wäre ich auch erst einmal sehr "zurückhaltend".

Typ 2 ist ne eigene Welt ;-)

Aber Typ 3, also alle Hobbyanwender; finden hier eine hervorragende, 
preiswerte (billige), Plattform für "rapid deployment" und eine 
ausreichende Stabilität, so wie eine ausgesprochen einfache 
Entwicklungsumgebung ohne Frust.

Also no Limits to the Limits of our Imagination ;-)

D.

von Carsten S. (dg3ycs)


Lesenswert?

Hi,

Micromite schrieb:
> Aber Typ 3, also alle Hobbyanwender; finden hier eine hervorragende,
> preiswerte (billige), Plattform für "rapid deployment" und eine
> ausreichende Stabilität, so wie eine ausgesprochen einfache
> Entwicklungsumgebung ohne Frust.

Siehst du, man kann sich ja doch verständigen...
Wenn du jetzt noch den obigen Teil deiner Aussage folgendermaßen 
abänderst können wir dann endgültig einer Meinung sein:

> Aber Typ 3, also die Hobbyanwender; finden hier eine hervorragende,
> preiswerte (billige), Plattform für "rapid development " und eine
> ausreichende Stabilität, so wie eine ausgesprochen einfache
> Entwicklungsumgebung mit geringem Frustpotential die sich für
> einen Teil von ihnen sehr gut eignet.

MCUA schrieb:
> Auch in der Industrie gibt es Leute, die wollen einfach nur mal schnell
> etwas runter schreiben (bsp in Basic oder mit vorgefert. Funktionen),
> was irgentwie läuft, und es dann im fertigen Produkt einsetzen.

Ja, die gibt es durchaus...
Zumindest für interne Testgeräte ist das gar nicht mal so selten und 
auch OK, aber dafür braucht es kein Basic.

Wer behauptet das man dafür einen der Basic Dialekte braucht der ist 
einfach weit hinter der Zeit zurück. Ich möchte Wetten das mittlerweile 
viele höhere Funktionen sich durch die mittlerweile sehr umfangreich 
gewordenen Frameworks der Hersteller sogar deutlich schneller in C 
schreiben lassen als in den meisten Basic Dialekten.

Aber um mal vergleichswerte zu haben (ich bin wirklich in Bascom oder 
den entsprechenden Dialekten für andere µC nicht Fit):
Wie lange dauert es in Bascom eine USB HID-Mouse Funktion zu 
implementieren die nur einen MAusklick ausgibt?

Oder wie lange dauert es einen CAN Sniffer zu programmieren der die CAN 
Packets die über dem BUS laufen auf einem HD44780 kompatiblen LCD 
Display darstellt?

Zu der RS232 Kommunikation habe ich ja oben schon ein abschließendes 
Programm gepostet, wie sieht der entsprechende Basic Code aus.
Das war oben ja schon gefragt, aber da hat scheinbar keiner der 
"steinewerfer" sich getraut das Gegenstück zu posten.

Wie gesagt, für Hobbyisten die auch Hobbyisten bleiben wollen ist das 
doch alles völlig in Ordnung.

GEnauso für Elektronikinteressierte Schüler die zwar vielleicht mal 
berufliche Ambitionen haben aber noch in den unteren Klassenstufen 
stecken
(Da IST C nun einmal etwas schwieriger zu verstehen, ich weiß ja selbt 
noch wie ich in der zweiten Hälfte der Mittelstufe da so manchen 
Gebissabdruck in der Tischplatte hinterlassen habe - für dinge die aus 
heutiger Sicht einfach trivialst sind. Da steckt schon Frustpotential 
drin!)

Aber für jeden der irgendwie beruflich etwas in dieser Richtung macht 
sollte C einfachstes Grundlagenwissen sein. Die Entwicklungen werden 
immer schneller und die Hardware immer umfangreicher. Die 
Hardwarehersteller stellen ihre Libs ohne die man komplexe Dinge 
zumindest in kleineren Firmen nicht mehr in annehmbarer Zeit realisieren 
kann aber nur in C zur Verfügung.
Diese Libs sind dabei so Umfangreich das die Basic entwickler, sofern es 
sich überhaupt um eine umfangreich gepflegte Sprache handelt, oft gar 
nicht mehr hinterherkommen und bis dann auch die Unterstützung für 
dieses Feature in Basic bzw. bei diesem µC angekommen ist hat der µC 
Markt bereits wieder zwei Schritte weiter gemacht!

Daher ist C mittlerweile einfach notwendig wenn man irgenwie 
Zukunfstsicherheit haben will. Teilweise geht der Trend ja sogar schon 
zu C++ selbst auf den kleineren µC.
(Wobei ich das selbst eher kritisch sehe, auf den großen µC erkenne ich 
den Sinn, bei den kleinen finde ich eine zu große Abstraktion eher 
hinderlich, da ist zumindest bei den heutigen Compilern C meist doch 
noch deutlich effektiver)

Für einen Schüler in den höheren Klassenstufen der mit dem Gedanken an 
eine entsprechende Laufbahn spielt macht es also gar keinen Sinn erst 
mit Basic einzusteigen. Das ist nur doppeltes Lernen. Da besser direkt 
mit C anfangen, zumal das spätestens im Studium dann sowieso sein muss.

Gruß
Carsten

von Turmbau zu Babel (Gast)


Lesenswert?

'Akademiker-Variante' ;) welche sich LISP/SCHEME bedient.


http://www.ccs.neu.edu/home/stamourv/papers/picobit.pdf


http://www.iro.umontreal.ca/~feeley/
http://www-etud.iro.umontreal.ca/~stamourv/honor-en.html
-> http://gambitscheme.org

So verkehrt ist das doch nicht, wenn sich ein embedded-System in 
gleicher weise programmieren/skripten laesst wie eine Anwendung auf 
einem Hostrechner? Guile als Variante findet sich zb. auf jedem 
GNU/Linux.

Ob das sinnvoll oder noetig ist, wer weis.

von Stefan (Gast)


Lesenswert?

Hier mal ein Beispiel für deine UART Schnitstelle.
Ist das selbe wie in C nur zwei Zeile.

UART1_Init(9600)
UART1_Write_Text("Ready")

von X4U (Gast)


Lesenswert?

Micromite schrieb:
> Geoff hat den schnellen Basic Interpreter in einem PIC 32 nach der
> Betaphase nun öffentlich gemacht.

Super, herzlichen Dank für den link. und Lass dir von den Miesepetern 
und den AVR Heinzis nicht den Tag versauen. Wenn Betriebsblindheit blaue 
Flecken machen würde dann liefen die alle als Schlümpfe rum ;-).


NoOne schrieb:
> Aus meiner Sicht, tut sich niemand einen Gefallen, auch nicht im
> Hobbybereich, mit irgend einem Basic anzufangen.

Also ich bin mit HP Basic (heute HT Basic) angefangen. die beste Sprache 
und die besten Maschinen die beste Doku und die beste Performance in 
Sachen Stabilität, aber auch die höchsten Kosten. Damit konnte man 
erstklassig arbeiten. Der Umstieg auf C war bei mir dann aber auch 
schwierig und es hat lange gedauert.


Hirnlosen Spaghetti- und "write only" Code kann man in jeder Sprache 
erzeugen, das ist nicht Basic spezifisch. Am besten ist da wohl MUMPS
1
GREPTHIS()
2
       N S,N,T,I,K,Q S I="K",S="11",K="l1",Q="R",T="K"
3
       I I=T D T
4
       Q:$Q Q Q
5
T  I I,S&K S S=S+K Q
http://en.wikipedia.org/wiki/MUMPS

von X4U (Gast)


Lesenswert?

Stefan schrieb:
> UART1_Init(9600)
> UART1_Write_Text("Ready")

Wo immer man das eintippt, ohne Kenntnis von Devicename, 
Oszillatorfrequenz und -typ sowie evtl. welcher Uart gemeint sein könnte 
wird das wohl keine Compiler in der embedded Welt umsetzen können.

von Stefan (Gast)


Lesenswert?

Man sieht du hast keine Ahnung
von Basic Compilern.
Ist übriegens MICROBASIC.

von Carsten S. (dg3ycs)


Lesenswert?

X4U schrieb:
> Stefan schrieb:
>> UART1_Init(9600)
>> UART1_Write_Text("Ready")
>
> Wo immer man das eintippt, ohne Kenntnis von Devicename,
> Oszillatorfrequenz und -typ sowie evtl. welcher Uart gemeint sein könnte
> wird das wohl keine Compiler in der embedded Welt umsetzen können.

Stefan schrieb:
> Man sieht du hast keine Ahnung
> von Basic Compilern.
> Ist übriegens MICROBASIC.

Naja, so GANZ Unrecht hat er nicht...
Es handelt sich zumindest nicht um ein Lauffähiges MicroBasic Programm.
auch wenn da jetzt nicht wirklich viel fehlt.

Ich habe gerade mal MicroBasic Pro V6.0 (eval) für Pic Installiert und 
in Verbindung mit dem gerade hier liegenden Eval.Board mit PIC18F14K50 
etwas gespielt. Da ist ja eine Ser.Schnitstelle passenderweise drauf.

Also die Minimalanforderung für ein Kompilierbares Programm wäre
ja dies:

program MyProject
main:
UART1_Init(9600)
UART1_Write_Text("Ready")
end.

Wobei dieses Programm nicht ganz dem von mir geschriebenen oben 
entsspicht und dabei sogar eine wirklich EISERNE REGEL der EmbeddedWelt 
verletzt. Ein EmbeddedProgramm darf nie nie niemals nicht durch etwas 
anderes enden als durch abschalten der Stromversorgung!

Unterbrechungen durch Sleep, Standby & co. sind natürlich zulässig! Aber
ein Laufen "ins Leere" ist normalerweise ein schwerer Kunstfehler.
Wenn gleich in diesem Fall natürlich harmlos ;-)

Der Grund ist darin zu suchen das einfach nicht definiert ist was der µC 
macht wenn der PC am ende des Physikalisch vorhandenen Speichers 
ankommt. Im Idealfall natürlich "NICHTS" aber es könnte auch völlig 
anders aussehen.

Nun sind wir hier aber ja in keiner Klausur und die Anwendung ist auch 
nicht kritisch, es sei dir daher verziehen! Allerdings sollte daher für 
eine definitv saubere Funktion mindestens noch eine Endlosschleife am 
Ende stehen. (In C setzt man- falls das Programm nicht sowieso einer 
nicht verlassbaren Endlosschleife läuft, was eher der Standardfall ist - 
dann einfach ein " while(1);" ans Ende der main Funktion.)

Die Entsprechung hier wäre dann wohl das Einfügen der beiden folgenden 
Zeilen direkt vor dem "end.":
WhileSchleife:
goto WhileSchleife

Wobei man dann direkt auch die Befehle an die richtige Stelle setzen 
kann um ein bis auf dem Text zu meinem Beispiel funktionsidentisches 
Programm zu bekommen:

program MyProject
main:
UART1_Init(9600)
WhileSchleife:
UART1_Write_Text("Ready")
goto WhileSchleife
end.

Aber das ist im Grunde jetzt Erbsenzählerrei!
Ich denke es ist somit klar das weder MicroBasic (für Pic) unter 
Verwendung der MicroE Libs noch C unter Verwendung des Microchip 
Compilers & der Microchip Libs hier nennenswerte Mehrarbeit erfordern!
Das bleibt sich relativ gleich!

Die ConfigFuses wurden ja in beiden Fällen in der IDE gesetzt, Bei MPLAB 
geht das alternativ auch im Code, bei Mikrobasic weiß ich das nicht 
(vermute aber mal auch, oder?)
Sonst sind in C die Includes noch dabei die man manuell machen muss, in 
MikroBasic sind auch Includes nötig die macht die Software aber selbst.
Da ist noch ein Minimalunterschied...

Die GEschwindigkeit mit welcher der µC TATSÄCHLICH LÄUFT muss bei MikroE 
manuell in die IDE eingetragen werden, bei C habe ich die ja im Code 
angegeben. Ist also auch relativ egal, wobei die richtige Angabe in 
BEIDEN FÄLLEN genaues Lesen und verstehen des Datenblattes vorraussetzt.

Ich hatte die Speedangabe bei MikroBasic ja erst als "Sollfrequenz" des 
Oszillators missverstanden und dann Testweise 16 Mhz eingetragen weil 
dies ja die Nominalfrequenz des Internen Oszillators ist.
Erst als die Ausgabe dann um den Faktor 2^4 zu langsam war und ich 
gesehen habe das im ASM Code keine Änderung des OSCCON Registers erfolgt 
war mir (sofort) klar das hier die "Tatsächliche" Frequenz des Bausteins 
NACH Teilerkette eingetragen werden muss wie sie sich dann durch die 
Einstellungen (hier Initwerte nach Reset)  bei Erreichen der 
Ausgabebefehle darstellt.

NAtürlich hätte hier ein Lesen des Manuals auch vorher für Klarheit 
gesorgt ;-). Zudem ist es technisch auch Sinnvoll und sicher kein Fehler 
dies so zu machen.
Aber es erfordert genau so viel Nachdenken wie bei C,
ist also auch nicht einfacher in diesem Fall.

Eine andere Sache ist mir aber beim Test noch aufgefallen.
Ich wollte Spasseshalber gerade mal den Realtest machen und eine 
WINZIGANWENDUNG (zwanzig C Zeilen gesamt) die ich heute für ein 
Gerätchen geschrieben habe in Basic schreiben.

Aber ich musste feststellen das MicroBasic diesen Baustein, den es ja 
mittlerweile schon einige Monate gibt, gar nicht zu kennen scheint!
Also genau einer von den weiter oben von mir genannten DEUTLICHEN 
Nachteilen... (Es handelt sich um einen PIC12F1572)

Ansonsten muss ich aber sagen das mir die IDE gar nicht schlecht 
gefällt. Vielleicht sogar besser als das neue MPLABX mit dem ich bisher 
noch etwas auf Kriegsfuss stehe. (Ich weiß viele sehen das anders, aber 
mir lag das alte MPLAB 8.xx mehr als das neue MPLABX!)

Also wie gesagt, für Hobby spricht da ja nichts gegen! Wer µC nur als 
Hobby betreibt soll nehmen womit er zurecht kommt und wo er am meisten 
Spass hat. (Aber das habe ich ja schon vorher genau so gemeint!)

Für die berufliche Anwendung bleibe ich aber nach wie vor ebenso bei 
meiner festen Meinung! Und damit auch bei meiner Empfehlung für alle die 
zwar NOCH Hobbyisten sind, aber ernsthaft vor haben mal beruflich in die 
Richtung zu gehen.

Gruß
Carsten

: Bearbeitet durch User
von Stefan (Gast)


Lesenswert?

Hallo
Ja klar muß das in einer MAIN Schleife rein,
sonst macht es keinen Sinn. War auch nur
ein Beispiel. Aber die Librarys die im
Compiler sind, muß man ja nicht nehmen,
man kann genauso, wie in C, INCLUDE Dateien
einbinden. Entweder nimmt man welche von anderen
User oder man schreibt sie sich selber. Ist alles
möglich. Müßen natürlich mit dem Compiler
kompatible sein. Basic ist mitlerweile so flexibel
wie C geworden. Gibt natürlich Ausnahmen, wo sie noch
wie vor 10 Jahren, so unflexible sind. Aber das gibt
es auch in C.
Wollte jetzt auch nicht einen Streit zwischen den beiden
Sprachen auslösen. Wollte nur damit sagen, das man sich
vorher mal schlau macht, was die so können und nicht
ein Wissen nimmt, was über 10 Jahre alt ist.
So ist kein objektives Diskutieren möglich.
Ob einer C oder Basic nimmt, ist mir völlig egal und werde
auch niemandem vom Gegenteil überzeigen wollen. Jeder soll
die Sprache nehmen, mit der er am besten zurecht kommt.
Es ist ein Hobby und es soll Spaß machen. Was in der Industrie
genommen wird, das ist ein ganz anderes Thema.

von Stefan (Gast)


Lesenswert?

Die Geschwindigkeit wurde hier im Compiler
eingestellt. Das stimmt. Aber genauso kann
man es im Programm machen. Einfach im Datenblatt
das Register suchen und es genauso in den
Editor schreiben mit dem entsprechendem Wert.
Der Compiler akzeptiert alle Register die im Datenblatt
stehen. Es müßen nicht neue Befehle gelernt werden,
man kann auch die aus dem Datenblatt nehmen.
Oder halt die eigenen vom Compiler. Wie jeder mag.

von 2N3055 (Gast)


Lesenswert?

Ihr habt den Thread versaut.
Hier ging es um einen PIC Basic Interpreter.
Und nicht um einen krankhaften Kampf C gegen Basic oder Compiler oder 
sonst noch was.

Trollt Euch.

von Rübezahl (Gast)


Lesenswert?

2N3055 schrieb im Beitrag #3631694:
> Ihr habt den Thread versaut.
> Hier ging es um einen PIC Basic Interpreter.
> Und nicht um einen krankhaften Kampf C gegen Basic oder Compiler oder
> sonst noch was.
>
> Trollt Euch.

Full Ack.
Hier wimmelt es von Besten und Tollen (Trollen), die ihre Meinung (!= 
Wissen) überall einstreuen.
Bald kommt noch der Vergleich PIC-AVR ins Spiel...

von W.S. (Gast)


Lesenswert?

Uwe Berger schrieb:
> also meine Messwerte von ADCs oder Sensoren an irgendwelchen Bussen sind
> meist immer irgendetwas Ganzzahliges. Wozu braucht man dann
> Floating-Point?

Mein lieber Uwe, du hast gahz offensichtlich noch NIE irgendwelche 
echten Meßwerte zu verarbeiten gehabt. Sonst würdest du nicht das Obige 
geschrieben haben.

Ein ganz kleines Gegenbeispiel: Ich hatte vor geraumer Zeit hier mal nen 
Minimal-Frequenzzähler mit einem einfachen PIC16 gepostet. Natürlich 
handelt es sich erstmal um gezählte Impulse, also Ganzzahlen, aber da 
kommt sofort ne Multiplikation und eine Division ins Spiel:
Ergebnis:= Referenzfrequenz * Meßimpulse/Referenzimpulse;
Versuche doch mal, sowas blank in Integer zu machen - nein, geht nicht. 
Selbst auf so einem winzigen PIC16F7xx braucht man deshalb 
Gleitkomma-Arithmetik.

Du kannst aus diesem winzigen Beispiel sehen, daß man beim Vorliegen 
tatsächlicher Meßwerte (auch wenn diese anfangs integer sind) für eine 
sachgerechte Verarbeitung fast IMMER Gleitkomma braucht.

Übrigens: eine GK-Arithmetik nur für die Grundrechenarten braucht keine 
2K, sondern nur etwas 1/2 K an Programmcode.

Ansonsten meine Ansicht zu BASIC versus Rest der Welt: Es ist immer noch 
genug Platz in der Welt für einen resident auf einem µC laufenden 
Basicinterpreter - unter der Voraussetzung, daß der µC von einem 
Menschen interaktiv benutzt wird.

Wer bislang für größere Serien professionell entwickelt, wird sicherlich 
Maschinencode per Compiler erzeugen, weil das (meistens) auf die 
sparsamste Hardware hinausläuft. Ob das der Nachwuchs ebenso hinbekommt, 
ist aber höchst zweifelhaft bis unwahrscheinlich. Man lese hierzu bloß 
mal in diesem Forum in der GCC-Abteilung, was da für altkluge und 
zugleich unfähige Leute sich da spreizen.

W.S.

von Alexander S. (esko) Benutzerseite


Lesenswert?

@W.S.: Oft kann man Gleitkomma- durch Festkommaarithmetik ersetzten. 
Wie das geht steht im Link.

von Micromite (Gast)


Lesenswert?

W.S. schrieb:
> Ansonsten meine Ansicht zu BASIC versus Rest der Welt: Es ist immer noch
> genug Platz in der Welt für einen resident auf einem µC laufenden
> Basicinterpreter - unter der Voraussetzung, daß der µC von einem
> Menschen interaktiv benutzt wird.


Also der Interpreter interpretiert auch ohne einen interaktiv agierenden 
Menschen.

Der Micromite startet automatisch das Programm im Flash beim Anlegen der 
Betriebsspannung.
Interaktiv und äußerst komfortabel wird es natürlich während der 
Programmentwickelung;-)

von Uwe B. (boerge) Benutzerseite


Lesenswert?

MoinMoin,

W.S. schrieb:
> Mein lieber Uwe, du hast gahz offensichtlich noch NIE irgendwelche
> echten Meßwerte zu verarbeiten gehabt. Sonst würdest du nicht das Obige
> geschrieben haben.

"Mein lieber W.S."..., wenn du dich da mal nicht täuschst. Soweit ich 
mich recht entsinne, hatte eines meiner Hauptstudienfächer vor gut 25 
Jahren den Namen "Prozessmesstechnik". Und so schlecht kann ich da nicht 
gewesen sein, für meine Diplomarbeit hatte ich ein Thema aus diesem Fach 
gewählt...

W.S. schrieb:
> Versuche doch mal, sowas blank in Integer zu machen - nein, geht nicht.
> Selbst auf so einem winzigen PIC16F7xx braucht man deshalb
> Gleitkomma-Arithmetik.

...und dazu habe ich mehrere 10.000 Messwerte 
aufnehmen/umrechnen/weiterverarbeiten müssen. Und ich verrate dir mal 
folgendes: ja, es geht auch ohne Floating-Point!

W.S. schrieb:
> Ergebnis:= Referenzfrequenz * Meßimpulse/Referenzimpulse

...hmmm, da hast du natürlich recht, das ist schon eine recht 
komplizierte Gleichung. Wahrscheinlich muss das Ergebnis auch auf ein 
Millionstel genau sein. Da werde ich wohl ein paar Nächte nachdenken 
müssen.

W.S. schrieb:
> Übrigens: eine GK-Arithmetik nur für die Grundrechenarten braucht keine
> 2K, sondern nur etwas 1/2 K an Programmcode.

alles klar, da du dich ja ausgezeichnet mit dem Interpreterbau 
auskennst: die Quellen zu meinem Interpreter findest du hier im SVN. Du 
kannst dich ja mal versuchen und das Ergebnis posten! Ich würde auch 
nicht entäuscht sein, wenn du 3 oder 4 kByte Programmcode dafür 
benötigst...

W.S. schrieb:
> Man lese hierzu bloß
> mal in diesem Forum in der GCC-Abteilung, was da für altkluge und
> zugleich unfähige Leute sich da spreizen.

joo, nicht nur dort; sogar hier...

Grüße Uwe

von W.S. (Gast)


Lesenswert?

Micromite schrieb:
> Also der Interpreter interpretiert auch ohne einen interaktiv agierenden
> Menschen.

Das glaube ich dir.
Aber es gibt da nen Unterschied:
Für einen µC, der irgendwo in irgendeiner Schaltung in irgendeinem Gerät 
seine Arbeit verrichtet, die immer gleich ist, braucht es keinen 
Interpreter im µC. Es kann sein, muß aber nicht. Deswegen ist an solchen 
Stellen etwas fertig übersetztes im ROM oftmals die ökonomischere Wahl - 
wenn es um Stückzahlen geht.

Das Gegenteil ist der Fall, wenn so ein µC interaktiv benutzt wird, weil 
er wechselnde Aufgaben verrichten soll, Beispiel: irgend ein Tester für 
irgendwelche Produkte, ein Laboraufbau für irgendwelche Versuche, wo man 
mal eben über ein Terminal nen Parameter verändern will usw. Dort wäre 
der Umweg über PC anschmeißen, Quelle dort ändern, übersetzen, Chip 
programmieren usw. zu umständlich - und deshalb ist ein vor Ort 
vorhandener Basic-Interpreter in solchen Fällen viel angenehmer.

Mach weiter mit deinem Interpreter, ich find's gut. Und an alle, die 
hier über C versus Basic schreiben: Ja, Basic hat auch heutzutage seine 
Berechtigung und ich finde es albern und scheuklappig zu fordern, daß 
ein junger Mensch zu allererst mit C anfangen soll.



anderes Thema:
Uwe Berger schrieb:
> wenn du dich da mal nicht täuschst..
Ach nein, ich täusche mich da nicht. Es gibt nen Unterschied zwischen 
deiner Diplomarbeit und dem echten Leben. Den gibt es übrigens fast 
überall, da brauchst du dich nicht zu schämen - aber du solltest das 
auch nicht als Argument benutzen, wenn du ernstgenommen sein willst.

Uwe Berger schrieb:
> ...hmmm, da hast du natürlich recht, das ist schon eine recht
> komplizierte Gleichung. Wahrscheinlich muss das Ergebnis auch auf ein
> Millionstel genau sein. Da werde ich wohl ein paar Nächte nachdenken
> müssen.
Ja, tu das.
Vielleicht ist es dir noch nicht aufgefallen, deshalb sage ich es dir:
Bei Frequenzzählern gilt ein Millionstel als zu poplig. Da wünschen sich 
die meisten Anwender wenigstens 8 gültige Stellen - was auch Auswirkung 
auf den schieren Hardwareaufwand hat: OCXO oder wenigstens TCXO und dann 
eben Kalibrieren, was wieder auf ne Multiplikation mit double 
hinausläuft.

Und der obige Rechengang ist tatsächlich nicht trivial.
Wenn du wirklich so schlau bist, dann versuche mal,
Ergebnis:= Referenzfrequenz * Meßimpulse/Referenzimpulse;
per integer hinzukriegen. Wohl gemerkt, alles was auf der rechten Seite 
steht, kann bei einfachen Zählern bis zu 28 Bit haben und das Ergebnis 
wird mit mehr als 6 gültigen Stellen gewünscht.
Also mach mal, dann wirst du von ganz allein sehen, wozu man in einem µC 
Gleitkomma braucht - und dann wirst du vermutlich auch von selbst deine 
dumme Bemerkung revidieren:

Uwe Berger schrieb:
> also meine Messwerte von ADCs oder Sensoren an irgendwelchen Bussen sind
> meist immer irgendetwas Ganzzahliges. Wozu braucht man dann
> Floating-Point?

Die Antwort auf deine Frage hatte dir ja der Helmut schon im Voraus 
gegeben: "Meistens muss man Messwerte korrigieren und umrechnen. Dazu 
benötigt ein BASIC-Programmierer Fließkomma."

W.S.

von Uwe B. (boerge) Benutzerseite


Lesenswert?

Sorry für diesen OT... :-(

"Mein lieber W.S."... es wird langsam lustig mit dir --> du zerredest 
gerade deine letzte Glaubwürdigkeit und Seriösität...!

W.S. schrieb:
> Ach nein, ich täusche mich da nicht. Es gibt nen Unterschied zwischen
> deiner Diplomarbeit und dem echten Leben. Den gibt es übrigens fast
> überall, da brauchst du dich nicht zu schämen - aber du solltest das
> auch nicht als Argument benutzen, wenn du ernstgenommen sein willst.

ich verneige mich vor dir grosser allwissender Meister. Ich gelobe, dich 
in Zukunft ernst zu nehmen, deinen Weisheiten andächtig zu lauschen und 
nur noch dich als einzig Wahren anzuerkennen... Spinner!

W.S. schrieb:
> Bei Frequenzzählern gilt ein Millionstel als zu poplig.

Mit was kalibrierst du eine solche Genauigkeit, betreibst du deinen FZ 
im klimatisierten Reinstraum, wo hast du diese höchststabilen Bauteile 
her?

W.S. schrieb:
> Da wünschen sich
> die meisten Anwender wenigstens 8 gültige Stellen

vor oder nach dem Komma?

W.S. schrieb:
> OCXO oder wenigstens TCXO und dann
> eben Kalibrieren, was wieder auf ne Multiplikation mit double
> hinausläuft.

wie definierst du eigentlich den Begriff "Kalibrieren"? Irgendwie passt 
dieser Begriff nicht in deinen Satz bzw. die Aussage, die du gerade 
machen wolltest...

W.S. schrieb:
> Und der obige Rechengang ist tatsächlich nicht trivial.

ok, hatte schon eine schlaflose Nacht, aber du erklärst es mir ja 
gleich...

W.S. schrieb:
> Ergebnis:= Referenzfrequenz * Meßimpulse/Referenzimpulse;
> per integer hinzukriegen. Wohl gemerkt, alles was auf der rechten Seite
> steht, kann bei einfachen Zählern bis zu 28 Bit haben und das Ergebnis
> wird mit mehr als 6 gültigen Stellen gewünscht.

ahaaaa...!
Kurze Zwischenfrage, damit ich es auch verstehe:
Was kann dein FZ maximal messen?
Welche Toleranz hat deine Zeitbasis?
Du hast eine ungefähre Ahnung davon, dass es auch noch andere 
ganzzahlige Variablenformate gibt, die grösser als 2^16 sind?

...und nun bitte mal konkrete Antworten und kein Drum-Herum-Gesülze!

W.S. schrieb:
> ... und dann wirst du vermutlich auch von selbst deine
> dumme Bemerkung revidieren:

nö... bzw. rechne doch mal ein konkretes Beispiel vor, damit ich es auch 
verstehe!

Grüße Uwe

von Nico (Gast)


Lesenswert?

W.S. schrieb:
> aber du solltest das
> auch nicht als Argument benutzen, wenn du ernstgenommen sein willst.
Und du solltest überhaupt stichhaltige Argumente bringen, wenn du 
ernstgenommen werden willst.

von m.n. (Gast)


Lesenswert?

Uwe Berger schrieb:
> "Mein lieber W.S."... es wird langsam lustig mit dir --> du zerredest
> gerade deine letzte Glaubwürdigkeit und Seriösität...!

Nee, er läßt sich nur nicht die Butter von der Stulle nehmen :-)

Uwe Berger schrieb:
> W.S. schrieb:
>> Da wünschen sich
>> die meisten Anwender wenigstens 8 gültige Stellen
>
> vor oder nach dem Komma?

Informiere Dich, was 'gültige Stellen' sind und rechne einmal im 
Fix-Komma-Nix Format für die Variablen x, y, z:

x=84878800
y=19
z=168000000

x*y/z auf 6 gültige Stellen.

Uwe Berger schrieb:
> ahaaaa...!
> Kurze Zwischenfrage, damit ich es auch verstehe:
> Was kann dein FZ maximal messen?
> Welche Toleranz hat deine Zeitbasis?

Beispielsweise: Beitrag "reziproker Frequenzzähler, GPS-stabilisiert, ATmega162"

Nico schrieb:
> Und du solltest überhaupt stichhaltige Argumente bringen, wenn du
> ernstgenommen werden willst.

Wenn man die Argumente versteht, muß man sie zwangsläufig ernst nehmen; 
auch wenn sich die üblen Vorurteile halten, wie float braucht man nicht, 
float braucht zuviel Speicher, float ist langsam...

Ich erinnere an den uralten PET (mit BASIC-Interpreter). Ohne 
float-Berechnungen wäre das Teil nur ein weiteres Spielzeug und vielen 
gewesen.

Gibt es von dem PIC32-MMBASIC eine Portierung auf den STM32F4..?

von Sciba (Gast)


Lesenswert?

Zum Thema:

Hier [1] ist ein Flashtool für den obigen PIC32-Controller. Wer hat die 
Arduino-Umgebung installiert, kann das Programm compilieren (ATMega328) 
und das Hexfile hier einstellen?

So hat man die Möglichkeit auf die Schnelle einen Flashprogrammer auf 
einem Steckbrett zu bauen.


[1]
http://code.google.com/p/ardupic32/source/browse/trunk/?r=4

von Uwe B. (boerge) Benutzerseite


Lesenswert?

MoinḾoin,

m.n. schrieb:
>> vor oder nach dem Komma?
>
> Informiere Dich, was 'gültige Stellen' sind

da provokative "vor/nach Komma" bezog sich auf das Unverständnis von 
W.S., was ich mit dem Millionstel Genauigkeit meinte!

m.n. schrieb:
> rechne einmal im
> Fix-Komma-Nix Format für die Variablen x, y, z:

mit einem uint64_t kein Problem:

y * 100000, dann kommst du im Endeffekt auf deine 6 Stellen 959938

...wobei ich die Beispielzahlen für den von W.S. angebrachten 
Sachverhalt anzweifle!

Uwe

von m.n. (Gast)


Lesenswert?

Uwe Berger schrieb:
> m.n. schrieb:
>> rechne einmal im
>> Fix-Komma-Nix Format für die Variablen x, y, z:
>
> mit einem uint64_t kein Problem:
>
> y * 100000, dann kommst du im Endeffekt auf deine 6 Stellen 959938

Mit float-Berechnung komme ich auf 9.59939; Zwischenwerte bei der 
Berechnung interessieren mich nicht.
Für den Kehrwert erhalte ich übrigens 0.104173.

> ...wobei ich die Beispielzahlen für den von W.S. angebrachten
> Sachverhalt anzweifle!

Dann müssen wir garnicht mehr weiterreden.

von Uwe B. (boerge) Benutzerseite


Lesenswert?

m.n. schrieb:
> Mit float-Berechnung komme ich auf 9.59939; Zwischenwerte bei der
> Berechnung interessieren mich nicht.

du hast nach den 6 signifikanten Stellen (Definition vielleicht nochmal 
nachlesen...) gefragt und diese ganzzahlig berechnet! Wo das Komma dabei 
steht ist nebensächlich. Ergibt sich aber "zufällig" aus dem Faktor, mit 
dem man y multipliziert hat!

m.n. schrieb:
>> ...wobei ich die Beispielzahlen für den von W.S. angebrachten
>> Sachverhalt anzweifle!
>
> Dann müssen wir garnicht mehr weiterreden.

ich bin gespannt auf deine Erläuterung!

Uwe

von Carsten S. (dg3ycs)


Lesenswert?

Hi,

W.S. schrieb:
> Uwe Berger schrieb:
>> also meine Messwerte von ADCs oder Sensoren an irgendwelchen Bussen sind
>> meist immer irgendetwas Ganzzahliges. Wozu braucht man dann
>> Floating-Point?
>
> Mein lieber Uwe, du hast gahz offensichtlich noch NIE irgendwelche
> echten Meßwerte zu verarbeiten gehabt. Sonst würdest du nicht das Obige
> geschrieben haben.

DA es in dem von "Uwe" geschriebenen Textstück schon das nette Wörtchen 
"meist" gibt ist es im Grunde völlig Unsinnig um einen konkreten 
Beispielfall zu streiten.

Und völlig egal ob ein Reziproker Frequenzzähler mit oder ohne 
Fließkommarithmetik machbar* ist - Eine Darstellung von 8 oder mehr 
signifikanten Stellen mit 1ppm Genauigkeit  ist bei Frequenzzählern die 
nur mit Festkommarithmetik arbeiten keine Hexerei!
JA - es funktioniert nicht jedes Konzept und JA es muss auch so mancher 
Trick verwendet werden. Aber das es geht ist zahlreich bewiesen...
Und wie gesagt- es ist müßig sich über "ein" Beispiel zu unterhalten.

(*ist es, wobei sich mit Fließkomme durchaus eine etwas leichtere 
Realisierung und einige weitere KLEINE Vorteile ergeben)

m.n. schrieb:
> Ich erinnere an den uralten PET (mit BASIC-Interpreter). Ohne
> float-Berechnungen wäre das Teil nur ein weiteres Spielzeug und vielen
> gewesen.

Uwe hat doch gar nirgendwo behauptet das Fließkommarithmetik in JEDEM 
FALL unsinnig ist. Für mich liest sich seine Aussgae so das er der 
Meinung ist bei den für Mikrocontroller typischen Anwendungen kann man 
MEIST Problemlos darauf verzichten. Und so Falsch ist das ja nicht, wenn 
gleich die Tatsache das gerade in den letzten JAhren die µC früher 
ungeahnte Leistungsfähigkeiten erreicht haben und damit immer mehr 
Aufgaben mit immer höheren Anforderungen übernehmen können sehr zur 
Relativierung beigetragen hat.

Für mich liest diese gesamte Teildiskussion so als ob jemand der 
Jahrelang solide erfahrung in diesem Bereich zu einer Zeit als man 
wirklich noch um jedes Byte kämpfen musste erlebt hat und deshalb noch 
alle Möglichkeiten und Tricks aus dem FF kennt, mit welchen Diskutiert 
die das vielleicht gerade mal drei oder vier JAhren machen oder das 
Handwerk im µC Bereich zumindest niemals auf professionellen Niveau 
erlernt haben und darum nur die Fließkommaaraithmetik überhaupt als 
Lösung wahrnehmen und die ganze Problematik inkl. Ausweichwege gar nicht 
wirklich kennen.

Woebi diese Diskussion auch heute noch -abseits der Grundlagenfrage- 
nicht völlig unsinnig ist. Zwar spielt es für einen Hobbyisten oder auch 
industriellen Kleinserienfertiger kein Rolle, aber für ein "High Volume 
Product" macht es unter Umständen einen riesen Unterschied ob ich für 
die Zielerreichung mit 1900 Programmwörtern auskomme oder aber 2100 
Programmwörter brauche. Da kann es dann im Extremfall um einsparungen in 
Millionenhöhe über die Produktlebensdauer gehen.

Der Hobbyist oder Kleinserienproduzent ist heute natürlich viel besser 
dran wenn er statt dessen einfach auf die Fließkommamöglichkeiten 
zurückgreift und bei Bedarf einfach zu dem in >>90% der Fälle vorhanden 
nächst größeren µC der Serie greift. Nur wenn diese Möglichkeit 
ausgereizt ist wird es überhaupt sinnvoll über Alternativen 
nachzudenken.

Wenn dann aber ein solcher Hobbyist mit seiner etwas eingeschränkten 
Erfahrung an jemanden gerät der zumindest die früheren Zeiten wo es eben 
keinen "nächst größeren" µC gab oder gar aus einem Bereich der 
HighVolume produkte kommt, dann gibt es eine Diskussion wie hier...

@Uwe
Aber zumindest in einem Punkt solltest du dir auch an deine Nase fassen:

1ppm  bei 8 Stellen Auflösung ist bei F-Countern jetzt nichts absolut 
exotisches.
Klar - das ist sicher nicht mehr Trivial. Aber in einer Zeit wo man 
Rubidiumnormale für <<100Euro bekommt (wobei irgendwie in der Letzten 
Zeit die Preise wieder angezogen zu haben scheinen ) und GPS Empfänger 
mit Sync-Ausgang noch deutlich billiger sind, ist selbst der eigenaufbau 
solcher Geräte durch erfahrene Hobbyisten keine Unmöglichkeit mehr.

Einfach mal so was aus der Bastelkiste zusammenstecken geht freilich 
natürlich nicht.

Gruß
Carsten

: Bearbeitet durch User
von Mehmet K. (mkmk)


Lesenswert?

Hat inhaltlich nichts mit der Thematik zu tun.
Mir ist aber aufgefallen, dass alle (ich hoffe, ich habe keinen 
übersehen), die für Basic/Float plaedieren, dies aus der Anonymitaet 
heraus als Gast tun, waehrend diejenigen, die hinter Basic ein 
Fragezeichen setzen, ihre Ansichten mit vollem Namen unterschreiben.

: Bearbeitet durch User
von Chris (Gast)


Lesenswert?

Ja, tolle Sache, inkl der einfachen Erweiterbarkeit des Interpreters,
blöd nur wie es gelaufen ist.
Am Anfang war der Interpreter Frei, inkl kommerzieller Nutzung, sprich 
eine
Art BSD Lizenz. Dann ging olimex her, tat so als hätte Olimex dies 
programmiert ohne nennung der Quellen. Der Programmierer ärgerte sich, 
beschwerte sich auf einigen Blogs, und machte eine neue Lizen, nur 
persönliche Nutzung, was den Nutzen komplett wieder einschränkt.

Ich bevorzuge da lieber einen basic zu C Converter und dann compilieren,
aber auch ein Interpreter hat seinen Nutzen.

von W.S. (Gast)


Lesenswert?

Uwe Berger schrieb:
> y * 100000, dann kommst du im Endeffekt auf..

Junge, kannst du blöd sein.

Anstatt mal die Klappe zu halten und das, was dir von kompetenter Seite 
gesagt wurde zu Kenntnis zu nehmen und ein bissel nachzudenken, 
reagierst du mit Aufgebrachtheit und Arroganz.

Also zähle mal in deinem Beispiel die Nullen - nur so als Hinweis.

Es nützt aber auch nichts, wenn du irgendwelche an den Haaren 
herbeigezogenen Beispiele für das mögliche Umgehen einer 
Gleitkommarechnung anführst. Da könnte man allzeit sagen "Ja, mit einem 
int256 und Multiplizieren mit 10000000000000 kann man dieses Problem 
auch lösen" - solche Argumentation ist praktisch Mumpitz.

Es ist auch nicht hilfreich, wenn du in den zurückliegenden 25 
Berufsjahren hast " mehrere 10.000 Messwerte 
aufnehmen/umrechnen/weiterverarbeiten müssen". Aus einem Beispiel, wo 
jemand sagt, daß er 25 Jahre lang selber nicht mit dem Skalieren und 
Berechnen von Meßwerten und mit dem Kalibrieren von Meßgeräten zu tun 
hatte, kann man nicht schließen, daß Gleitkomma auf dem µC etwas 
Überflüssiges wäre, wie du es getan hast.

Und noch was Grundsätzliches: Unsereiner erwartet auch von DIR ein 
gewisses Maß an Sachlichkeit. Wenn du nur herumulken und mit 
unsachlichen Bemerkungen andere nerven willst("da provokative "vor/nach 
Komma" bezog sich auf das Unverständnis von W.S., was ich mit dem 
Millionstel Genauigkeit meinte!"), dann gehe damit in die Ecke für 
Offtopics.

Mannomann, soviel Dummschwätz deinerseits, bloß weil du dir zu fein bist 
einfach mal zu sagen "sorry, mit sowas hatte ich noch nix zu tun 
gehabt".

W.S.

von Uwe B. (boerge) Benutzerseite


Lesenswert?

W.S. schrieb:
> Mannomann, soviel Dummschwätz deinerseits, bloß weil du dir zu fein bist
> einfach mal zu sagen "sorry, mit sowas hatte ich noch nix zu tun
> gehabt".

...ich überings auch noch nicht...!

...lese einfach mal dein wirres Zeugs, trinke einen Kamillentee und 
denke mal darüber nach, wer hier versucht hat objektiv zu bleiben bzw. 
loszupöbelt!


Uwe

PS.: zu dem Rest von dir im letzten Beitrag sage ich einfach nichts 
mehr, da ich einfach nur sprachlos über soviel Ignoranz bin!

von Carsten S. (dg3ycs)


Lesenswert?

W.S. schrieb:
> Also zähle mal in deinem Beispiel die Nullen - nur so als Hinweis.
>
> Es nützt aber auch nichts, wenn du irgendwelche an den Haaren
> herbeigezogenen Beispiele für das mögliche Umgehen einer
> Gleitkommarechnung anführst. Da könnte man allzeit sagen "Ja, mit einem
> int256 und Multiplizieren mit 10000000000000 kann man dieses Problem
> auch lösen" - solche Argumentation ist praktisch Mumpitz.

AAAUUUUTTTTSSCCHHHHH !!!

Ich glaube mit diesem Beitrag hast du dann alles gesagt was zu deiner 
Kompetenz bei dem Thema zu sagen ist...

Nur mal so als Hinweis über den du noch einmal Nachdenken solltest:
Bei einem üblichen 8Bit Mikrocontroller ist der einzige Physikalisch 
vorhandene Datentyp der 8Bit Char (Ob signed/unsigned sei mal 
dahingestellt).
Alle weiteren Datentypen werden vom Compiler aus diesen 
zusammengebastelt.

Daher ist ES JA auch ÜBERHAUPT KEIN PROBLEM sich eine Rechnung zu 
programmieren die mit Zahlen aus dem Wertebereich eines 256Bit INT 
arbeitet.. Oder 512Bit oder 1024 Bit....

Und da dies viel einfacher ist als eine echte Fließkommaoperation zu 
realisieren lässt sich so bei knappem Speicher eine Menge platz sparen.
Wem das wissen darum natürlich fehlt, dann ist es schon recht peinlich 
wenn so jemand dann so laut einen auf "experten" macht.

Und zum Rest deines Beitrages erübrigt sich dann jede weitere Äusserung.

Gruß
Carsten

von m.n. (Gast)


Lesenswert?

Carsten Sch. schrieb:
> Für mich liest diese gesamte Teildiskussion so als ob jemand der
> Jahrelang solide erfahrung in diesem Bereich zu einer Zeit als man
> wirklich noch um jedes Byte kämpfen musste erlebt hat und deshalb noch
> alle Möglichkeiten und Tricks aus dem FF kennt,

Ich kann mich gut an diese Zeit vor 30 Jahren erinnern. Vorzugsweise 
wurde in Assembler programmiert, sodass mir die Werte 0x64, 0x3e8 und 
0x2710 in bester Erinnerung sind. Allerdings hatte ich damals auch schon 
einen BASIC-Interpreter mit float (5 Bytes), den ich für u.a. reziproke 
Zähler verwendet hatte. (Befehle wie 'open', 'save', 'load'.. für eine 
serielle Commodore-Foppy, ein integrierter 6502-Assembler und das 
Programm im gepufferten CMOS-RAM ermöglichten mobilen Einsatz inkl. 
zügiger Programmänderungen :-)

Aber aus den Erfahrungen habe ich auch gelernt und verwende daher heute 
immer float auch für Skalierungen von Sensoren. Gerade beim Umrechnen 
von Druck, Kraft, ... in angloamerikanische Maßeinheiten ist das ein 
Segen.

Wenn sich heute jemand als Experte dadurch profilieren muß/möchte, wie 
vor 30 Jahren zu programmieren, tut er mir Leid.

Ich wiederhole noch einmal meine Frage, ob Jemand eine Portierung für 
den STM324.. gemacht hat. Das wäre doch eine nette Spielerei.
Oder ich schreib mal wieder selber einen Interpreter.

von Micromite (Gast)


Lesenswert?

Den Sourcecode stellt Geoff auf Anfrage zur Verfügung.
Der ist sehr gut dokumentiert und aufgeräumt.

Feel free for a port ;-)

von m.n. (Gast)


Lesenswert?

Micromite schrieb:
> Den Sourcecode stellt Geoff auf Anfrage zur Verfügung.
> Der ist sehr gut dokumentiert und aufgeräumt.

Soweit ich es überschlagen habe, darf man ihn aber nicht weitergeben, 
egal, ob 1:1 oder modifiziert. Andernfalls müßte man ja keine 
Registrierungsspur hinterlassen?

Ich sehe ihn mir bei Gelegenheit einmal an.

von Micromite (Gast)


Lesenswert?

Geoff anschreiben fertig.
Der sieht das sehr. Locker, hat keine kommerziellen Absichten und möchte 
nur wieder so eine Olimex Nummer vermeiden...

von Micromite (Gast)


Lesenswert?

Habe Geoff ne PM gesendet.

Er begrüßt deine Portierungsidee und freut sich auf einen Kontakt.

von m.n. (Gast)


Lesenswert?

Micromite schrieb:
> und möchte
> nur wieder so eine Olimex Nummer vermeiden...

Da weiß ich nicht, was da gelaufen ist.


> Er begrüßt deine Portierungsidee und freut sich auf einen Kontakt.

Gemach, gemach, da muß ich erst einmal auf schlechtes Wetter warten :-)

Enthält der Quellcode auch ein Filsystem für SD-Karte, usw... oder sind 
das spezielle Anpassungen anderer Entwickler?
Das wäre dann eine feine Sache.

von Alexander S. (esko) Benutzerseite


Lesenswert?

m.n. schrieb:
>> und möchte nur wieder so eine Olimex Nummer vermeiden...
> Da weiß ich nicht, was da gelaufen ist.

Das kannst du hier nachlesen:
http://www.geoffg.net/OpenSource.html

Der Onlineversender hat die Platinen nachgebaut und sich als Erfinder 
ausgegeben.

von Micromite (Gast)


Lesenswert?

Ja, Filesystem für SD Karten ist mit dabei.

von Carsten S. (dg3ycs)


Lesenswert?

Micromite schrieb:
> Ja, Filesystem für SD Karten ist mit dabei.

ICh glaube m.n. wollte darauf hinaus ob der Quellcode ein von geoff 
SELBST erstelltes FileSystem enthält oder z.B. das File System von 
Microchip nutzt.

Im ersten Fall bestimmt Geoff ja ganz alleine ob und wie das auf STM 
Portiert werden darf. ISt die Zustimmung da sind alle Probleme vom 
Tisch.
Im zweiten Fall müsste das Microchip File System dann entweder durch ein 
eigenes oder das STM File System ersetzt werden.

Wie viel Aufwand das wird hängt dann davon ab wie viel Wert bereits bei 
Erstellung der Micromite Firmware auf eine spätere Portabilität gelegt 
wird. Im Optimalfall finden dann keine direkten Aufrufe das MAL 
Funktionen im eigendlichen Hauptprogramm statt sondern diese werden nur 
innerhalb eigener Funktionen aufgerufen deren Zweck es einfach nur ist 
diese etwas zu Kapseln um eine Portierung zu erleichtern. Dann müssten 
die Änderungen für jeden Befehl nur an einer einzigen Stelle erfolgen. 
Ist also im Grunde einfach nur ein Teil des HAL.

Also der Fall welchen ich hier bereits angesprochen habe:
Carsten Sch. schrieb:
> Wenn man weitestgehende Plattformunabhängigkeit sucht,[...] wird es
> minimal aufwendiger,
>  dann würde man die µC Spezifischen Funktionen in eigenen
> Funktionen verstecken und dann im Programm nur die eigenen Funktionen
> aufrufen.
> Dann müssten jeweils bei einer Portierung nur einmalig die eigenen
> Funktionen angepasst werden. Aber das ist hier wie gesagt irrelevant
> weil die Basic Varianten diese Möglichkeit ja überhaupt nicht bieten.)

Gruß
Carsten

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

1
> The SD/MMC/SDHC memory card slot has support for FAT16 and FAT32 file 
2
> systems up to 64GB.  Using this you can save and load programs and under
3
> program control you can read and write data to the memory card with up to
4
> 10 files simultaneously open.  The file system and data is compatible with
5
> Windows, Apple and Linux so the card can be read by any of these computers.

: Bearbeitet durch User
von Micromite (Gast)


Lesenswert?

In den nächsten Tagen wird es eine 4.5C geben, welche einige Bugs 
beseitigt.
RND, Reset Problem etc...

von Micromite (Gast)


Lesenswert?

A new version of MMBasic for the Micromite is available for download 
from

http://geoffg.net/micromite.html#Downloads

von m.n. (Gast)


Lesenswert?

Micromite schrieb:
> Ja, Filesystem für SD Karten ist mit dabei.

Carsten Sch. schrieb:
> Im zweiten Fall müsste das Microchip File System dann entweder durch ein
> eigenes oder das STM File System ersetzt werden.

So ist es wohl; da muß sich dann eine andere Lösung suchen.

Mittlerweile habe ich die Quellen soweit angepaßt, dass ich eine 
MMBasic-Version compiliert bekomme. Diese läuft auf einem STM32F407 mit 
168MHz CPU-Takt. Als ersten Anhaltspunkt für die Geschwindigkeit erhalte 
ich für eine Schleife:
10 for i=1 to 1000000
20 next
rund 7s Ausführungszeit. Das wären rund 140k Durchläufe/s.
Die FPU ist dabei aktiv; ohne FPU dauert die Schleife ca. 1s länger.
Kann mir jemand sagen, ob das schnell oder langsam ist?

von Micromite (Gast)


Lesenswert?

MMBASIC soll so etwa 25000 Programmzeilen pro Sekunde verarbeiten, wobei 
nicht geschrieben welchen Code die Zeilen enthalten.


Demnach wäre das etwa 6 mal schnelle als mit einem PIC.

Ich werde die Schleife einmal testen...

von m.n. (Gast)


Lesenswert?

Micromite schrieb:
> Ich werde die Schleife einmal testen...

Das wäre gut!

von Micromite (Gast)


Lesenswert?

Gerade getestet:

32 Sekunden auf einem PIC32MX150 bei 48MHZ.

von Micromite (Gast)


Lesenswert?

Rsepekt und Gratulation wenn Du das zum Laufen gebracht hast.
Ist das MMBASIC auf dem  STM32F407 schon voll funktionsfähig?

von Udo (Gast)


Lesenswert?

Weis ja nicht wie getestet wurde.
Habe mal die Schleife von oben durchlaufen
lassen. mit einem Pic auf 8MHz. Der braucht
dafür 20 Sekunden. PIC12F675.
War ein anderer Basic Compiler.

von m.n. (Gast)


Lesenswert?

Micromite schrieb:
> Ist das MMBASIC auf dem  STM32F407 schon voll funktionsfähig?

Nein; ich bin von der DOS-Version ausgegangen und mußte erst einmal jede 
Menge der DOS_io.c löschen, um überhaupt Land zu sehen. Die 
Speicherverwaltung muß noch eingehend untersucht und angepaßt werden.

Dann will ich das Basic auch einmal komplett auf double umstellen. Es 
dürfte dadurch nicht viel langsamer werden, hätte aber eine für alle 
Zwecke ausreichende Auflösung/Genauigkeit. Die 8 Byte / Variable sind 
beim ..F4xx verkraftbar.
Da ich schon eine TFT-Ansteuerung in der Schublade habe, die bei einem 
QVGA-Display etwa 80kB benötigt, blieben noch locker 50kB für 
Programmspeicher+Daten übrig. Weitere rund 60kB könnte man vom CCM-RAM 
nutzen.
Das sind so meine Vorstellungen bei der Sache.

Udo schrieb:
> War ein anderer Basic Compiler.

Wir haben hier einen BASIC-Interpreter, der zudem noch alle Variablen 
als float abarbeitet :-)

von Micromite (Gast)


Lesenswert?

Hallo m.n.

das Micromite Basic hat viele spezielle Funktionen für den Controller 
bezüglich I2C,RS232,SPI,RTC,PWM,IR,ADC,Servos.....

Auf der Roadmap vom Entwickler steht, das alles auch ins mmbasic 
einfließen zu lassen, mit den kommenden Versionen.

Ich denke es gibt daher schon signifikante Unterschiede zwischen der DOS 
Variante und der PIC spezifischen.
Letztere finde ich interessanter, da dies das Ziel der Entwicklung ist.
Die DOS Variante war wohl eher etwas "Spielerei".
Ich habe mir beide Sourcen noch nicht angeschaut, kann mir aber 
vorstellen,
das die PIC Variante als Ausgangsbasis schon die viel interessantere 
ist.

Schreib dem doch mal ne Mail über Dein Vorhaben/Stand.
Momentan entwickelt sich da ein kleiner Disput zwischen Programmieren 
welche auf mmbasic Basis Weiterentwickelungen betrieben haben, was Geoff 
zwar begrüßt, aber eben nur für den "privaten" Gebrauch.

Bei einer grundlegend anderen Plattform wird er dafür wohl sehr offen 
sein, was deren Verbreitung betrifft.

DS

von Micromite (Gast)


Lesenswert?

@ Udo

wir sprechen hier von einem Interpreter, nicht von compiliertem Code.
Lasst uns hier auch dabei bleiben, sonst reden wieder alle durcheinander 
;-)
Schon erstaunlich, dass der Interpreter nicht so viel langsamer ist !

DS

von Micromite (Gast)


Lesenswert?

@m.n.

Also da läuft jetzt bei dem STM kein DOS "command.com" mehr unten 
drunter; richtig?

von m.n. (Gast)


Lesenswert?

Micromite schrieb:
> das Micromite Basic hat viele spezielle Funktionen für den Controller
> bezüglich I2C,RS232,SPI,RTC,PWM,IR,ADC,Servos.....

Die sind letztlich das 'Spielzeug', was auf dem STM32 etwas anders 
aussehen muß und bei der ersten Inbetriebnahme nur stört.
Wenn man es braucht, schreibt man es dazu.

Micromite schrieb:
> Momentan entwickelt sich da ein kleiner Disput zwischen Programmieren
> welche auf mmbasic Basis Weiterentwickelungen betrieben haben, was Geoff
> zwar begrüßt, aber eben nur für den "privaten" Gebrauch.

Ich kann Geoff sehr gut verstehen (habe den o.g. Link dazu gelesen) und 
halte mich an seine Regeln. Mir geht es in erster Linie zu sehen, wie 
schnell so ein Interpreter laufen kann.

Micromite schrieb:
> Also da läuft jetzt bei dem STM kein DOS "command.com" mehr unten
> drunter; richtig?

Der Interpreter läuft auf einer kleinen Platine mit STM32F407 und wird 
per RS232 mit einem Terminalprogramm bedient. Wenn ich die Ausgabe 
umlenke, kann ich sie auch auf ein TFT bekommen. Mal sehen.

von m.n. (Gast)


Angehängte Dateien:

Lesenswert?

Wie gesagt, QVGA und mein Dank an Geoff Graham!

von Andreas H. (ahz)


Lesenswert?

Micromite schrieb:
> http://geoffg.net/micromite.html
>
> Schaut Euch das mal an, macht riesig Spass!

Ja, das klingt wirklich lustig. Erinnert mich an die Zeiten mit dem 
(legendären) HP-85. Nie wieder so schnell in IEEE-488 Messplätzen was 
zum laufen gekriegt ;-)

Natürlich haben sicher alle "Nörgler" hier recht. Heute ist da C(++) das 
Mittel der Wahl.

Trotzdem gibt es ja oft genug Fälle wo man gerne mal schnell einen uP 
anklemmt, der mit 3-Lines on-the-fly code beim Debuggen aushilft. Und 
das wächst ja auch oft zu n * 100 LOCs an.
Da kann ich mir so ein DIP28 Schwein mit Basic gut vorstellen ;-)


Carsten Sch. schrieb:
> Oder wie lange dauert es einen CAN Sniffer zu programmieren der die CAN
> Packets die über dem BUS laufen auf einem HD44780 kompatiblen LCD
> Display darstellt?

Das bringt Dir genau WAS ?

Ein "seriöser" CAN Sniffer haut Dir selbst bei 125KBit/s schon so viel 
Infos ins Log, das (zumindest mir) ein kleines TFT wenig helfen würde.

/Regards
Andreas

von W.S. (Gast)


Lesenswert?

m.n. schrieb:
> Der Interpreter läuft auf einer kleinen Platine mit STM32F407...

Bis du auf die STM32Fxxx festgelegt?

Hintergrund meinerseits: ich hab hier ne Eigenbau-Eval-Platte vorliegen, 
die ich vor ein paar Jahren mal für den LPC2478 gemacht hatte: LPC2478, 
dazu 16 MB SDRAM, dazu TFT-Ansteuerung (das Teil kann problemlos bis zu 
WVGA, also 800x480), dazu SD-Karte, dazu CODEC von TI, dazu nen CPLD für 
Unvorhergesehenes usw. Der Witz daran ist, daß die neueren Cortex M4 
(LPC4088) quasi als Drop-In benutzbar sind. Die bisherige Firmware 
(meinerseits) sieht in weiten Teilen so ähnlich aus wie das, was ich 
damals für die Lernbetty geschrieben habe, bloß eben mit buntem GDI, mit 
SD-Bedienung und mit virtuellem COM per USB. Komplett fertig ist die 
allerdings noch lange nicht, ich bin immer noch am Grübeln, ob und wie 
man ein dafür passendes EXE-Format kreieren könnte/sollte, um damit 
echte Programme von SD laden und starten zu können. Immer nur eins per 
.HEX finde ich albern und zu wenig, weswegen das Ganze derzeit ruht, 
aber mit einem residenten Basicinterpreter sieht das Ganze ganz anders 
aus.

Ich würde das Teil (genauer: die Eagle-Dateien dazu) in's Rennen werfen 
und die bisherige FW auf LPC4088 und diesen Interpreter umschreiben - 
wenn wir damit zu Potte kommen.

W.S.

von Carsten S. (dg3ycs)


Lesenswert?

Andreas H. schrieb:
> Carsten Sch. schrieb:
>> Oder wie lange dauert es einen CAN Sniffer zu programmieren der die CAN
>> Packets die über dem BUS laufen auf einem HD44780 kompatiblen LCD
>> Display darstellt?
>
> Das bringt Dir genau WAS ?
>
> Ein "seriöser" CAN Sniffer haut Dir selbst bei 125KBit/s schon so viel
> Infos ins Log, das (zumindest mir) ein kleines TFT wenig helfen würde.

Gefragt war hier nicht die Sinnhaftigkeit für ein konkretes Projekt 
sondern die Zeitdauer der Realisierung.

Aber wenn du die Sinnhaftigkeitsfrage beantwortet haben willst:
Für mich war dies ENORM HILFREICH da ich so nach wenigen Minuten das 
Problem erkannt habe ohne mich ins Auto setzen zu müssen um den CAN 
Fähigen LA von daheim zu holen und dann in der Folge auch noch die 
Software samt Protokolldekoder auf dem Firmenrechner installieren zu 
müssen.

Wenn der CAN Bus unter Vollast läuft nützt da ein vierzeiliges Display 
natürlich nichts. Aber oft ist die Zahl der Pakete ja sehr überschaubar. 
Und dann weiß man ja noch welche Pakete man erwartet und kann filtern...
Es muss ja nicht zwingend (im ersten Schritt) alles dargestellt werden. 
Das ist nur nötig wenn man überhaupt keine Ahnung hat wo das Problem 
liegen könnte.

Dank einer vorhandenen Baugruppe mit LCD Display auf der Pinnkompatibler 
Controller verbaut war lief das ganze in etwas über 20 Minuten.
Can-fähigen Controller von einer Protoplatine runtergenommen, statt des 
Originalcontrollers auf die Displayplatine gesetzt, In paar Litzen um 
den CanTreiber auf dem ProtoBoard mit dem Controller auf dem Display 
Board zu bverbinden und ca 15Minuten arbeit im Code. Lief!
10Minuten damit gearbeiten und dann war der Fehler gefunden.
Da wäre ich gerade erst daheim angekommen und aus dem Auto ausgestiegen 
beim LA holen.
(Im Anschluss an die Fehlersuche habe ich aber auch für die Firma einen 
neueren LA mit CAN Fähigkeit bestellt)

Gruß
Carsten

von Andreas H. (ahz)


Lesenswert?

Carsten Sch. schrieb:
> Wenn der CAN Bus unter Vollast läuft nützt da ein vierzeiliges Display
> natürlich nichts.

Eben ;-)

> (Im Anschluss an die Fehlersuche habe ich aber auch für die Firma einen
> neueren LA mit CAN Fähigkeit bestellt)

Würde ich auch dringend empfehlen :-D

/regards
Andreas

von m.n. (Gast)


Lesenswert?

W.S. schrieb:
> m.n. schrieb:
>> Der Interpreter läuft auf einer kleinen Platine mit STM32F407...
>
> Bis du auf die STM32Fxxx festgelegt?

Für den STM habe ich eine TFT-Ansteuerung mit touch-Bedienung als 
Bedienteil fertig, weshalb sich die Hardware für diesen Zweck anbot.

Die STM32F4xx sind sehr schnell und haben, soweit ich sehe, den größten 
internen RAM-Speicher als single-chip. Die ..F427/F429 haben sogar 256kB 
RAM, wo spielend der Bildschirmspeicher, Programm+Daten untergebracht 
werden können, wenn man nicht 'unsinnige' Anforderungen an Farbtiefe und 
TFT-Auflösung stellt.
Aber Deine LPC-Lösung sollte genau so gut verwendbar sein. Mit Deinen 
16MB SDRAM brauchst Du bei der DOS-Version auch den vorgesehen 
Heap-Bereich von 512kB nicht zu verkleinern :-)

Da man sich verpflichtet, den erhaltenen Quellcode nicht weiterzugeben, 
ist ein lockerer Austausch ausgeschlossen. Aber besorge Dir den 
Quellcode und sieh ihn Dir an. Dann kann man weiterreden.

Bezüglich der Hardware würde mir der ..F407 voll reichen, den man ggf. 
mit einer SD-Karte kombiniert oder einfach ein serielles EEPROM mit 
MB-Größe als Programm und Datenspeicher als simple Ablage benutzt.

Noch haben wir eine kühle Maiwoche vor uns; dann wird das Wetter wieder 
zu gut, um noch Bits+Bytes zu schaufeln.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

Nur mal so aus meiner Erfahrung:

Ich bin neu in die Firma gekommen, vorher nur ASM und Pascal.

Ein Ing hatte ein Programm in GWBASIC geschrieben und nach >1200
Zeilen übelstem Spaghetticode den Überblick dermaßen verloren, daß
er es hingeschmissen hat.

In ASM wäre das Projekt (Compiler für Bestückprogramme) zu aufwendig
gewesen, also habe ich das mal in C angefangen (Aztek Manx auf eigene
Kappe gekauft). Resultat: Laufzeitverbesserung Faktor 2000 (!).

BASIC: Beginner’s All-purpose Symbolic Instruction Code
sagt alles ;)

von Peinlicher geht es kaum. (Gast)


Lesenswert?

@ Joachim Drechsel (Firma: JDCC) (scheppertreiber)

Was für eine Schande: So ein toller Kerl wie Du muss sich auch noch 
selbst beweihräuchern.

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

Peinlicher geht es kaum. schrieb:
> @ Joachim Drechsel (Firma: JDCC) (scheppertreiber)
>
> Was für eine Schande: So ein toller Kerl wie Du muss sich auch noch
> selbst beweihräuchern.

Moin Gast,

kein Weihrauch. Nur meine Erfahrungen.

von Rudolf (Gast)


Lesenswert?

Stefan schrieb:
> Die heutigen Basic Compiler sind dem C fast gleich.

Ha ha ha ha ha .... Muhahaha ha ha

von W.S. (Gast)


Lesenswert?

Joachim Drechsel schrieb:
> Nur mal so aus meiner Erfahrung:...

Ach ja, bescheuerte Erfahrungen hat wohl jeder von uns. Aber das hängt 
eigentlich NIEMALS an irgendeiner Programmiersprache, sondern immer nur 
an der Blödheit der Leute. Schau dich hier im Forum um und du wirst 
sehen, daß die allermeisten nicht mal richtig denken können: "Wie 
schafft ihr das, nicht blockierend zu schreiben..." oder "wie kan man 
PortA..PortD zwischen AVR und ARM vereinheitlichen.." oder "wie schreibe 
ich ein Menü" und so weiter.

Es ist immer wieder das fehlende Denkvermögen, was verhindert, daß die 
Leute ihr Problem analysieren und sich eine funktionierende Lösung 
ausdenken können. Stattdessen wird lustig in die Tasten gehauen und 
drauflosprogrammiert und dann kommen bei deinem Ex-Kollegen plötzlich 
1200 Zeilen Basic heraus, wo er nicht mehr durchsieht. ich bin mir 
völlig sicher, daß man das Problem auch in Basic hätte gut lösen können, 
wenn denn systematisch und überlegt vorgegangen wäre.

W.S.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

@ Schleppertreiber

oh weh,
willst du jetzt den Thread kippen oder wirst du verstehen, dass es noch 
andere Prämissen als nur Effizienz des Codes gibt?

Wer im Büro sitzt und Standardsoftware für Industrieanwendungen schreibt 
stellt freilich andere Anforderungen an Hard- und Software als der 
Service-Troubleshooter im Außeneinsatz, der oft zu Anlagen gerufen wird 
die er zuvor nicht gesehen hat, nicht weiß was ihn erwartet und manchmal 
noch nicht mal eine Produktbeschreibung vorfindet. Da hast du einfach 
keine Zeit und oft auch keine HW welche geeignet ist ein professionelles 
Programm zu schreiben oder ein passendes Tool aufzutreiben.

Der Servicetechniker benötigt ein Tool welches alles kann und leicht 
konfigurierbar ist um in der vorgefundenen Situation effektiv handeln zu 
können. Dafür ist ein Basic Interpreter mit diversen Schnittstellen, 
einfacher Programmierbarkeit und wenig externer HW genau das Richtige. 
Natürlich ist es sinnvoll den CAN-Bus in C zu compilieren weil Standard. 
Aber alles spezifische sollte man vor Ort möglichst flexibel gestalten 
können. Die eierlegende Wollmilchsau, welche die Industrie, eben aus 
Effizienzgründen nie  wird bauen können, baut sich selbst, wer es 
vermag. Und da kommt es nicht darauf an den letzten Cent oder die letzte 
Performance heraus zu quetschen, sondern die höchste Flexibilität bei 
vertretbarer Performance und Kosten.

: Bearbeitet durch User
von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

W.S. schrieb:
> Joachim Drechsel schrieb:
>> Nur mal so aus meiner Erfahrung:...
>
> Ach ja, bescheuerte Erfahrungen hat wohl jeder von uns. Aber das hängt
> eigentlich NIEMALS an irgendeiner Programmiersprache, sondern immer nur
> an der Blödheit der Leute. Schau dich hier im Forum um und du wirst
> sehen, daß die allermeisten nicht mal richtig denken können: "Wie
> schafft ihr das, nicht blockierend zu schreiben..." oder "wie kan man
> PortA..PortD zwischen AVR und ARM vereinheitlichen.." oder "wie schreibe
> ich ein Menü" und so weiter.

Ok, jeder fängt halt mal an.

Der Knackpunkt für mich war der Basic-Spaghetticode der das Programm
unflegbar gemacht hatte. Ich glaube, so etwas geht in C gar nicht ...

Winfried J. schrieb:
> Der Servicetechniker benötigt ein Tool welches alles kann und leicht
> konfigurierbar ist um in der vorgefundenen Situation effektiv handeln zu
> können. Dafür ist ein Basic Interpreter mit diversen Schnittstellen,
> einfacher Programmierbarkeit und wenig externer HW genau das Richtige.

Mag sein, kann ich nicht beurteilen.

Ich habe mal erlebt wie ein Servicemann 1 1/2 Tage aus Ausdrucken
Basic Code eingetippt hat. Er nannte das "installieren". Effizienz
ist etwas anderes. C-Compiler gibt es überall.

von Neutraler Nick (Gast)


Lesenswert?

Joachim Drechsel (Firma: JDCC) (scheppertreiber) schrieb:

> BASIC: Beginner’s All-purpose Symbolic Instruction Code
> sagt alles ;)

" 50 Jahre BASIC: die Allzweck-Programmiersprache für Anfänger feiert 
Jubiläum "

http://www.heise.de/developer/meldung/50-Jahre-BASIC-die-Allzweck-Programmiersprache-fuer-Anfaenger-feiert-Jubilaeum-2178897.html

" Die Erfinder der Programmiersprache BASIC schufen tatsächlich das, was 
sie sich erhofft hatten: die einfache und jedem zugängliche 
Programmierung. "

Was will man mehr. 50 Jahre und noch immer auf dem Posten. Da haben 
manche bereits den Löffel abgegeben.

;-)

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

Joachim Drechsel schrieb:
> Mag sein, kann ich nicht beurteilen.
>
eben

> Ich habe mal erlebt wie ein Servicemann 1 1/2 Tage aus Ausdrucken
> Basic Code eingetippt hat. Er nannte das "installieren". Effizienz
> ist etwas anderes. C-Compiler gibt es überall.

Das ist weder Installieren, noch effizient und Genau das benötigt das 
Ding nicht. der Interpreter Kann 4 GB SD Karten Fat16 Fat32 lesen mit 
TFT Monitoren oder diversen Schnittstellen arbeiten, ebenso wie mit 
einer PS2 Tastatur sogar Touchsreen ist schon demonstriert worden. zudem 
ist das System offen für Erweiterungen in C oder ASM. Mithin ist es weit 
mehr als ein Spielzeug. Es ist eine Basis für Eigenentwicklungen auf 
hohen Niveau.

Also lass es jenen welche sich etwas denken und schaue nicht auf sie 
herab könnte sein sie stehen gerade über dir, wer weiß das schon. Besser 
überlegst du was andere motiviert Dinge zu tun welche du lassen würdest, 
dann wirst du erkennen, dass die Welt und das Leben komplexer verlaufen 
als eine Einbahnstraße.

Namaste

von m.n. (Gast)


Angehängte Dateien:

Lesenswert?

Noch eine kleine Spielerei mit double-Zahlen.
Eine leere Schleife mit 1E6 Durchläufen braucht ca. 9,3 Sekunden. Die 
nachfolgende Schleife mit x = i*i etwa 47 Sekunden.
Verrechnet man die Durchlaufzeiten, so braucht die durchschnittliche 
Multiplikation i*i etwa 38µs.

Ein Test mit
10 For i=1 To 100 Step 0.01
20 x = Pi^i
30 Next
braucht ca. 0.8 Sekunden, was pro Durchlauf rund 80µs bedeutet.
Die bei mir auf 15 Stellen begrenzten Ergebnisse ließen sich mit einem 
Taschenrechner leider nicht überprüfen :-)

von Micromite (Gast)


Lesenswert?

@m.n

Wie steuerst Du das Display an, sind das die Routinen für das PIC VGA 
Interface von Geoff?

Was ist das für ein Display?

von m.n. (Gast)


Lesenswert?

Da koche ich meine eigenen Suppen: 
http://www.mino-elektronik.de/TFT-direct-drive/TFT-direct-drive.htm
Unter Punkt 5. findet sich die Ausführung mit dem ..407. Das Display ist 
von EDT, welches sich mit den Befestigungslaschen gut montieren läßt.
Bei 8x16 Zeichen passen 15 Zeilen mit je 40 Zeichen aufs 5,7" QVGA-TFT. 
Zeichensätze habe ich momentan CP850, CP866 und einen mit 6x10.
Zu sehen sind auch Beispiele für 4,3"-TFTs mit 480x270 Auflösung, die 
zwar günstig zu beschaffen sind, aber die touch-Bedienung per Finger 
eingrenzen.
Für mich ganz wichtig ist die Möglichkeit, einzelne Pixel/Zeichen 
blinken zu lassen.

Zuletzt hatte ich die Speichernutzung des ..407 so angepaßt, dass im 
'regulären' Speicher 0x20000000-0x2001ffff Bildspeicher + Stack + 
Variablen des Interpreters selbst liegen; das BASIC-Programm nebst 
eigenen Variablen liegt im CCM-Bereich ab 0x10000000, der 64KB groß ist. 
Das reicht für meine Spielerein locker.

Dann bin ich an dem Punkt angekommen, wo es zwingend notwendig wird, das 
eingegebene Programm abzuspeichern und zumindest einzelne Zeilen zu 
edieren. Letzteres ist kein Problem, die Abspeicherung bedarf aber 
einiger Arbeit. Die eingeschränkten Nutzungsrechte nehmen zunehmend die 
Form von Fußfesseln an :-)
Kommt Zeit - kommt Rat.

von Martin (Gast)


Lesenswert?

m.n. schrieb:
> Dann will ich das Basic auch einmal komplett auf double umstellen. Es
> dürfte dadurch nicht viel langsamer werden, hätte aber eine für alle
> Zwecke ausreichende Auflösung/Genauigkeit. Die 8 Byte / Variable sind
> beim ..F4xx verkraftbar.

und im Beitrag #3642461:
> Noch eine kleine Spielerei mit double-Zahlen.
> Eine leere Schleife mit 1E6 Durchläufen braucht ca. 9,3 Sekunden. Die
> nachfolgende Schleife mit x = i*i etwa 47 Sekunden.
> Verrechnet man die Durchlaufzeiten, so braucht die durchschnittliche
> Multiplikation i*i etwa 38µs.
>
> Ein Test mit
> 10 For i=1 To 100 Step 0.01
> 20 x = Pi^i
> 30 Next
> braucht ca. 0.8 Sekunden, was pro Durchlauf rund 80µs bedeutet.
> Die bei mir auf 15 Stellen begrenzten Ergebnisse ließen sich mit einem
> Taschenrechner leider nicht überprüfen :-)

Ist es nicht so, dass der Cortex M4F nur single precision in Hardware 
rechnen kann, double precision hingegen muss vollständig in Software 
gemacht werden und ist daher langsamer ?!
Dann würde ich den Float-Datentyp (32bit) besser (evtl. als Option) 
belassen, um für geringere Genauigkeitsanforderungen die höhere 
Geschwindigkeit nutzen zu können.
Oder kann ein Cortex M4F echte double-Zahlen in Hardware ?

von m.n. (Gast)


Lesenswert?

Martin schrieb:
> Ist es nicht so, dass der Cortex M4F nur single precision in Hardware
> rechnen kann, double precision hingegen muss vollständig in Software
> gemacht werden und ist daher langsamer ?!

Der M4F kann nur float per Hardware berechnen, aber wenn Du die Zeiten 
für 1E6 leere Schleifen vergleichst 7 bzw. 9 µs/Durchlauf, sieht man 
doch, dass die Rechenzeiten von float/double hier keine wesentliche 
Bedeutung haben.

> Dann würde ich den Float-Datentyp (32bit) besser (evtl. als Option)
> belassen, um für geringere Genauigkeitsanforderungen die höhere
> Geschwindigkeit nutzen zu können.

Mach, wie Du meinst. Aber dann kommt bald Jemand, der wieder int32_t 
rechnen möchte und irgendetwas von Fixpoint und schnell schwafelt. Tut 
mir leid, aber das ist nicht mehr zeitgemäß.

Schnelle double-Berechnungen sehe ich als positives 
Alleinstellungsmerkmal, auch wenn AVR-GCC und Arduino-Nutzer vermutlich 
nichts damit anfangen können.
Aus Jux noch einmal gerechnet: PI^500. Das Ergebnis ist (hoffentlich 
richtig): 3.75782323229248E+248. Die Zeit für eine 100000 Schleife liegt 
bei 8,03s, was rund 80µs/Durchlauf ergibt.

von Micromite (Gast)


Lesenswert?

m.n. schrieb:
> Die eingeschränkten Nutzungsrechte nehmen zunehmend die
> Form von Fußfesseln an :-)
> Kommt Zeit - kommt Rat.


Schreib Geoff ne Mail und der gibt das frei...

Kommerziell wird es nicht so leicht...

von W.S. (Gast)


Lesenswert?

Joachim Drechsel schrieb:
> Der Knackpunkt für mich war der Basic-Spaghetticode der das Programm
> unflegbar gemacht hatte. Ich glaube, so etwas geht in C gar nicht ...

Du Witzbold! In C geht das noch viel schlimmer, es ist bloß strukturell 
etwas anders gelagert.

Ich hatte mal ein Projekt vor der Nase, wo sich mehrere geschachtelte 
#ifdef über mehrere Dateien hinzogen. Sowas ist klasse, man weiß 
wirklich nicht mehr, welche Quelle und welcher Teil davon denn nun 
tatsächlich im Programm landet.

Eine beliebte Sache ist auch, zum Erstellen einer Konfigurationsdatei 
(ohne die mal dank 1003 #ifdef's in jeder Quelle nicht auskommt) und 
eines dazugehörigen Makefiles ein Shellscript zu benutzen. Ganz grandios 
sowas, siehe z.B. ECOS.

Gegen C-Spaghetticode sind ALLE Basic-Schreiber zusammengenommen nur 
eine blasse Minderheit.

W.S.

von Jürgen G. (pre8)


Lesenswert?

ich nutze den micromite selbst und muss sagen es macht spass.

echtes rapid development im hobbybereich. und wer will kann seine c oder
asm routinen einbinden.

@ m.n. respekt zu deiner implementierung .

von Micromite (Gast)


Lesenswert?

und wer will kann seine c oder
asm routinen einbinden......

Aha, wie geht das denn ?

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

Micromite schrieb:
> und wer will kann seine c oder
> asm routinen einbinden......

Warum ??? umkipp

von Micromite (Gast)


Lesenswert?

Nein, das schrieb Jürgen/ pre8.

Und ich fragte wie er das denn nun macht?!

von Jürgen G. (pre8)


Lesenswert?

nun für den micromite brauchst du dummerweise den pro compiler
aber für den maximite kannst du die free version nutzen .
das einbinden eigener befehle ist wirklich einfach und schnell zu 
bewerkstelligen wenn du c grundkenntnisse hast.

ich bastel mir gerade ne ws2812b routine.
die rgbdaten kommen per bluetooth vom handy über com1.


@ micromite  gugst du backsheed ? (atmega8 ? )



@ scheppertreiber

sie sollten ihren gyro mal kalibrieren und neu justieren.





@m.n. was macht die kunst ?

von Joachim D. (Firma: JDCC) (scheppertreiber)


Lesenswert?

Mal im Ernst: Warum soll ich in C Erweiterungen für irgendein
BASIC schreiben wenn ich das Original nehmen kann ?

Das wäre ja total abgedreht.

von m.n. (Gast)


Lesenswert?

Joachim Drechsel schrieb:
> Mal im Ernst: Warum soll ich in C Erweiterungen für irgendein
> BASIC schreiben wenn ich das Original nehmen kann ?
>
> Das wäre ja total abgedreht.

Ganz einfach, um den Funktionsumfang des Interpreters für spezielle 
Hardware zu erweitern. Beispielsweise die Ansteuerung von DC- oder 
Schrittmotoren, die dann direkt über eigene BASIC-Befehle angesprochen 
werden können und die dafür notwendige Interruptverarbeitung im 
Hintergrund erledigen.
Natürlich kann man das alles in C lösen, und niemand zwingt Dich, dies 
nicht auch zu tun.
Ebenso wenig mußt Du für Internet-Inhalte html verwenden, was 
ausgesprochen langsam auf jedem Rechner erst interpretiert werden muß. 
Schreib alles in C; dann kann sich der geneigte Leser das geladene 
Programm auf seinem Rechner starten und alles blinkt und glitzert viel, 
viel schneller :-)

Ein schneller BASIC-Interpreter erlaubt es, ohne großen PC-Überhang 
kleinere Anwendungen direkt im Zielsystem zu entwickeln und auch zu 
modifizieren. Als Beispiel fallen mir Steuerungen für Antriebe ein, 
wobei diverse Bewegungen erledigt werden müssen. Hier ist es dann recht 
einfach, das Timing an die speziellen Lasten vor Ort anzupassen (z.B. 
kurze Pause nach einem Stopp, um Schwingungen abzuwarten).
Natürlich geht das auch alles in C und auch 100x schneller. Aber was 
nutzt die hohe Ausführungsgeschwindigkeit, wenn der µC nur in 
Warteschleifen hängt. In einem fertigen C-Programm kann man nicht mal 
eben vor Ort Parameter ändern, es sei denn, man hat alle eventuellen 
Änderungsmöglichkeiten parametrierbar programmiert (und bestimmt eine 
davon vergessen).
Im Extremfall kann man dem Anwender sogar sagen, wie er die 'Kiste' 
anhalten kann und welche Zeile wo einzufügen ist: Fernwartung unter 
Erhalt von Arbeitsplätzen :-)

Jürgen G. schrieb:
> @m.n. was macht die kunst ?

Ich sehe mich nach sinnvoller Ansteuerung von SD-Karten um. Im Netz gibt 
es viele Beispiele, die ich zur Zeit sondiere; aber Arbeit macht es 
dennoch.
Ein wenig optimiere ich noch die TFT-Ausgabe für mein QVGA. Im Textmodus 
40x15 dauert ein 'scroll' jetzt rund 1ms und den ganzen Schirm (600 
Zeichen) vollzuschreiben, braucht jetzt nur noch 34ms. Kaffeepausen 
entfallen somit.

Jürgen G. schrieb:
> das einbinden eigener befehle ist wirklich einfach und schnell zu
> bewerkstelligen wenn du c grundkenntnisse hast.

So ist es! Je länger man sich die Quellen ansieht, so mehr sieht man die 
gute Struktur und die jahrelange Arbeit die dahinter steckt.

von Micromite (Gast)


Lesenswert?

Schade das Eure Erweiterungen nicht der Allgemeinheit zugänglich sind...

von Micromite (Gast)


Lesenswert?

Saubeeeer:


A new version of MMBasic (ver 4.5) for the Maximite, Colour Maximite, 
DuinoMite and compatible devices is available for download from 
http://geoffg.net/maximite.html#Downloads
This is a major update.  The highlights are:
•  Support for a number of hardware devices that was originally 
developed for the Micromite.  This includes Infra-red remote control 
receiver and transmitter, ultrasonic distance sensors, LCD display 
modules, the DS18B20 temperature sensor, numeric keypads and battery 
backed clocks.

•  A number of other improvements that were developed for the Micromite 
(including a better SETPIN command, improved PEEK/POKE, etc).

•  Support for more I/O pins on the TFT Maximite and additional commands 
to enable/disable controls.

•  Many bug fixes.
Note that significant changes has been made to the I2C and 1-Wire 
commands.  This was done to make these functions work more efficiently 
inside MMBasic however the changes will break existing programs that 
used either of these protocols.  You should review the need to upgrade 
if you have an existing program that makes heavy use of these.
If you have not already done so, you should also check out the Micromite 
(http://geoffg.net/micromite.html).  This is a low cost 28-pin chip that 
runs MMBasic.  It has most of the features of Maximite but is intended 
to be used as a powerful but easily programmed microcontroller for 
electronics projects.

von Fabrice (Gast)


Lesenswert?

Hallo ,

Ist hier etwas neue an diese Projekt ?
Wird auch gut der stm32 Source von mmbasic zu haben das mir das testen 
konnte :)

Gruß.

von Micromite (Gast)


Lesenswert?


von m.n. (Gast)


Lesenswert?

Auf Anfrage hatte mir Geoff erlaubt, eigene Compilate oder eine 
entsprechende .lib für den STM zu verbreiten, wobei sein Copyright 
erkenntlich bleibt. Als Basis dafür werde ich vermutlich Em::blocks 
verwenden.
Für die Verbreitung des Quellcodes hat er mir angeboten, diesen auf 
seiner Seite zu seinen Lizenzbedingungen zugänglich zu machen. Derzeit 
ist das aber noch Zukunftsmusik!

Gegen Jahresende werde ich eine kleine Platine fertig haben, die das 
gleiche 4,3" Display wie das Original (bei Segor für € 25 zu haben) 
verwendet und wahrscheinlich den STM32F427 (wegen des etwas größeren 
RAMs) enthält.
Wer allerdings eine 1:1 Kopie des Originals erwartet, wird enttäuscht 
werden. Welche Pins und Schnittstellen verfügbar sein werden, wird mein 
Bauch entscheiden :-)

von Fabrice (Gast)


Lesenswert?

Hallo ,

@micromite : Die pic32 source habe ich , aber ich denke das ich nicht 
das gut bin für eine stm32 Version raus zu bringen ;)

Für stm32 Version , besser ist der stm429 zu benutzen , der dma2d und 
ltdc mach schon alles in Hintergrund für den LCD ;)
Für die VGA/LCD konnte schon mein libs benutzen , das ist schon viel 
Arbeit
weniger zu tun :)
Ich habe also auch der Mod player Routine fertig ..
... alles ist hier :
https://sites.google.com/site/suprabotics/

Bis bald ..

Gruß.

von plasma (Gast)


Lesenswert?

@ m.n

was sagt dein bauch ?

von m.n. (Gast)


Lesenswert?

plasma schrieb:
> @ m.n
>
> was sagt dein bauch ?

Zunächst muß mein Hirn eine sinnvolle Belegung der Steckverbinder auf 
die Reihe bekommen. Momentan ist das Wetter noch zu gut dafür.
Erst dann kommt mein Bauch ins Spiel ;-)

Was ich vorsehen werde, ist ein 100-pol. Prozessor, neben einem Quarz 
auch einen TCXO, einen Vorteiler für Frequenzmessung, mini-USB, 
micro-SD, MAX3232 für direkten RS232-Betrieb, separates EEPROM und 
Batteriepufferung für die interne Uhr+RAM.
Als Vorversuch für meine Spielerei, habe ich erst einmal eine andere 
Schaltung aufgebaut: 
http://www.mino-elektronik.de/FM_407/fmeter_407.htm#a2
Hier überlege ich, ob ich das Programm noch um eine 
MaxiMite-BASIC-Version ergänze (oder auch anders herum), um die 
möglichen Parameter flexibel einstellen zu können und die Ausgangswerte 
damit umzurechnen.

Ich bleibe am Ball, brauche aber meine Zeit. Geduld!

von micromite (Gast)


Lesenswert?

Ein neues Basic für den 170 MX ist raus.
Schneller und mit "modernen" Spracherweiterungen.

CFunktion für Assembler oder C Code Einbettung; cool.

Beta Tester werden gesucht.

Ich Beta Teste bereits und bin begeistert ;-)

von G.J. (Gast)


Lesenswert?

micromite schrieb:

> Ein neues Basic für den 170 MX ist raus.
> Schneller und mit "modernen" Spracherweiterungen.
>
> CFunktion für Assembler oder C Code Einbettung; cool.
>
> Beta Tester werden gesucht.
>
> Ich Beta Teste bereits und bin begeistert ;-)

Link?

von M. N. (Gast)


Lesenswert?

Zum einen habe ich hier die "Stiftleisten-Belegung TFT Maximite 1.4" und 
die "TFT MM Dimensions 1.4" vor mir.
Kann mir Jemand beschreiben, wie 4,3" TFT, Platine und Frontplatte 
mechanisch miteinander verbunden sind? Eigentlich möchte ich die 
Leiterplatte so klein halten, dass sie noch von hinten huckepack aufs 
TFT 'abstandsgebolzt' werden kann.

Dann habe ich die Belegung der o.g. Stiftleisten funktional 
nachempfunden, was teilweise gut geht (26-pol. PL6) aber, gepaart mit 
dem Port-Wildwuchs des STM32 selber, dann doch zu einer recht konfusen 
I/O-Verwendung führt. Nichtsdestoweniger bleiben noch einige 'schöne' 
Pins übrig.

Wenn ich die mittlerweile vielen Variationen der X-mite Platinen ansehe, 
wird es schwierig, einen sinnvollen Nenner zu finden.
Jetzt kommt mein Bauch: ich brauche keine missglückten 
Arduino-kompatibelen Steckverbinder, keinen 1-Draht Temperatursensor, 
keine PWM-Musik, keine IR-Fernbedienung und diverse andere 
'Bastelgimmiks'.
Daher meine Frage an Euch, worin besteht denn Euer Hauptinteresse bei 
einer STM32F4 Adaption?

Mich interessiert zunächst einmal die hohe Rechengeschwindigkeit mit 
hoher Rechengenauigkeit in ein bestehendes/zu entwickelndes Gerät zu 
integrieren. Einfaches I/O könnte man mit besserer Struktur durch 
IIC-Portextender oder auch Schieberegister erreichen, als durch 
verwurschtelte Portpins.
Ohne gleich ein komplettes Filesystem mit SD zu installieren, wäre ein 
einfaches Abspeichern und Laden des Anwendungsprogrammes (mit autostart) 
auch in einem IIC-EEPROM / SPI-Flash möglich.
Und um von der Hardware einen alternativen Ansatz zu haben, könnte man 
das steckerkompatibel zu einem STM32F407-Discovery-Board gestalten. Das 
Basic wäre dann per UART über Terminal bedienbar und ohne großen Aufwand 
von Interessierten nachzubauen. Das wäre aus meiner Sicht eine 
Möglichkeit, Schritt für Schritt zu einer kompletten Version von HW und 
SW zu kommen.

Was ist Eure Meinung dazu?

von M. N. (Gast)


Angehängte Dateien:

Lesenswert?

Anbei der noch nicht abgeschlossene Schaltungsentwurf. TFT+SD Stecker 
sind auf einem anderen Blatt (hier nicht gezeigt).

von Plasma (Gast)


Lesenswert?

Logischerweise wuerde ich den schnellsten chip mit dem meisten ram und 
flash benutzen.
Die bastelgimmiks sind eh alles
Portfunktionen,kannste spaeter machen, lcd support ist cool.
Ich werde mir den stm mal ansehen
Und mich melden.
Tja was solls werden micro oder maximite? Ist das plugin auch 
Realisierbar?
Und wieviel schneller ist es den jetzt , auf backsheed hat kiiid
Einen clone beschrieben der mit
Standardhardware schon mal 40% ruppt.
Gruss

von m.n. (Gast)


Lesenswert?

Plasma schrieb:
> Und wieviel schneller ist es den jetzt ,

Das hatten wir weiter oben schon mal ergründet.
Beitrag "Re: PIC 32 schneller Basic Interpreter"

Da ich auf meine obigen Fragen aber keine Antwort bekommen habe, 
schraube ich die Priorität von 'Ende des Jahres' auf 'vielleicht 
irgendwann'. Da koche ich dann meine Suppe und esse sie allein ;-)
An anderer Stelle hatte ich die bislang verwendete Hardware angeboten 
(Platine+Display)
Beitrag "[V] QVGA-Controller Platine mit STM32F407"
Beitrag "[V] 5,7"-TFT QVGA, gebraucht"
aber das ist wohl auch Alles nicht das, was Bastlers Herz höher schlägen 
läßt.

von plasma (Gast)


Lesenswert?

schade .

von Lothar S. (loeti)


Lesenswert?


von Guido L. (guidol1970)


Lesenswert?

m.n. schrieb:
> Da ich auf meine obigen Fragen aber keine Antwort bekommen habe,
> schraube ich die Priorität von 'Ende des Jahres' auf 'vielleicht
> irgendwann'. Da koche ich dann meine Suppe und esse sie allein ;-)

Wuerde Dein STM32-Basic nicht auf dem STM32F429 laufen?
http://www.amazon.de/gp/product/B00HGG0KHY/

So eine Platine waere schon teilweise aufgebaut und gut verfuegbar.

Ich selbst mag MM-Basic schon auf dem Duinomite, weil man einen Mico- 
oder Maximite nicht so gut bekommt.

Nun gehen die Duinomite sicher bald aus, weil die nicht mehr 
nachproduziert werden und noch kein deutscher DIstributor MicroMite im 
Angebot hat.

Andere Firmen sind noch nicht "auf den Zug" aufgesprungen :(

Einzig byVAC hat den BV508 (PIC32MX170) , bei dem man ueberlegen 
muesste, ob da MMBasic auch drauf zu bekommen waere....
http://www.bypic.byvac.com/index.php/BV508
bzw.
http://www.bypic.byvac.com/index.php/BV502_V2

von Mittelweller (Gast)


Lesenswert?

Guido Lehwalder schrieb:
> m.n. schrieb:
>> Da ich auf meine obigen Fragen aber keine Antwort bekommen habe,
>> schraube ich die Priorität von 'Ende des Jahres' auf 'vielleicht
>> irgendwann'. Da koche ich dann meine Suppe und esse sie allein ;-)
>
> Wuerde Dein STM32-Basic nicht auf dem STM32F429 laufen?
> http://www.amazon.de/gp/product/B00HGG0KHY/
>
> So eine Platine waere schon teilweise aufgebaut und gut verfuegbar.
>
> Ich selbst mag MM-Basic schon auf dem Duinomite, weil man einen Mico-
> oder Maximite nicht so gut bekommt.
>
> Nun gehen die Duinomite sicher bald aus, weil die nicht mehr
> nachproduziert werden und noch kein deutscher DIstributor MicroMite im
> Angebot hat.
>
> Andere Firmen sind noch nicht "auf den Zug" aufgesprungen :(
>
> Einzig byVAC hat den BV508 (PIC32MX170) , bei dem man ueberlegen
> muesste, ob da MMBasic auch drauf zu bekommen waere....
> http://www.bypic.byvac.com/index.php/BV508
> bzw.
> http://www.bypic.byvac.com/index.php/BV502_V2

Ich verstehe Euer Problem bezüglich der geeigneten Hardware nicht.

Der aktuelle MKII Mmbasic läuft mit den MX 170/270.
Das ist das Micromite MMBasic, also ohne Grafik, aber aktuell und mit 
Support für LCD, DS18b20, DHT Sensoren, Servo, IR, I2C, RTC....
Dazu reicht ein kleiner Elko, fertig ist der gesamte Rechner.
Das baue ich in 10 Minuten auf Lochraster.
Für die TQFP kann man die überall verfügbaren Adapterplatinen nehmen.
Z.Bsp. das hier http://www.ebay.de/itm/like/151323069957?lpid=106&chn=ps

von m.n. (Gast)


Lesenswert?

Guido Lehwalder schrieb:
> Wuerde Dein STM32-Basic nicht auf dem STM32F429 laufen?
> http://www.amazon.de/gp/product/B00HGG0KHY/

Schon, aber wozu?
Das wäre eine Spielzeug-Bastel-Lösung: kleines Display, keine sinnvollen 
IO-Leitungen, keine SD-Card und nicht einmal EEPROM. Dafür jede Menge 
Kram, den man für 'produktiven' Einsatz nicht braucht.

Das Schöne an Micro-/Maximite ist doch die minimalistische Lösung mit 
einem Chip ergänzt um (EE-)Programm-/Datenspeicher, Tastatur (bzw. 
RS232) und lesbares Display als 'standalone' Baugruppe; sinnvolle 
IO-Anschlüsse, selbststartendes Programm und im System 
programmier-/modifizierbar.
Nicht mehr - und nicht weniger; das gibt es bereits in voller Funktion!

Aus meiner Sicht spräche für einen ..F407 die deutlich höhere 
Geschwindigkeit inkl. 'double'-Berechnungen.

von J.G. (Gast)


Lesenswert?

Hi ,

In anbetracht des erwarteten F7
werde ich mich mal an eine mK2
Portierung setzen.

von PICObello (Gast)


Lesenswert?

Und nu ???


Was geht ?

von jg (Gast)


Lesenswert?

nun wirds ein community project :)
anfänge sind gemacht

von Jg (Gast)


Lesenswert?

Beta ist raus

von stm fan (Gast)


Lesenswert?

Hallo ,

Geil das eine Version raus ist , funktioniert sogar gut !!
Aber ist auf der alte stm32f407 gemach.
Ist vielleicht eine stm32f429 geplant ?
Wurde wirklich toll , mit integrierte lcd Treiber und nicht externe 
Controller zu benutze ;)

Gruß.

von pre (Gast)


Lesenswert?

wir sind dabei ne 429 zu machen

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.