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
"Das alles für 2.50€, ..." @ Micromite Wo kaufst du den Chip für 2,50 Euro? Wie kann kostengünstig der Interpreter geflasht werden?
Bernie schrieb: > Wie kann kostengünstig der > Interpreter geflasht werden? PICkit3 China Clone, das ist eine einmalige Investition. Wenn du das dazurechnen willst, dann bitte auch den Lötkolben und vllt. auch noch den PC,...
:
Bearbeitet durch User
> 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?
Bernie schrieb: > Wie viele Firmen hast du mit deiner Kalkulationsmethode bereits zugrunde > gerichtet? Moment... Lass mich nachzählen... ... ... Null.
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)
|
7 | #define GetSystemClock() 60000000UL
|
8 | #define GetPeripheralClock() 60000000UL
|
9 | #define GetInstructionClock() (GetSystemClock() / 2)
|
10 | |
11 | #define BAUDRATE2 115200UL
|
12 | #define BRG_DIV2 4
|
13 | #define BRGH2 1
|
14 | |
15 | //Programmbeginn
|
16 | void main() |
17 | {
|
18 | while(1) UART2PrintString( " *** Hallo Welt *** \r\n" ); |
19 | }
|
Was natürlich noch nötig ist, das ist das setzen der Config Fuses. Das geschieht in diesem Fall im entsprechenden Menü von MPLAB. Will man das im Code erledigen kommen die Zeilen halt noch dazu... (Wenn man weitestgehende Plattformunabhängigkeit sucht, -was bei Bascom oder Micromite ja absolut nicht möglich ist- wird es minimal aufwendiger, dann würde man die µC Spezifischen Funktionen in eigenen Funktionen verstecken und dann im Programm nur die eigenen Funktionen aufrufen. Dann müssten jeweils bei einer Portierung nur einmalig die eigenen Funktionen angepasst werden. Aber das ist hier wie gesagt irrelevant weil die Basic Varianten diese Möglichkeit ja überhaupt nicht bieten.) Wie sähe denn ein KOMPLETTES Bascom Programm mit dieser Funktionalität überhaupt aus? Aber darauf wollte ich eigentlich nicht hinaus, denn generell finde ich "Micromite" gar nicht so schlecht wie manche es darstellen. Gerade für das Beispiel mit dem "Zehnjährigen Ersteinsteiger" finde ich solche "ready to use" Interpreter sehr gut. Vielleicht noch ein wenig besser als Basic Compiler. Oder halt für den Hobbyisten der nur mal kurz für ein einziges Projekt eine µC Funktionalität braucht und bereits jetzt schon weiß das er das nächste mal in vielen Monaten - wenn nicht sogar JAhren- wieder an diesem Punkt sein wird. Wenn überhaupt. Dies sind alles Fälle wo "Micromite" oder meinetwegen auch "Bascom" durchaus das Mittel der Wahl sein können. Völlig anders sehe ich das aber wenn jemand sich dauerhaft mit µC beschäftigen will und auch schon in Mathe etwas weiter als bei den Grundrechenarten ist... Ich sage mal so ab 13 - 16 (je nach individueller Begabung) aufwärts... Und erst recht wenn jemand schon weiß das er mal beruflich in diese Richtung gehen will! Da sollten dann die Basic Varianten sofort aussen vor bleiben! Aber generell ist das ein "Äpfel mit Birnen" Vergleich, denn weder Bascom und erst recht nicht Micromite sind mit einer Programmentwicklung in C vergleichbar. Denn die "Einfachheit" der Funktionen ist nur deshalb gegeben weil die Ersteller der Sprache dem Programmierer eine Menge an Parametrierung abgenommen haben. Dadurch ist der Programmierer aber auch an die Vorgaben weitgehend gebunden, eine auch nur annähernd so große Vielfältigkeit wie in C ist einfach nicht möglich. Solange es aber nur fürs Hobby ist und keine Ambitionen zu "mehr" dahinterstecken reicht das aber dann oft doch aus. Wer allerdings ernsthaft der Meinung ist das man mit Bascom oder Micromite auch professionelle Entwicklungen realisieren kann, der hat einfach den Schuss nicht gehört! Wer soetwas in einem Angestelltenverhältniss oder bei Auftragsentwicklungen ernsthaft in erwägung zieht, der gehört definitiv schnellstens "entsorgt". Denn in aolchen Fällen spielt viel mehr mit als nur die Frage ob die Funktion irgendwie erreicht werden kann. Deshalb: Äpfel & Birnen -> Jeder Vergleich erübrigt sich! Gruß Carsten
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
> 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
'Akademiker-Variante' ;) welche sich LISP/SCHEME bedient. http://www.ccs.neu.edu/home/stamourv/papers/picobit.pdf http://www.iro.umontreal.ca/~feeley/ http://www-etud.iro.umontreal.ca/~stamourv/honor-en.html -> http://gambitscheme.org So verkehrt ist das doch nicht, wenn sich ein embedded-System in gleicher weise programmieren/skripten laesst wie eine Anwendung auf einem Hostrechner? Guile als Variante findet sich zb. auf jedem GNU/Linux. Ob das sinnvoll oder noetig ist, wer weis.
Hier mal ein Beispiel für deine UART Schnitstelle.
Ist das selbe wie in C nur zwei Zeile.
UART1_Init(9600)
UART1_Write_Text("Ready")
Micromite schrieb: > Geoff hat den schnellen Basic Interpreter in einem PIC 32 nach der > Betaphase nun öffentlich gemacht. Super, herzlichen Dank für den link. und Lass dir von den Miesepetern und den AVR Heinzis nicht den Tag versauen. Wenn Betriebsblindheit blaue Flecken machen würde dann liefen die alle als Schlümpfe rum ;-). NoOne schrieb: > Aus meiner Sicht, tut sich niemand einen Gefallen, auch nicht im > Hobbybereich, mit irgend einem Basic anzufangen. Also ich bin mit HP Basic (heute HT Basic) angefangen. die beste Sprache und die besten Maschinen die beste Doku und die beste Performance in Sachen Stabilität, aber auch die höchsten Kosten. Damit konnte man erstklassig arbeiten. Der Umstieg auf C war bei mir dann aber auch schwierig und es hat lange gedauert. Hirnlosen Spaghetti- und "write only" Code kann man in jeder Sprache erzeugen, das ist nicht Basic spezifisch. Am besten ist da wohl MUMPS
1 | GREPTHIS() |
2 | N S,N,T,I,K,Q S I="K",S="11",K="l1",Q="R",T="K" |
3 | I I=T D T |
4 | Q:$Q Q Q |
5 | T I I,S&K S S=S+K Q |
http://en.wikipedia.org/wiki/MUMPS
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.
Man sieht du hast keine Ahnung von Basic Compilern. Ist übriegens MICROBASIC.
X4U schrieb: > Stefan schrieb: >> UART1_Init(9600) >> UART1_Write_Text("Ready") > > Wo immer man das eintippt, ohne Kenntnis von Devicename, > Oszillatorfrequenz und -typ sowie evtl. welcher Uart gemeint sein könnte > wird das wohl keine Compiler in der embedded Welt umsetzen können. Stefan schrieb: > Man sieht du hast keine Ahnung > von Basic Compilern. > Ist übriegens MICROBASIC. Naja, so GANZ Unrecht hat er nicht... Es handelt sich zumindest nicht um ein Lauffähiges MicroBasic Programm. auch wenn da jetzt nicht wirklich viel fehlt. Ich habe gerade mal MicroBasic Pro V6.0 (eval) für Pic Installiert und in Verbindung mit dem gerade hier liegenden Eval.Board mit PIC18F14K50 etwas gespielt. Da ist ja eine Ser.Schnitstelle passenderweise drauf. Also die Minimalanforderung für ein Kompilierbares Programm wäre ja dies: program MyProject main: UART1_Init(9600) UART1_Write_Text("Ready") end. Wobei dieses Programm nicht ganz dem von mir geschriebenen oben entsspicht und dabei sogar eine wirklich EISERNE REGEL der EmbeddedWelt verletzt. Ein EmbeddedProgramm darf nie nie niemals nicht durch etwas anderes enden als durch abschalten der Stromversorgung! Unterbrechungen durch Sleep, Standby & co. sind natürlich zulässig! Aber ein Laufen "ins Leere" ist normalerweise ein schwerer Kunstfehler. Wenn gleich in diesem Fall natürlich harmlos ;-) Der Grund ist darin zu suchen das einfach nicht definiert ist was der µC macht wenn der PC am ende des Physikalisch vorhandenen Speichers ankommt. Im Idealfall natürlich "NICHTS" aber es könnte auch völlig anders aussehen. Nun sind wir hier aber ja in keiner Klausur und die Anwendung ist auch nicht kritisch, es sei dir daher verziehen! Allerdings sollte daher für eine definitv saubere Funktion mindestens noch eine Endlosschleife am Ende stehen. (In C setzt man- falls das Programm nicht sowieso einer nicht verlassbaren Endlosschleife läuft, was eher der Standardfall ist - dann einfach ein " while(1);" ans Ende der main Funktion.) Die Entsprechung hier wäre dann wohl das Einfügen der beiden folgenden Zeilen direkt vor dem "end.": WhileSchleife: goto WhileSchleife Wobei man dann direkt auch die Befehle an die richtige Stelle setzen kann um ein bis auf dem Text zu meinem Beispiel funktionsidentisches Programm zu bekommen: program MyProject main: UART1_Init(9600) WhileSchleife: UART1_Write_Text("Ready") goto WhileSchleife end. Aber das ist im Grunde jetzt Erbsenzählerrei! Ich denke es ist somit klar das weder MicroBasic (für Pic) unter Verwendung der MicroE Libs noch C unter Verwendung des Microchip Compilers & der Microchip Libs hier nennenswerte Mehrarbeit erfordern! Das bleibt sich relativ gleich! Die ConfigFuses wurden ja in beiden Fällen in der IDE gesetzt, Bei MPLAB geht das alternativ auch im Code, bei Mikrobasic weiß ich das nicht (vermute aber mal auch, oder?) Sonst sind in C die Includes noch dabei die man manuell machen muss, in MikroBasic sind auch Includes nötig die macht die Software aber selbst. Da ist noch ein Minimalunterschied... Die GEschwindigkeit mit welcher der µC TATSÄCHLICH LÄUFT muss bei MikroE manuell in die IDE eingetragen werden, bei C habe ich die ja im Code angegeben. Ist also auch relativ egal, wobei die richtige Angabe in BEIDEN FÄLLEN genaues Lesen und verstehen des Datenblattes vorraussetzt. Ich hatte die Speedangabe bei MikroBasic ja erst als "Sollfrequenz" des Oszillators missverstanden und dann Testweise 16 Mhz eingetragen weil dies ja die Nominalfrequenz des Internen Oszillators ist. Erst als die Ausgabe dann um den Faktor 2^4 zu langsam war und ich gesehen habe das im ASM Code keine Änderung des OSCCON Registers erfolgt war mir (sofort) klar das hier die "Tatsächliche" Frequenz des Bausteins NACH Teilerkette eingetragen werden muss wie sie sich dann durch die Einstellungen (hier Initwerte nach Reset) bei Erreichen der Ausgabebefehle darstellt. NAtürlich hätte hier ein Lesen des Manuals auch vorher für Klarheit gesorgt ;-). Zudem ist es technisch auch Sinnvoll und sicher kein Fehler dies so zu machen. Aber es erfordert genau so viel Nachdenken wie bei C, ist also auch nicht einfacher in diesem Fall. Eine andere Sache ist mir aber beim Test noch aufgefallen. Ich wollte Spasseshalber gerade mal den Realtest machen und eine WINZIGANWENDUNG (zwanzig C Zeilen gesamt) die ich heute für ein Gerätchen geschrieben habe in Basic schreiben. Aber ich musste feststellen das MicroBasic diesen Baustein, den es ja mittlerweile schon einige Monate gibt, gar nicht zu kennen scheint! Also genau einer von den weiter oben von mir genannten DEUTLICHEN Nachteilen... (Es handelt sich um einen PIC12F1572) Ansonsten muss ich aber sagen das mir die IDE gar nicht schlecht gefällt. Vielleicht sogar besser als das neue MPLABX mit dem ich bisher noch etwas auf Kriegsfuss stehe. (Ich weiß viele sehen das anders, aber mir lag das alte MPLAB 8.xx mehr als das neue MPLABX!) Also wie gesagt, für Hobby spricht da ja nichts gegen! Wer µC nur als Hobby betreibt soll nehmen womit er zurecht kommt und wo er am meisten Spass hat. (Aber das habe ich ja schon vorher genau so gemeint!) Für die berufliche Anwendung bleibe ich aber nach wie vor ebenso bei meiner festen Meinung! Und damit auch bei meiner Empfehlung für alle die zwar NOCH Hobbyisten sind, aber ernsthaft vor haben mal beruflich in die Richtung zu gehen. Gruß Carsten
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Hat inhaltlich nichts mit der Thematik zu tun. Mir ist aber aufgefallen, dass alle (ich hoffe, ich habe keinen übersehen), die für Basic/Float plaedieren, dies aus der Anonymitaet heraus als Gast tun, waehrend diejenigen, die hinter Basic ein Fragezeichen setzen, ihre Ansichten mit vollem Namen unterschreiben.
:
Bearbeitet durch User
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.
Den Sourcecode stellt Geoff auf Anfrage zur Verfügung. Der ist sehr gut dokumentiert und aufgeräumt. Feel free for a port ;-)
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.
Geoff anschreiben fertig. Der sieht das sehr. Locker, hat keine kommerziellen Absichten und möchte nur wieder so eine Olimex Nummer vermeiden...
Habe Geoff ne PM gesendet. Er begrüßt deine Portierungsidee und freut sich auf einen Kontakt.
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
1 | > The SD/MMC/SDHC memory card slot has support for FAT16 and FAT32 file |
2 | > systems up to 64GB. Using this you can save and load programs and under |
3 | > program control you can read and write data to the memory card with up to |
4 | > 10 files simultaneously open. The file system and data is compatible with |
5 | > Windows, Apple and Linux so the card can be read by any of these computers. |
:
Bearbeitet durch User
In den nächsten Tagen wird es eine 4.5C geben, welche einige Bugs beseitigt. RND, Reset Problem etc...
A new version of MMBasic for the Micromite is available for download from http://geoffg.net/micromite.html#Downloads
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...
Rsepekt und Gratulation wenn Du das zum Laufen gebracht hast. Ist das MMBASIC auf dem STM32F407 schon voll funktionsfähig?
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
@m.n. Also da läuft jetzt bei dem STM kein DOS "command.com" mehr unten drunter; richtig?
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 ;)
@ Joachim Drechsel (Firma: JDCC) (scheppertreiber) Was für eine Schande: So ein toller Kerl wie Du muss sich auch noch selbst beweihräuchern.
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.
Stefan schrieb: > Die heutigen Basic Compiler sind dem C fast gleich. Ha ha ha ha ha .... Muhahaha ha ha
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.
:
Bearbeitet durch User
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
Angehängte Dateien:
-
MMBas_test.jpg
77 KB
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 :-)
@m.n Wie steuerst Du das Display an, sind das die Routinen für das PIC VGA Interface von Geoff? Was ist das für ein Display?
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 .
und wer will kann seine c oder asm routinen einbinden...... Aha, wie geht das denn ?
Nein, das schrieb Jürgen/ pre8. Und ich fragte wie er das denn nun macht?!
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 ?
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.
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.
Schade das Eure Erweiterungen nicht der Allgemeinheit zugänglich sind...
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.
Hallo , Ist hier etwas neue an diese Projekt ? Wird auch gut der stm32 Source von mmbasic zu haben das mir das testen konnte :) Gruß.
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?
Angehängte Dateien:
-
maxi_f407.png
35 KB
Anbei der noch nicht abgeschlossene Schaltungsentwurf. TFT+SD Stecker sind auf einem anderen Blatt (hier nicht gezeigt).
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.
Hi , In anbetracht des erwarteten F7 werde ich mich mal an eine mK2 Portierung setzen.
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ß.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.