Zum Coden für meine laufenden Projekte habe ich zwar während der Sommerzeit keine Lust, aber neuen Ideen für ein weiteres Projekt schon: SerialComMeasurement soll eine universelle, programmierbare und frei erweiterbare Mess- und Steuer-Box oder Karte mit eigenem Betriebssystem werden. Das heisst, man schickt der Mess-Box/Karte eine Befehlssequenz, diese wird OnBoard abgearbeitet und die Ergebnisse einmalig oder zyklisch über die Schnittstelle zum PC geschickt. Features: OnBoard Realtime Multitasking Betriebssystem Programmierbare Samplerate Programmierbare analog/digital Kanäle Analog/Digital Triggers/EventDetection Mathem. Verknüpfungen, Transformationen, Statistics usw. Process Control, PID, analog/digital Outputs Einfache Befehls Syntax Kommunikation mit dem PC über virtuelle serielle Schnittstelle Mit den einige tausend Euro teuren professionellen Lösungen soll die Box/Karte nicht konkurieren. Es müsste aber möglich sein, zum Beispiel mit einem ATMega 644 oder 1284 sowas zu realisieren, wenn man keine überzogenen Forderungen an Sampleraten usw stellt, es soll also kein HighSpeed-Teil werden. ATMega deshalb, weil ich keine Lust habe mich in andere Controller Architekturen einzuarbeiten, auch wenn diese dafür wahrscheinlich besser geeignet wären. Mit einem ATMega ist das Ganze aber sicherlich bastlerfreundlicher. Die Programmierung soll mit LunaAVR erfolgen. Wie gesagt alles nur mal eine Idee, ob ich das realisiere wird sich zeigen.
:
Verschoben durch User
Klingt sportlich aber interessant. Halte uns bitte auf dem Laufenden.
"Projekte & Code" ist nicht dafür gedacht, seine Pläne oder Ideen vorzustellen, sondern um (weitestgehend) fertige Projekte mitsamt des zugehörigen Codes und gegebenenfalls Schaltungen vorzustellen.
.....ganz schön "wenig Lust" für so ein umfangreiches Projekt... Was erwartest Du jetzt?
Albert M. schrieb: > Mathem. Verknüpfungen, Transformationen, Statistics usw. So ein Blödsinn, das kann der PC viel besser und schneller. > OnBoard Realtime Multitasking Betriebssystem [...] > Die Programmierung soll mit LunaAVR > erfolgen. Damit gibst du den einzigen Vorteil auf, denn ein µC ohne OS und dumpfbackige Programmiersprache bieten kann: seine ultimative harte Echzeitfähigkeit. Alles andere kann man mit einem PC viel billiger und viel schneller... D.h.: Die Umsetzung in einem µC macht genau nur dann irgendeinen Sinn, wenn eben gerade KEIN PC zur Verfügung steht. Also subtrahiere "PC" von deinem Projekt und betrachte, was über bleibt... Tipp: Das wird nicht viel sein...
c-hater schrieb: >> Mathem. Verknüpfungen, Transformationen, Statistics usw. > > So ein Blödsinn, das kann der PC viel besser und schneller. c-hater schrieb: > Alles andere kann man mit einem PC viel billiger und > viel schneller... > > D.h.: Die Umsetzung in einem µC macht genau nur dann irgendeinen Sinn, > wenn eben gerade KEIN PC zur Verfügung steht. > > Also subtrahiere "PC" von deinem Projekt und betrachte, was über > bleibt... Du hast das Konzept nicht mal annähernd verstanden. Und was es dazu auf dem Markt gibt ist Dir wohl auch entgangen. Es gibt Unternehmen die leben seit über 30 Jahren genau von sowas, z.B.: http://www.mstarlabs.com/dataacquisition/dap.html http://www.mstarlabs.com/docs/manuals/DAPL2000.PDF http://www.adwin.de/ Damit ist Deine voreilige Aussage widerlegt. c-hater schrieb: > ... und dumpfbackige Programmiersprache Hast Du Dich mit LunaAVR schon mal intensiv beschäftigt um Dir ein Urteil erlauben zu können?
Albert M. schrieb: > OnBoard Realtime Multitasking Betriebssystem > ATMega 644 oder 1284 Da Realtime einer ganz willkürlichen Definition folgt ist das natürlich möglich. Farbe trocknet ja auch in 'Realtime' ...
1. ich glaub, das LunaAVR hier die Leute eher abschreckt. Du wirst fast alleine Programmieren müssen. 2. zur Hardware nebst dem Atmega hast Du noch nichts ausgesagt. Externer ADC, galvanische Trennung usw... Ich glaub Du müsstest erst mal bisschen was zeigen, dann springen schon ein paar Leute mit auf den Zug auf. Je weiter das Projekt dann fortschreitet, desto mehr Leute tauchen dann auf und posten ihre Vorschläge und Wünsche. Daß Du es drauf hast, bezweifelt hier keiner. Deine anderen Projekte zeigen das ganz deutlich!!!
Gerhard W. schrieb: > 1. ich glaub, das LunaAVR hier die Leute eher abschreckt. Du wirst fast > alleine Programmieren müssen. Habe ich das nicht immer so gemacht? Viele Köche verderben den Brei :) Luna habe ich nur der Information halber erwähnt, solange das Resultat performant bleibt ist die Sprache gleichgültig, insbesondere da ich nie Quellcode veröffentlicht oder zur Diskussion gestellt habe. Hat ja eigentlich auch nie einen interessiert oder gestört, dass meine anderen Projekte in Pascal/Delphi geschrieben sind. Gerhard W. schrieb: > 2. zur Hardware nebst dem Atmega hast Du noch nichts ausgesagt. Externer > ADC, galvanische Trennung usw... Orientieren könnte man sich da an eine drastisch auf ATMega runterskalierte Version hiervon: http://www.mstarlabs.com/dataacquisition/840/840spec.html Und für die event. Möglichkeiten der Befehle, auch stark reduziert, hieran: http://www.mstarlabs.com/docs/manuals/DAPL2000.PDF Es soll etwas für wenige Euro nachbaubares, auf Hobbyniveau neues erstellt werden. Wenn es soweit ist können gerne Hard- und Software-Features diskutiert werden. Damit könnten dann autonom, teilautonom oder PC-gesteuert komplette Versuchsaufbauten oder sonstige Prozesse gesteuert und überwacht werden indem man einmalig die nötigen Steuerungssequenzen als Befehle über z.B. ein Terminalprogramm zum ATMega schickt. Die Befehle sollen dabei insbesondere mathem. Operationen, wie Datenreduktion, Statistik usw., sowie Triggeroptionen, auch auf den bereits auf vorangegangenen Operationen resultierenden Datenstrom, auf einfache Weise kapseln. Wenn das schöne Sommerwetter vorbei ist werde ich mal ein paar Machbarkeitstest durchführen und sehen ob das Ganze auf ATMega Basis realistisch für die von mir angedachten Zykluszeiten/Abtastraten von 50/s bis vielleicht 500/s ist. Vielleicht komme ich ja auch zu dem Ergebnis, dass man sich besser einen Controller mit aufgebranntem BASIC kauft, da gibt es ja so einige.
:
Bearbeitet durch User
Hallo Albert, ich bin auf deine Projektgestaltung mit LunaAVR gespannt. Mit der neuen Release V2015 R1.6 hat sich einiges getan.
interessantes Projekt, bin ebenfalls gespannt. DAPL ist nicht besonders eingängig, jedoch sehe ich da eine brauchbare Basis.
Ich habe mir mal über die grundlegende Befehlsstruktur Gedanken gemacht. Die nachstehend benutzten Channels sind Variable/Puffer. Die Befehle werden über die Schnittstelle zum MC geschickt und dort im Befehlspuffer vorätig gehalten. Der Befehlspuffer wird zyklisch im Takt des Abtastinterval abgearbeitet. Kommandos --------- AIx_Cn Analog Input x auf Channel n legen DIx_Cn Digital Input x auf Channel n legen IVnnnn Abtast-Interval nnnn in ms A0 Stop Acquisition A1 Start Acquisition TAx_>v Start Acq. sobald Analog Input x Wert grösser als v TAx_<v Start Acq. sobald Analog Input x Wert kleiner als v TDx_n Start Acq. sobald an Digital Input x der Wert n = 1 ist // M steht für math. Operationen // Ergebisse für math. Funkt. werden in Channel n zurückgegeben M+CnCm Addiere Channel n mit Channel m M-CnCm Subtrahiere Channel m von Channel n M*CnCm Multipliziere Channel n mit Channel m M/CnCm Dividiere Channel n durch Channel m M+Cn_N Addiere zu Channel n die Konstante N M-Cn_N Subtrahiere von Channel n die Konstante N M*Cn_N Multipliziere Channel n mit der Konstanten N M/Cn_N Dividiere Channel n durch die Konstante N MWCnCmMp Mittelwert Channel n über p Werte, Ergebnis nach Channel m MACnCm Maximum von Channel n nach Channel m MICnCm Minimum von Channel n nach Channel m SO_Cn Serial Out Channel n SO_TU Serial Out Uhrzeit (wenn ClockModul verfügbar) SO_TS Serial Out Zeit seit Start, vom Timer abgeleitet DOx_Cn_>V Digital Out x wenn Channel n grösser V DOx_Cn_<V Digital Out x wenn Channel n kleiner V DOx_Cn+Cm Digital Out x wenn Channel n UND Channel m AOx_Cn Analog Out x von Channel n (PWM) Eventuell könnte man das noch mit Befehlen zum Beschreiben einer Speicherkarte erweitern.
:
Bearbeitet durch User
So recht erschließt sich mir der Nutzen dieses Projekts auch nicht. Viel eher sehe ich die Gefahr, daß es beim vielversprechenden SerialComInstruments (Zitat Programmautor: "Da die Weiterentwicklung bald wieder anläuft") zukünftig, wie seit einer ganzen Weile schon, nicht mehr recht vorangeht ;-)
Dann einig dich doch mit Albert darauf, daß du seine Idee in Assembler statt Luna realisierst, dann ist allen geholfen.
Moby A. schrieb: > So recht erschließt sich mir der Nutzen dieses Projekts auch nicht. Der Nutzen des Projektes ist für mich, dass ich nicht mehr jedesmal, wenn ich etwas Einfaches mit einem Mikrocontroller messen/steuern will, ein neues Programm in Assembler, C, Bascom, Luna oder was auch immer schreiben muss. Was ist jetzt daran schwer zu verstehen? Beispiel: Messung von 2 Analog-Signalen (Spannung und Strom) alle 10 ms und verrechnen zur Leistung. Wenn die Leistung über 5W geht Relais schalten (Digital Out). Leistung incl. Uhrzeit über Serial Out dokumentieren. Skalierungen sind im Beispiel noch nicht berücksichtigt. AI1_C0 Lege AnalogInput1 auf Kanal 0 AI2_C1 Lege AnalogInput2 auf Kanal 1 IV10 Abtastinterval 10 ms M*C0C1 Multipliziere Kanal 0 mit Kanal 1, Ergebnis in Kanal 0 DO1_C0_>5.0 Setze DigitalOutput 1 wenn Kanal 0 grösser 5 SO_TU Uhrzeit auf SerialOut SO_C0 Kanal 0 auf SerialOut A1 Starte Messung So ist das komplette Programm in weniger als 1 Minute geschrieben, ohne sich mit den Innereien des Controllers beschäftigen zu müssen. Wer darin keinen Nutzen erkennt, muss es ja nicht nutzen :)
:
Bearbeitet durch User
Also ich würde auf Ethernet statt Seriell umstellen oder zumindest parallel dazu anbieten. Wollte man konsequent sein, müsste man sogar WLAN als Client und Server und Bluetooth anbieten, aber wir wollen ja nicht gleich übertreiben. Welche Laptop hat heute noch eine COM-Schittstelle? OK, dann gibts noch USB im CDC-Mode ... wie lang darf ein USB-Kabel sein? Ethternet mit einem kleinen Webserver dahinter, gestattet wenigstens den Zugriff per Browser (plattformunabhängig!) und aus beliebiger Entfernung ... das fände ich zeitgemäß. LunaAVR finde ich übrigens eine gute Idee, endlich eine "erwachsene" Programmiersprache und dazu kostenlos. Leider wurde ja die Mac-Version "eingestampft", weil der Chefentwickler keinen echten Mac für Tests zu Verfügung hat und der, der sich angeboten hatte ("macsven") da wieder ausgetiegen ist ...
Frank E. schrieb: > endlich eine "erwachsene" > Programmiersprache und dazu kostenlos. Leider wurde ja die Mac-Version > "eingestampft", weil der Chefentwickler keinen echten Mac für Tests zu > Verfügung hat Total erwachsen, in der Tat. Und wenn morgen der Chefentwickler auch keine Lust mehr hat, ist Sense.
Frank E. schrieb: > Also ich würde auf Ethernet statt Seriell umstellen oder zumindest > parallel dazu anbieten. Wollte man konsequent sein, müsste man sogar > WLAN als Client und Server und Bluetooth anbieten Meine Intension beschränkt sich nur auf die Software/Betriebssystem für den ATMega. Was hardwaremässig dranggehängt wird kann jeder selbst entscheiden. Es gibt ja genügend Converter Seriell auf was auch immer. Für event. notwendige Steuerbefehle (z.B. AT Commands) liesse sich SerialComMeasurement leicht erweitern, z.B.: SSs Sende String s. @Nase Das Luna Bashing kannst Du Dir sparen, man weiss ja aus welcher Ecke das kommt. Den Quellcode für die Implementation mit Luna werde ich hier nicht zur Diskussion stellen/veröffentlichen. Der Anwender von SerialComMeasurement kommt mit Luna nicht in Berührung, also ist eine Diskussion darüber müssig.
:
Bearbeitet durch User
Mach mal, man kann dann ja immer noch sehen was daraus wird. Vielleicht kommen so ja andere Ideen daraus. Dass immer alle so viele Argumente gegen etwas haben und nur so wenig sich Gedanken über ein "für" machen, das habe ich noch nie verstanden. Allerdings, lieber Albert, solltest du dann auch den Code offen halten, für alle. Ich kann da noch gar nicht mit mischen und muss erstmal selber wieder fast bei Null anfangen, mit dem Programmieren, aber diese Grundidee finde ich schon mal überlegenswert.
Albert M. schrieb: > @Nase > Das Luna Bashing kannst Du Dir sparen, man weiss ja aus welcher Ecke das > kommt. Ja, aus einer Ecke die Erfahrung hat. Und schon einige Irrlichter hat sterben sehen... > Den Quellcode für die Implementation mit Luna werde ich hier > nicht zur Diskussion stellen/veröffentlichen. Der Anwender von > SerialComMeasurement kommt mit Luna nicht in Berührung, also ist eine > Diskussion darüber müssig. Naja, das beudetet im Unkehrschluss aber auch, dass auch niemand außer dir an SerialComMeasurement mitwirken wird. Ich würd ja ganz ehrlich für sowas eher auf eine Arduino-Plattform setzen. Nicht will ich Arduino und den Hype darum so toll finde, sondern weil fast alles, was du vorhast, dort schonmal jemand durchdacht hat. Ein paar Shields, alles sauber verpacken und fertig ist die Laube. Das hätte dann wenigstens eine Nutzerbasis. So aber wird das dein Privatprojekt. Vermutlich. Erfahrungsgemäß orakel ich mal, dass es leider garnichts wird...
Nase schrieb: > So aber wird das dein Privatprojekt. Vermutlich. Erfahrungsgemäß orakel > ich mal, dass es leider garnichts wird... Ja genau, wird nichts. Wie meine anderen Projekte: http://www.serialcominstruments.com/ Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle" Beitrag "Projekt: SerialComCNC Serielles Frontend für CNC GRBL mit ATMega"
:
Bearbeitet durch User
Albert M vorzuwerfen, seine Projekte werden nichts, zeugt von Uninformiertheit. Allerdings wollte ich an seiner Stelle nicht jedes Spezialproblem selber lösen wollen. Darin sehe ich die Vorteile von OpenSource. Und man würde dann auch mit Leuten kommunizieren, die nicht nur Endverbraucher sind. Nachteilig nur der fehlende Heldenstatus.
Mach einfach mal. Bei deinen anderen Projekten war es am Anfang auch nicht anders.
Bastler schrieb: > Albert M vorzuwerfen, seine Projekte werden nichts, zeugt von > Uninformiertheit. Nicht unbedingt uninformiertheit. Aber ich bin durchaus gewillt, an gewissen Stellen zu provizieren.
Ich habe gerade mal ein Minimalsystem mit einem ATMega 328 (Arduino Nano) getestet. Sieht ganz gut aus was Speicherbedarf und Performance angeht. Grössere ATMegas (644 oder 1284) scheinen nicht unbedingt erforderlich zu sein.
Hier mal ein Einblick in die ersten Vorversuche von heute Abend. Hardware ATMega 328P 16MHz (Arduino Nano) Schnittstelle 115200 Baud, 8 Data Bits, 1 Stop Bit. Der Flash Speicher ist momentan zu 15% belegt und das SRAM mit 21%, da bleibt noch Luft für viele Erweiterungen. Das Hex-File gibt es oben zum ausprobieren. Folgende Befehle sind implementiert und können getestet werden: #CL ClearComandBuffer and Reset BufferCounter (immer zuerst) #Stop Stop Acquisition #Start Start Acquisition #SB SerialOutCmdBuffer (Dump Command Buffer to Serial) #AIx_Cnn Analog Input x auf Channel nn legen (x=0..9 , nn=0..40) #SO_Cnn Serial Out Channel nn Momentan sind für den Befehlspuffer max. 40 Befehlszeilen vorgesehen. Es stehen zusätzlich 40 frei belegbare Channels für Daten zur Verfügung. Diese können später mit math. Funktionen untereinander verknüpft werden. Die jeweils 40 sind fürs erste mal willkürlich festgelegt. Die Analog-Eingänge können beliebig auf die Channels gemappt werden. Ein programmierbares Messinterval und digitale Kanäle kommen als nächstes. Die Befehle müssen als String und mit CR (#13) als Abschluss z.B. über ein Terminal-Programm an den Controller geschickt werden. Das Interne Datenformat ist z.Z. Int32/LongInteger um bei späteren Berechnungen nicht gleich einen Overflow zu bekommen. Eventuell wird das Format noch auf Single/Floatingpoint umgestellt. Da eh kein High Speed System angestrebt ist, dürfte es kein Zeitproblem wegen des Formates geben. Aber das wird sich später noch zeigen. Das Beispiel im Bild oben, Messung von 2 Analog Signalen und Ausgabe über die ser. Schnittstelle, wurde mit folgenden Befehlen erstellt: #CL Clear und Reset des Befehlspuffer #AI3_C12 Analog Input 3 auf Channel 12 mappen #AI4_C13 Analog Input 4 auf Channel 13 mappen #SO_C12 SerialOut Channel 12 #SO_C13 SerialOut Channel 13 Dann Start Messung mit: #Start Darunter sieht man die gemessenen Werte (offene Eingänge). Wichtig: Vor alle Befehle muss immer das # mit eingegeben werden.
:
Bearbeitet durch User
Nase schrieb: > Und wenn morgen der Chefentwickler auch keine Lust mehr hat, ist Sense. jaja wenn die xyz-Entwickler keine Lust mehr haben, wenn Merkel keine Lust mehr hat, wenn dein Chef keine Lust mehr hat und wenn der Betreiber von mikrocontroller.net keine Lust mehr hat und wenn deine Frau morgen keine Lust mehr auf dich hat,... tja, dann ist auch sense. Das Leben ist hart und ungerecht. so eine Grütze!!
Es gibt diverse OpenSource-Projekte wo so was schon passiert ist. Und wenn's andere interessiert hat, dann haben die eben weiter gemacht.
Hier eine neue Testversion. Die erste Version erreichte durch einen Bug nur ca. 70 Samples/s, die neue Version sieht da mit über 800 Samples/s schon besser aus. Schnittstelle mit 250000 Baud Getestet mit: Analog Eingang 2 auf Channel 11, Channel 11 seriell ausgeben #CL #AI2_C11 #SO_C11 #Start
:
Bearbeitet durch User
Hallo Albert, ich würde gerne die Syntax noch etwas leserlicher machen und mehr in Richtung einer Zuweisung gehen. #AI2_C11 ==> #C11:=AI2 Map alle Daten von Analog 2 auf Channel 11 #SO_C11 ==> #C11=>SO oder #C11>>SO Sende alle gesammelten Daten von Channel 11 an Serialport 0 Was denkst Du ?
:
Bearbeitet durch User
Hallo Uwe, die Abarbeitung des Befehlspuffer (String-Array) geschieht mittels State-Machine die über die ersten 2 Zeichen die Art der Verarbeitung vorsortiert/bestimmt, z.B.: AI alles was mit Analogeingängen zu tun hat DI alles was mit Digitaleingängen zu tun hat SO alles was an seriell Out geht DO alles was an digital Out geht Mm alles was mit Mathematik zu tun hat m ist dabei die Art der Verarbeitung M+ Addition usw MM Mittelwertbildung Mx Maximum Das macht das Parsen einfacher. Als Argument dieser Operations-Kennzeichnung folgt dann jeweils der Kanal. Mit welchen Zeichen diese Zuweisung erfolgt kann man gerne diskutieren. Ob nun mit AI3_C10 oder AI3>C10 oder AI3>>C10 ist Geschmackssache. Logischerweise müsste es dann für die Ausgänge so sein: DO<C15 oder DO<<C17 SO<C11 oder DO<<C11 Ich finde allerdings den von mir beutzen Unterstrich leserlicher wegen der Quasi-Leerstelle zwischen den Zeichen. Dein Vorschlag macht jedoch die Zuordnung ersichtlicher. Zur Zeit iteriert die State-Machine noch einfach durch das Befehls-Array. Ob dies für alle Aufgaben optimal ist muss noch getestet werden.
:
Bearbeitet durch User
Albert M. schrieb: > Zur Zeit iteriert die State-Machine noch einfach durch das > Befehls-Array. Ob dies für alle Aufgaben optimal ist muss noch getestet > werden. das lässt sich mittels baumstruktur sicher beschleunigen: erstes Zeichen -> Startbefehl -> Kommando -> Ziel
Ich habe mir mit dem Logic Analyzer mal angeschaut wo Optimierungsbedarf besteht. Die Hauptschleife im MC sieht prinzipiell so aus. Do Check auf RX .... Do something | Check auf RX TimeOut ... Info | Zusammen 1,5 us If Status Start Incr Befehlszähler | | Check ob AI .... Do something | 412 us Check ob SO .... Do something | 700 us usw | usw | EndIf Status Start | Loop Ergibt 1113,5 us also die von mir vorher mit der Stoppuhr gemessenen ca. 800 Samples/s. Zur Zeit findet das Parsen des Befehlspuffers noch mit Befehlen zur Stringmanipulation statt. Offensichtlich erzeugt das den hohen Zeitbedarf von 420us/700us. Das ist insbesondere ungünstig, weil sich diese Zeit ja mit der Anzahl der Befehle im Befehlspuffer multipliziert. Für langsamere Messungen wie Temperatur usw wäre das ja tragbar, aber eigentlich muss das Ganze für mich wesentlicher schneller werden. Lösung wäre von den zeitraubenden Befehlen zur Stringmanipulation weg zu kommen, oder einen Parserlauf vor dem eigentlichen Programmstart, bei dem die Befehlsstrings einfach zu Befehlsnummern konvertiert werden, z.B. #AI3 wird zu 13, #AI4 zu 14, #DO2 zu 22 usw. Vieleicht sind da auch verkettete Listen oder wie von wire vorgeschlagen Baumstrukturen sinnvoll. Auf der anderen Seite soll das Projekt auch keine Dissertationsarbeit werden, sondern so einfach und schnell wie möglich zu realisieren sein. Wie auch immer, ich werde mir dazu mal weiter Gedanken machen. Übrigens habe ich auch an Befehle für die direkte Kombination mit SerialComInstruments gedacht. Schneller als mit dieser Kombi könnte man dann eigentlich keine Messaufgaben programmieren und visualisieren.
:
Bearbeitet durch User
Nachtrag: Nach interem Ersatz der meisten Stringfunktionen sieht es im Vergleich zu oben nun so aus Check ob AI .... Do something | 100 us (vorher 412 us) Check ob SO .... Do something | 600 us (vorher 700 us) Damit ist Samplerate nun incl. sonstigem Overhead ca. 1200/s (ca. 0,8 ms Zykluszeit). Wie ersichtlich ist die Analog Verarbeitung um den Faktor 4 schneller, an der Zeit für die serielle Ausgabe lässt sich aber nicht grundsätzlich viel ändern. Eine Geschwindigkeitsverdopplung ist für die ser. Ausgabe eh nicht möglich wie man am Bild des Logic Analyzers sieht, die Schnittstelle steht ja bereits auf 250000 Baud. Im Übrigen habe ich die Marker für dem LA auf PortD.7 vorläufig im hex-File gelassen. Für die nächsten Versionen werden nun weitere Funktionen implementiert.
:
Bearbeitet durch User
Sorry, im hex-File steckten noch Bugs. Hier die Korrektur
:
Bearbeitet durch User
Jetzt gibt es die erstem arithmetischen Befehle. Zur Zeit verfügbare Kommandos: #CL ClearComandBuffer and Reset BufferCounter (immer zuerst) #Stop Stop Acquisition #Start Start Acquisition #SB SerialOutCmdBuffer (Dump Command Buffer to Serial) #AIx_Cnn Analog Input x auf Channel nn legen (x=0..9 , nn=10..40) #SO_Cnn Serial Out Channel nn #M+Cnn_Cmm_Coo Addition von Cmm und Coo nach Channel nn #M-Cnn_Cmm_Coo Subtraktion von Cmm und Coo nach Channel nn #M*Cnn_Cmm_Coo Multiplikation von Cmm und Coo nach Channel nn #M/Cnn_Cmm_Coo Division von Cmm und Coo nach Channel nn Alle Werte sind int32. Operationen. Floatingpoint kommt demnächst. ATMega 328 P, Schnittstelle 250000 Baud. Beispiel: #CL Clear und Reset des Befehlspuffer #AI2_C10 Analog Input 2 auf Channel 10 mappen #AI3_C11 Analog Input 3 auf Channel 11 mappen #M*C12_C10_C11 Multiplikation Chan.10 und Chan.C11 nach Chan.C12 #SO_C10 SerialOut Channel 10 #SO_C11 SerialOut Channel 11 #SO_C12 SerialOut Channel 12 TutnichtszurSache schrieb: > Gabs alles schon mal Das Elektor Teil kann z.B. mit Sicherheit nicht SerialComInstrument passend ansteuern. Das Geld für den Download des Elektor-Artikels werde ich mir allerdings sparen.
:
Bearbeitet durch User
Albert M. schrieb: > Damit ist Samplerate nun incl. sonstigem Overhead ca. 1200/s Das reißt einen ja nicht vom Hocker. Ich würde die Strings zu Anfang einmal parsen und als eine Liste von Calls im RAM ablegen (Funktionspointer). Albert M. schrieb: > die Schnittstelle steht ja bereits auf 250000 Baud. Welcher PC kann denn diese krumme Zahl? Standardwerte sind 230,4, 460,8 und 921,6kBaud (Hyperterminal).
Hallo Albert, ich habe einen Vorschlag die mathematische Fähigkeiten zu erweitern. Wurzelfunktion
> Wurzelfunktion auf dem armen kleinen AVR? Das kann der PC hinter der Seriellen Schnittstelle viel besser!
Peter D. schrieb: > Ich würde die Strings zu Anfang einmal parsen und als eine Liste von > Calls im RAM ablegen (Funktionspointer). Das kann LunaAVR aber nicht. Abgesehen halt vom händisch-Ablegen der Einsprungadressen und dann icall. Argumente muss man wohl vorher auch von Hand auf den Stack legen
es mag sein, aber dann sollten sämtliche mathematische und logische Funktionen in SerialComInstrument eingebettet sein.
Guten Morgen, schade dass es hier so viele Nasen gibt, die sich anonym beteiligen würden, wenn denn nur etwas mut bestünde, dies auch aktiv mit guten Beiträgen zu tun. Zum Zitat Nase schrieb: > Peter D. schrieb: >> Ich würde die Strings zu Anfang einmal parsen und als eine Liste von >> Calls im RAM ablegen (Funktionspointer). > > Das kann LunaAVR aber nicht. Abgesehen halt vom händisch-Ablegen der > Einsprungadressen und dann icall. Argumente muss man wohl vorher auch > von Hand auf den Stack legen LunaAVR hat/ bietet alle Möglichkeiten Von C ein Array von Zeichen (char) zu verarbeiten. Darüber hinaus können auch Funktionspointer mit Parametern definiert werden und über ICALL auch aufgerufen werden. http://avr.myluna.de/doku.php?id=de:icall Man soll es kaum glauben, der Code funktioniert !
Albert M. schrieb: > Das Elektor Teil kann z.B. mit Sicherheit nicht SerialComInstrument > passend ansteuern. Das Geld für den Download des Elektor-Artikels werde > ich mir allerdings sparen. Man kann die PC-Software und die Arduino-Software gratis herunterladen. Die Oberfläche sieht ganz vernünftig aus, man kann auch Skripte laufen lassen. Soll nur als Anregung dienen.
Peter D. schrieb: > Albert M. schrieb: >> die Schnittstelle steht ja bereits auf 250000 Baud. > > Welcher PC kann denn diese krumme Zahl? Jeder PC, auch Deiner. Im PC ist Da NICHTS einzustellen. Stell einfach Dein Terminal auf 250000, dann passt das schon.
Bastler schrieb: > Stell einfach > Dein Terminal auf 250000, dann passt das schon. Und wie soll das gehen? Wie schon gesagt, Hyperterminal kann keine beliebigen Werte, sondern nur die in der Auswahl (.., 230,4, 460,8 und 921,6kBaud).
Peter D. schrieb: > Bastler schrieb: >> Stell einfach >> Dein Terminal auf 250000, dann passt das schon. > > Und wie soll das gehen? > Wie schon gesagt, Hyperterminal kann keine beliebigen Werte, sondern nur > die in der Auswahl (.., 230,4, 460,8 und 921,6kBaud). In einem gescheiten Terminalprogramm kann man die Werte im Auswahlfenster einfach überschreiben. Das geht sogar im simplen Termite: http://www.compuphase.com/software_termite.htm
Nase schrieb: > Peter D. schrieb: >> Ich würde die Strings zu Anfang einmal parsen und als eine Liste von >> Calls im RAM ablegen (Funktionspointer). > > Das kann LunaAVR aber nicht. Abgesehen halt vom händisch-Ablegen der > Einsprungadressen und dann icall. Argumente muss man wohl vorher auch > von Hand auf den Stack legen dann müssen die Sprungtabellen in meinen Projekten wohl magisch sein, der Befehl dafür ist icall wenn man keine Ahnung hat...
Kann jetzt mit SerialComInstruments getestet werden. http://www.serialcominstruments.com/instrument.php Neuer Befehl dazu: Serial Out für SerialComInstruments #SI_Imm_Cnn wobei mm = verwendetes Instrument nn = Channel Beispiel #CL Clear Befehlspuffer #AI2_C14 Analog Input 2 auf Channel 14 #SI_I90_C14 Channel 14 für Instrument 90 (Mini Trend) ausgeben #Start Die Ausgabe erfolgt dann in der Form #nnMm< wobei # - Identifier MesswertübertragungStart n - Instrumenten-Nummer M - Identifier Messwert Start m - Messwert < - Ende Messwert Mit realen Werten sieht die serielle Ausgabe dann z.B. so aus: #90M289<
:
Bearbeitet durch User
sand schrieb: > ich habe einen Vorschlag die mathematische Fähigkeiten zu erweitern. > Wurzelfunktion Kommt in der nächsten Version.
Wenn die Kommunikation sowieso nicht zu sehen ist, warum muss sie überhaupt aus lesbaren Zeichen bestehen? Da auch Messungsfolgen schnell ablaufen könnten, wäre ine Binärform wesentlich einfacher. so könnte man beispielsweise die Funktionen quasi-direkt adressieren durch ein gesendetes Kommando. Überläufe müssen natürlich abgefangen werden, aber so entfällt jegliches gefummel mit Strings und dessen Umwandlung. Antworten können ja genauso verschickt binär werden, sozusagen mit ACK/NAK wie auch bei den Bootloadern praktiziert wird.
Es gibt neue Befehle: Quadratwurzel, direkte Kanal zu Kanal Zuweisung, Analog Trigger #CL ClearComandBuffer and Reset BufferCounter (immer zuerst) #SB SerialOutCmdBuffer (Dump Command Buffer to Serial) #Stop Stop Acquisition #Start Start Acquisition #AIx_Cnn Analog Input x auf Channel nn (x=0..9 , nn=01..40) #LH_Cnn_Px_Bitn_v Limit/Trigger High setzt Bit n von Port x solange Channel nn > v (wobei v = int32) #M+Cnn_Cmm_Coo Addition von Cmm und Coo nach Cnn #M-Cnn_Cmm_Coo Subtraktion von Cmm und Coo nach Cnn #M*Cnn_Cmm_Coo Multiplikation von Cmm und Coo nach Cnn #M/Cnn_Cmm_Coo Division von Cmm und Coo nach Cnn #MR_Cnn Quadratwurzel(aus int32) von Cnn nach Cnn #Cnn=Cmm Kopiere Wert von Cnn nach Cmm #SO_Cnn Serial Out Channel nn #SI_Inn_Cnn Serial Out für SerialComIntruments ------------------------------------------------------------- Beispiel für Quadratwurzel, direkte Kanalzuweisung und Limit/Trigger #CL Clear Befehlspuffer #AI2_C13 Analog Input 2 auf Channel 13 #C15=C13 Channel 13 nach Channel 15 kopieren #MR_C15 SquareRoot von Channel 15 nach Channel 15 #LH_C15_PB_Bit5_30 LimitHigh setzt PortB.5 wenn C15 > 30 #SO_C13 Serial Out Channel 13 #SO_C15 Serial Out Channel 15 Danke an Uwe S. (de0508) für die neuen schnellen LunaAVR Wurzelfunktionen (ca. 20us lt. Logic Analyzer). Hardware: ATMega 328P 16 MHz, 250000 Baud (Test mit Arduino Nano). Sorry, ich habe gerade bemerkt, dass ich in den vorhergehenden Posts teilweise das falsche File Format angegängt habe :) Für das schnelle Uploaden des Hex-Files auf einen Arduino habe ich noch den freien XLoader angehängt.
:
Bearbeitet durch User
Die Befehlsstruktur wird für die nächste Version leserlicher. (Cnn steht jeweils für einen Kanal C mit der Nummer nn (01...40) Alt Neu ------------------------------------------------------------------- #CL #CL Clear Command Buffer #SB #SB Serial Out Command Buffer #Stop #Stop Stop Acquisition #Start #Start Start Acquisition #AIx_Cnn #Cnn=AIx Analog Input x nach Cnn #Cnn=AIxMn A-In n mal gemittelt (n=3..10) #LH_Cnn_Px_Bitn_v #Pxn=Cnn>Cmm Setze Port x Byte n if Cnn>Cmm #Pxn=Cnn<Cmm Setze Port x Byte n if Cnn<Cmm #M+Cnn_Cmm_Coo #Cnn=Cmm+Coo Arithmetische Operationen #M-Cnn_Cmm_Coo #Cnn=Cmm-Coo #M*Cnn_Cmm_Coo #Cnn=Cmm*Coo #M/Cnn_Cmm_Coo #Cnn=Cmm/Coo #MR_Cnn #Cnn=SQRT(Cnn) #Cnn=Cmm #Cnn=Cmm #Cnn=Vv Cnn = Value v (int32) #SO_Cnn #SO=Cnn Channel Cnn seriell ausgeben #SO=Cnn(t) Cnn mit preceding Text seriell out #SI_Inn_Cnn #SOI=Cnn(Inn) Cnn formatiert ausgeben für SerialComInstruments wobei Inn die Instrumenten Nr. ist.
:
Bearbeitet durch User
Hier die neue Version mit überarbeiteter Syntax. Lauffähig auf ATMega 328P 16 MHz ,(z.B. Arduino Uno/Nano) Schnittstelle 250000 Baud #CL Clear Command Buffer #SB Serial Out Command Buffer #Stop Stop Acquisition #Start Start Acquisition #Cnn=AIxMn Analog Input x Mittelung n mal (1=keine Mittelung) #Pxn=Cnn>Cmm Setze Port x (B..D) Byte n (0..7 if Cnn>Cmm #Cnn=Cmm+Coo Addition #Cnn=Cmm-Coo Subtrktion #Cnn=Cmm*Coo Multiplikation #Cnn=Cmm/Coo Division #Cnn=SQRT(Cnn) Quadratwurzel #Cnn==Cmm Direkte Kanalzuweisung #Cnn=Vv Channel nn = Value v (int32) #SOCR=Cnn Channel Cnn seriell ausgeben, Abschluss CR #SOS=Cnn Channel Cnn seriell ausgeben, Abschluss Semicolon ";" (dies ist die schnellste Ausgabeart) #SON=Cnn Channel Cnn seriell ausgeben mit preeceding Channel Nr. #SO=Cnn(t) Channel Cnn seriell ausgeben mit preceding Text t #SOI=Cnn(Inn) Cnn formatiert ausgeben für SerialComInstruments wobei nn von I die Instrumenten Nr. ist. Beispiel: Leistungsmessung (Spannung u Strom)) über 2 Analogeingänge, Mittelung über 9 Werte, solange die Leistung höher als 500 ist PortB.5 setzen. Serielle Ausgabe aller Kanäle: #CL #C11=AI1M9 #C12=AI2M9 #C15=C11*C12 #C17=V500 #PB5=C15>C17 #SO=C11(Spannung) #SO=C12(Strom) #SO=C15(Leistung) #Start Hex-File für ATMega 328P, incl Uploader sind beigefügt.
:
Bearbeitet durch User
Bastler schrieb: > @Mods: Bitte den Thread zu Projekte & Code verschieben Nö. Das ist ja kein Code, sondern nur closed source. Und deswegen schaffe ich mir auch kein extra Terminalprogramm an, was exotische 250KBaud kann.
> @Mods: Bitte den Thread zu Projekte & Code verschieben
Warum wurde der überhaupt verschoben?
War doch zu erwarten, dass das Projekt nicht lange auf sich warten lässt
:)
Peter D. schrieb: > Bastler schrieb: >> @Mods: Bitte den Thread zu Projekte & Code verschieben > > Nö. > Das ist ja kein Code, sondern nur closed source. > Und deswegen schaffe ich mir auch kein extra Terminalprogramm an, was > exotische 250KBaud kann. Bei SerialComInstruments gibt es keinen Code. Bei SerialComCNC gibt es keinen Code. Beide stehen unter Projekte + Code. Was stellst Du Dich also plötzlich zu komisch an? Nur weil Du nicht in der Lage bist die gar nicht so exotischen 250000 Baud einzustellen? Zu Deiner Information: Die 250000 Baud ergeben bei einem 16 MHz Quarz Null Fehlerrate für die serielle, im Gegensatz zu z.B. 256000 Baud. Aber weisst Du was, ich muss hier ja nicht unbedingt was posten wenn es Dir nicht passt. Schönen Abend noch.
Peter D. schrieb: > Bastler schrieb: >> @Mods: Bitte den Thread zu Projekte & Code verschieben > > Nö. > Das ist ja kein Code, sondern nur closed source. > Und deswegen schaffe ich mir auch kein extra Terminalprogramm an, was > exotische 250KBaud kann. einem FTDI-USB ist es herzlich egal ob es 211, 133 oder 250 kbaud sind, funktioniert alles, auch solche die passend zur Taktrate des Controllers wären.
Albert M. schrieb: > Zu Deiner Information: Die 250000 Baud ergeben bei einem 16 MHz Quarz > Null Fehlerrate für die serielle, im Gegensatz zu z.B. 256000 Baud. Zu deiner Information: Ein klassischer UART wie der 16550, der quasi in jedem PC verbaut wird (wurde), kann das aber eben nicht direkt fehlerfrei. 16 MHz war und ist seit nun 30 Jahren halt kein typischer Baud-Raten-Quarz. Da ist z.B. 18,432 MHz üblicher.
Albert M. schrieb: > Bei SerialComInstruments gibt es keinen Code. > Bei SerialComCNC gibt es keinen Code. > Beide stehen unter Projekte + Code. Ja, die würde ich dort auch rausschmeißen, aber ich habe nicht den Zugriff darauf. Albert M. schrieb: > Was stellst Du Dich also plötzlich zu komisch an? Nicht plötzlich, sondern schon immer. Ich würde nur Projekte zulassen, die jeder erweitern und anpassen kann. Albert M. schrieb: > Nur weil Du nicht in der Lage bist die gar nicht so exotischen 250000 > Baud einzustellen? Du sagst doch selber, daß die der Flaschenhals sind. Warum also nicht gleich 921,6kBaud nehmen, geht prima mit nem 14,7456MHz Standardquarz.
Peter D. schrieb: > Albert M. schrieb: >> Bei SerialComInstruments gibt es keinen Code. >> Bei SerialComCNC gibt es keinen Code. >> Beide stehen unter Projekte + Code. > > Ja, die würde ich dort auch rausschmeißen, aber ich habe nicht den > Zugriff darauf. Jedem kann man es nicht recht machen. Ich bin aber auch der Meinung, daß es unter Projekte besser aufgehoben ist, egal ob mit oder ohne Code. Immerhin steht in dieser Kategorie als Überschrift: > Hier könnt ihr eure Projekte, Schaltungen oder Codeschnipsel vorstellen > und diskutieren. Bitte hier keine Fragen posten!
> Albert M. schrieb: >> Nur weil Du nicht in der Lage bist die gar nicht so exotischen 250000 >> Baud einzustellen? > > Du sagst doch selber, daß die der Flaschenhals sind. Warum also nicht > gleich 921,6kBaud nehmen, geht prima mit nem 14,7456MHz Standardquarz. Peter ich erläre Dir jetzt mal, wie die 250000 Baud zustande gekommen sind, dass hättest Du aber auch aus dem Kontext erkennen können: Die Software habe ich mit dem getestet was gerade bei mir rumlag, nämlich ein Arduino Nano, die haben einen 16 MHZ Quarz/Resonator fest verbaut. Für Speed Tests war mir 115200 Baud zu gering. 256000 Baud ergeben mit 16 MHz Quarz Fehler und in Richtung 500000 Baud ist eine sichere Übertragung, zumindest mit dem mir vorliegenden Nano Board nicht mehr gegeben. Da bietet sich 250000 Baud an, weil es damit keine Baudratenfehler gibt. Es hilft also nichts mir jetzt jedesmal was von anderen normierten Quarzfrequenzen zu erzählen, der Nano hat seinen fest verbaut. Für wie blöde hälst Du mich eigentlich, dass Du mir penetrant meinst erklären zu müssen welche Standard Quarzfrequenzen es gibt? Die nächsten Versionen werden als 3 verschiedene Hex-Compilate mit 115200, 250000 und 256000 Baud kommen. Wer noch eine andere Baudrate benötigt kann sich ja melden. Ich habe vor einiger Zeit mal verschiedene Serial-USB(virtual) Wandler getestet, einer funktionierte noch mit über 900000 Baud, die anderen (China) sind über 250000 nicht mehr sicher zu betreiben.
:
Bearbeitet durch User
Mangels Interesse der Leser (z.Z. 4 Downloads) und Ignoranz der Moderatoren werde ich dieses Projekt hier nicht weiterführen. Es ist möglich, dass das Projekt von anderer Seite weitergeführt und weiter ausgebaut wird. Vielleicht stelle ich irgend wann mal spezielle Versionen auf meiner Homepage zur Verfügung. http://www.serialcominstruments.com/ Gruss Ulrich Albert
Vor 4 Tagen gab es die allererste Hex. Vor 1 Tag eine überarbeitete Syntax. In der langen Zeit nur 4 Downloads. (einer war ich) Und die MOD's ignorieren das Projekt. Daß du etwas sensibel bist, ist wohl auch nur so ein Vorurteil. Und wenn es mehr als eine HEX gäbe, dann würde auch was vorangehen, dann müßte keiner wegen der Baudrate meckern, dann könnte einfach jeder seinen Lieblingsquarz verwenden. PS: ich geb's zu, ich hab das nur runtergeladen um den generierten Code des L...-Compilers zu sehen. In weiß nun, warum der kein "volatile" braucht.
Albert M. schrieb: > Mangels Interesse der Leser (z.Z. 4 Downloads) und Ignoranz der > Moderatoren werde ich dieses Projekt hier nicht weiterführen. > Damit musst du leben oder dein Angebot nochmal überdenken. Also ehrlich, Baudrate Einstellung auf Anfrage mit extra Hex-File ist doch echt ein Witz.
:
Bearbeitet durch User
Ein Mehrwert entstünde bei einer Integration von SerialComMeasurement in SerialComInstruments, weil der Nutzer dann nicht mehr auf die Ebene der uC-Programmierung herabsteigen muss. So kann auch die Auslastung des USB-Busses durch den virtuellen Comport optimiert werden. Einzig die, später vielleicht nur einmalig durchzuführende, Programmierung des bin-Files wäre noch erforderlich. Vielleicht könnte sogar der Updateprozess für SerialComMeasurement in SerialComInstruments integriert und vielleicht könnten auch fertig programmierte Platinchen angeboten werden. Idealerweise wäre alles plattformunabhängig und würde auch unter Linux und auf Android mit Bluetooth laufen. Aber Du, Albert, hängst sehr am alten delphi. Davon abgesehen ist es für alle Windows-Nutzer interessant. SerialComMeasurement für sich allein hat kaum einen Nutzen. Die meisten hier werden die von Dir zusätzlich eingeführte Abstraktionsebene nicht benötigen und einfach selbst mit Lua, python, Arduino oder der Entwicklungsumgebung des Herstellers programmieren. Und diejenigen, die das nicht können, schaffen es auch nicht, auf der PC-Seite einen virtuellen Comport mit einem eigenen Programm zur Weiterverarbeitung der Daten zu öffnen.
Albert M. schrieb: > Mangels Interesse der Leser (z.Z. 4 Downloads) und Ignoranz der > Moderatoren werde ich dieses Projekt hier nicht weiterführen. Was hast du erwartet? Ein closed-Source Programm auf dem PC lasse ich mir ja noch gefallen, aber als hex für einen ATMEGA niemals. Hast du schon mal daran gedacht, dass jemand ja gern noch etwas anderes zusätzlich auf seinen MC laufen lassen möchete? Also auch wenn es arrogant klingt, stell den Sourcecode hier rein oder vergiss es. Es gibt einfach schon zu viele tolle Projekte die wegen Magels an Lust ein einer Sackgasse enden. z.B. CanHacker und Hterm.
Kinder ? das Thread "Projekt: SerialComMeasurement" hat Albert M. hier beendet und wird hier nicht mehr schreiben. So sind weitere Beiträge nicht sinnvoll oder weiterführend. Nur "by the way"; ich habe mir einen SerialComMeasurement clone geschrieben mit optimierter Programmausführung, durch einen erweiterten Scanner mit Parser. Diese einfache Programm schaltete den Pin PB7 über den Interpreter um.
1 | #PB7=0
|
2 | #PB7=1
|
Die Zykluszeit beträgt max 54.6µs und dies entspricht einer Frequenz von 18,315kHz pro Durchlauf. Wir werden halt nur intern darüber diskutieren... by the way...
:
Bearbeitet durch User
temp schrieb: > einfach schon zu viele tolle Projekte die wegen Magels an Lust ein einer > Sackgasse enden. z.B. CanHacker und Hterm. Und SerialComInstruments...
Uwe S. schrieb: > das Thread "Projekt: SerialComMeasurement" hat Albert M. hier beendet > und wird hier nicht mehr schreiben. Friede seiner Asche.
MWS schrieb: > Friede seiner Asche. Schrieb der Bascom Forum Moderator der neidisch auf LunaAVR blickt.
Bastler schrieb: > MWS schrieb: >> Friede seiner Asche. > > Schrieb der Bascom Forum Moderator der neidisch auf LunaAVR blickt. Noch ein Minion ;D Weder bin ich Mod, noch neidisch. Mir geht nur das pseudoelitäre Gehabe der Bluna-Jünger auf den Zeiger, die aufgrund Verlustängsten, dass ihnen jemand irgendwas wegnimmt, alles abzukapseln versuchen. Einer weniger ist doch 'ne schöne Sache und gibt Hoffnung, dass irgendwann alle in ihrer kleinen selbstgemachten Quarantäne sind und dort auch bleiben.
Es gibt hier die Regel, daß man nicht mit 2 Namen in einem Thread posten darf. Nur was macht man wenn jemand anderer den Nick kapert? Und man sich nie das Passwort seinen User merken kann? Nun zur Sache: "Closed" weckt immer Neugier und so habe ich das mal durch einen Disassembler gejagt. Für so einen 1-Mann-Compiler nicht schlecht. Aber auch nicht vergleichbar mit Mannjahrhunderten des GCC. > nur runtergeladen um den generierten Code des LunaAVR-Compilers zu > sehen. In weiß nun, warum der kein "volatile" braucht.
Uwe S. schrieb: > Kinder ? > > das Thread "Projekt: SerialComMeasurement" hat Albert M. hier beendet > und wird hier nicht mehr schreiben. > So sind weitere Beiträge nicht sinnvoll oder weiterführend. > Wenn nur noch über Luna und Bascom geschwafelt wird und Leute sich in irgendwelche Schubladen stecken hast du sicher recht. Und manchmal geht es hier nur noch um Rechthaberei. Aber das eigendliche Problem ist ja das jemand, in welcher Sprache oder unter welchen Bedingungen auch immer, etwas anbietet und damit scheitert.
Hans-Georg L. schrieb: > Aber das eigendliche Problem ist ja das jemand, in welcher Sprache oder > unter welchen Bedingungen auch immer, etwas anbietet und damit > scheitert. Nein, das ist nicht das Problem. Das eigentliche Problem ist, dass jemand mit etwas zuviel Ego auf der einen Seite verbreitet, er würde diese Sachen aus Spaß an der Freude schreiben, auf der anderen Seite ist ihm das mangelnde Feedback oder Kritik dann Grund genug, um die Sache zu beenden. Dieses Risiko besteht bei closed Source immer, deshalb sind Closedsourceprogrammierer dann am verlässlichen, wenn sie einem starken Motiv folgen, wie etwa dem, Geld dmit zu verdienen. Des Kollegen Motiv hier ist dagegen das Bauchpinseln seines Egos und das ist eben für die potentiellen Nutzer ein recht riskantes und unberechenbares Motiv, wie hier auch schön bewiesen wurde.
MWS schrieb: > Des Kollegen Motiv hier ist dagegen das Bauchpinseln seines Egos Von Dir hat man noch nie etwas gesehen, was des Bauchpinselns würdig gewesen wäre. Kannst Du auch was Produktives? Die dummen unsachlichen Sprüche von Dir sind hier ja bekannt und bedürfen keiner weiteren Erwiederung. Bastler (der Echte!) schrieb: > Nun zur Sache: "Closed" weckt immer Neugier und so habe ich das mal > durch einen Disassembler gejagt. Für so einen 1-Mann-Compiler nicht > schlecht. Aber auch nicht vergleichbar mit Mannjahrhunderten des GCC. Ist kein GCC, aber LunaAVR ist besser und moderner als alles andere was sonst so angeboten wird und dabei kostenlos. Ich mag kein C, daher war es für mich die 1. Wahl. Hans-Georg L. schrieb: > Aber das eigendliche Problem ist ja das jemand, in welcher Sprache oder > unter welchen Bedingungen auch immer, etwas anbietet und damit > scheitert. Dazu von mir in diesem Thread noch ein letztes Wort: Ich habe erkennen müssen, dass dieses Forum für dieses Projekt die falsche Zielgruppe ist. Mit 4 Projekten lag ich hier richtig, mit diesem nicht. Soll ja mal vorkommen. Daher führe ich es hier nicht weiter. Wer sich dennoch dafür interessiert, kann ja demnächst mal auf meine Homepage schauen (Link siehe oben). Da wird es unter anderem eine erheblich erweiterte und schnellere Version geben, mit vielen weiteren Möglichkeiten, insbesondere mit einer Anbindung an SerialComInstruments. Ausserdem arbeitet Uwe S. an einer eigenen Version. Soviel zu dem Weiterbestehen des Projektes. Gruss Ulrich Albert
:
Bearbeitet durch User
Bastler (der Echte!) schrieb: > Nun zur Sache: "Closed" weckt immer Neugier und so habe ich das mal > durch einen Disassembler gejagt. Für so einen 1-Mann-Compiler nicht > schlecht. Aber auch nicht vergleichbar mit Mannjahrhunderten des GCC. der assembler-output kann generiert werden. ich hätte nur gerne den luna-source gehabt (verwende auch luna), da wäre sicher noch optimierungspotential gewesen. Die Optimierungen des Compilers sind schon recht gut wenn man ihm keine Knüppel dazwischenwirft.
Albert M. schrieb: > MWS schrieb: >> Des Kollegen Motiv hier ist dagegen das Bauchpinseln seines Egos > > Von Dir hat man noch nie etwas gesehen, was des Bauchpinselns würdig > gewesen wäre. Verstehst Du meine Aussage nicht? Dann hab' ich Dich wohl überschätzt. > Kannst Du auch was Produktives? Sowas "produktives", wie hier 'ne Welle zu machen, um dann als beleidigte Leberwurst zurückzurudern? Nein, das kann ich nicht LOL > keiner weiteren Erwiederung. Das ist das Selbe, wie der "Wiederstand", den gibt's auch nicht. Deine Aktion hier sollte nebenbei wohl ein wenig Aufmerksamkeit auf Deine eigene Domain lenken, Du benutzt das MC.net als Werbeplattform, also erzähl keinen Unsinn von wegen "falsche Zielgruppe". Für wie dumm hältst Du die Leser hier?
Albert M. schrieb: > Mangels Interesse der Leser (z.Z. 4 Downloads) Weil es vielleicht a) an Sinn und Zweck, b) am Mitmachen- und selbst Verändern/Anpassen Können mangelt? Allein dem Guru und seinem Werk huldigen ist nicht unbedingt jedermanns Sache. Und sei es auch noch so kostenlos.
MWS schrieb: > Albert M. schrieb: >> MWS schrieb: >>> Des Kollegen Motiv hier ist dagegen das Bauchpinseln seines Egos >> >> Von Dir hat man noch nie etwas gesehen, was des Bauchpinselns würdig >> gewesen wäre. > > Verstehst Du meine Aussage nicht? Dann hab' ich Dich wohl überschätzt. och, nun mach doch nicht ständig so einen Weinerle, tipp doch mal deinen eigenen Nick in die Suche hier, da kommt nur dümmliches Geschwafel, verdeckte Beleidigungen und offensichtlich abgeladener Frust. Nein - keine Projekte, keine Lösungswege oder Hilfen, also wer überschätzt hier wen? Wohl eher eine Selbstüberschätzung. Das Geschreibsel kann man nicht ernst nehmen. > Für wie dumm hältst Du die Leser hier? ich lass mich hier jdenfalls nicht von dir vereinnahmen, "Die Leser" stehen weder hinter dir noch sprichst du in unser Aller Namen. Dein Nick ist eine Garantie für zerstörte Threads, soweit ist "den Lesern" schon lange klar.
Robert M. schrieb: > Das Geschreibsel kann man nicht ernst nehmen. Warum antwortest Du dann? Robert M. schrieb: >> Für wie dumm hältst Du die Leser hier? > > ich lass mich hier jdenfalls nicht von dir vereinnahmen, "Die Leser" > stehen weder hinter dir noch sprichst du in unser Aller Namen. Nein, im Namen aller oder in Deinem Namen spreche ich sicherlich nicht. Dann will ich mich mal korrigieren in die: "Für wie dumm hältst Du die intelligenteren Leser hier?" Solltest Du selbiger TE Robert M. von hier sein: Beitrag "Re: Jetzt reichts! BASCOM = SCHROTT!!" so hab' ich versucht Dir zu helfen, da Dein Post offensichtlich nur Provokation war, tatsächlich ohne Erfolg. Sind denn heut' wieder die ganzen Bluna-Minions unterwegs? LOL
sagmal liest du auch was du schreibst? das ist ja schon psychisch auffällig in Jedem und Alles irgendwie was von "Bluna" zu sehen und nein der Beitrag ist mir unbekannt. Armer Tropf, nimm besser dein Medikamente ROTFL
MWS schrieb: > "Für wie dumm hältst Du die intelligenteren Leser hier?" Also wenn es deine Intelligenz ist, dann bin ich dann lieber bei den Dummen. Dein Nick ist tatsächlich eine Garantie für kaputtgemachte Threads. MWS schrieb: > Sind denn heut' wieder die ganzen Bluna-Minions unterwegs? LOL was soll denn Bluna-Minions sein? also ich finde die Minions knuffig :P
Peter schrieb: > kaputtgemachte Threads Wer bitte hat den Thread denn für beendet erklärt? MWS hat hier durchaus recht treffend analysiert. Manchmal ist das freilich wenig zielführend, um tiefere Freundschaften zu begründen!
Albert M. schrieb: > Dazu von mir in diesem Thread noch ein letztes Wort: och, jetzt ist die Leberwurst beleidigt :( lg Heiner
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.