Forum: Mikrocontroller und Digitale Elektronik Projekt: SerialComMeasurement


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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
von blubber (Gast)


Lesenswert?

Klingt sportlich aber interessant.

Halte uns bitte auf dem Laufenden.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

"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.

von Bestromer (Gast)


Lesenswert?

.....ganz schön "wenig Lust" für so ein umfangreiches Projekt... Was 
erwartest Du jetzt?

von Pandur S. (jetztnicht)


Lesenswert?

Hab ich auch schon gemacht ... dh es ist machbar.

von c-hater (Gast)


Lesenswert?

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...

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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?

von Michael K. (Gast)


Lesenswert?

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' ...

von Gerhard W. (gerhard_w)


Lesenswert?

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!!!

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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
von Uwe (de0508)


Lesenswert?

Hallo Albert,

ich bin auf deine Projektgestaltung mit LunaAVR gespannt.

Mit der neuen Release V2015 R1.6 hat sich einiges getan.

von Ehrhardt B. (ehbal)


Lesenswert?

interessantes Projekt, bin ebenfalls gespannt.

DAPL ist nicht besonders eingängig, jedoch sehe ich da eine brauchbare 
Basis.

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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
von Moby A. (moby-project) Benutzerseite


Lesenswert?

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 ;-)

von Bastler (Gast)


Lesenswert?

Dann einig dich doch mit Albert darauf, daß du seine Idee in Assembler 
statt Luna realisierst, dann ist allen geholfen.

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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
von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

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 ...

von Nase (Gast)


Lesenswert?

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.

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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
von F. F. (foldi)


Lesenswert?

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.

von Nase (Gast)


Lesenswert?

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...

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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
von Bastler (Gast)


Lesenswert?

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.

von Jonas G. (jstjst)


Lesenswert?

Mach einfach mal. Bei deinen anderen Projekten war es am Anfang auch 
nicht anders.

von Nase (Gast)


Lesenswert?

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.

von Bastler (Gast)


Lesenswert?

Den Drang kenn ich ;-)

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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.

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Angehängte Dateien:

Lesenswert?

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
von Gerhard W. (gerhard_w)


Lesenswert?

@Mods: Bitte den Thread wieder zu Projekte & Code verschieben

von Bein (Gast)


Lesenswert?

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!!

von Bastler (Gast)


Lesenswert?

Es gibt diverse OpenSource-Projekte wo so was schon passiert ist. Und 
wenn's andere interessiert hat, dann haben die eben weiter gemacht.

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Angehängte Dateien:

Lesenswert?

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
von Uwe (de0508)


Lesenswert?

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
von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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
von wire (Gast)


Lesenswert?

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

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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
von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite



Lesenswert?

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
von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Angehängte Dateien:

Lesenswert?

Sorry, im hex-File steckten noch Bugs. Hier die Korrektur

: Bearbeitet durch User
von TutnichtszurSache (Gast)


Lesenswert?


von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Angehängte Dateien:

Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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).

von sand (Gast)


Lesenswert?

Hallo Albert,

ich habe einen Vorschlag die mathematische Fähigkeiten zu erweitern.

Wurzelfunktion

von Bastler (Gast)


Lesenswert?

> Wurzelfunktion

auf dem armen kleinen AVR?
Das kann der PC hinter der Seriellen Schnittstelle viel besser!

von Nase (Gast)


Lesenswert?

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

von sand (Gast)


Lesenswert?

es mag sein, aber dann sollten sämtliche mathematische und logische 
Funktionen in SerialComInstrument eingebettet sein.

von Uwe (de0508)


Lesenswert?

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 !

von TutnichtszurSache (Gast)


Angehängte Dateien:

Lesenswert?

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.

von Bastler (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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).

von Bastler (Gast)


Lesenswert?

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

von Robert (Gast)


Lesenswert?

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...

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Angehängte Dateien:

Lesenswert?

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
von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

sand schrieb:
> ich habe einen Vorschlag die mathematische Fähigkeiten zu erweitern.
> Wurzelfunktion

Kommt in der nächsten Version.

von Robert (Gast)


Lesenswert?

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.

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Angehängte Dateien:

Lesenswert?

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
von Bastler (Gast)


Lesenswert?

.
@Mods: Bitte den Thread zu Projekte & Code verschieben
.

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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
von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Angehängte Dateien:

Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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.

von Jonas G. (jstjst)


Lesenswert?

> @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 
:)

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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.

von wire (Gast)


Lesenswert?

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.

von Keiner (Gast)


Lesenswert?

Nicht mehr als der unfehlbare Heiner.

von Nase (Gast)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von Gerhard W. (gerhard_w)


Lesenswert?

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!

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

> 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
von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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

von Bastler (Gast)


Lesenswert?

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.

von Hans-Georg L. (h-g-l)


Lesenswert?

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
von Lars R. (lrs)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von Uwe (de0508)


Lesenswert?

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
von Moby (Gast)


Lesenswert?

temp schrieb:
> einfach schon zu viele tolle Projekte die wegen Magels an Lust ein einer
> Sackgasse enden. z.B. CanHacker und Hterm.

Und SerialComInstruments...

von MWS (Gast)


Lesenswert?

Uwe S. schrieb:
> das Thread "Projekt: SerialComMeasurement" hat Albert M. hier beendet
> und wird hier nicht mehr schreiben.

Friede seiner Asche.

von Bastler (Gast)


Lesenswert?

MWS schrieb:
> Friede seiner Asche.

Schrieb der Bascom Forum Moderator der neidisch auf LunaAVR blickt.

von MWS (Gast)


Lesenswert?

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.

von Bastler (der Echte!) (Gast)


Lesenswert?

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.

von Hans-Georg L. (h-g-l)


Lesenswert?

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.

von MWS (Gast)


Lesenswert?

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.

von Albert M. (Firma: Bastler aus Mönchengladbach) (albertm) Benutzerseite


Lesenswert?

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
von Peter (Gast)


Lesenswert?

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.

von MWS (Gast)


Lesenswert?

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?

von Rene Degenhardt (Gast)


Lesenswert?

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.

von Robert M. (Gast)


Lesenswert?

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.

von MWS (Gast)


Lesenswert?

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

von Robert M. (Gast)


Lesenswert?

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

von Peter (Gast)


Lesenswert?

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

von Rene Degenhardt (Gast)


Lesenswert?

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!

von Heiner (Gast)


Lesenswert?

Albert M. schrieb:
> Dazu von mir in diesem Thread noch ein letztes Wort:

och, jetzt ist die Leberwurst beleidigt :(

lg Heiner

von Bastler (Gast)


Lesenswert?

Hier geht es weiter incl. neuer Benchmarks.

http://www.serialcominstruments.com/measurement.php

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