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!
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.
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...
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.
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
;-)
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))
;-)
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 ;-)
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 :-)
@ 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
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
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,...
> 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 ;-)
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?
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...
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.
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 !
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;-)
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)
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
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.
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.
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
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.
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.
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
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 ...
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.
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.
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.
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.
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
> 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.
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
>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.
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
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?
>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.
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
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.
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
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
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.
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
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.
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.
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.
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...
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.
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;-)
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
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.
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
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.
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..?
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
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
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.
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
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
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.
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.
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.
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!
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
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.
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.
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.
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.
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
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?
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...
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.
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 :-)
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
@ 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
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.
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
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.
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
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
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.
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 ;)
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.
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.
@ 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.
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.
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.
;-)
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
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 :-)
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.
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 ?
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.
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...
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.
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 .
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 ?
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.
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.
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 :-)
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ß.
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!
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 ;-)
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?
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?
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
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.
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
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
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.
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ß.
