ATMEL stellt grafische Oberfläche für 8 bit Controller vor

LabView für die ATmega-Familie. Ich bin gespannt.

Mir ist nicht klar, ob die Firma wirklich mit Atmel verbandelt ist.
Das Tool hat aber mehrere interessante Eigenschaften:
http://avrtools.no/Main.asp?page=7

chris_ schrieb:
> Mir ist nicht klar, ob die Firma wirklich mit Atmel verbandelt ist.
Wenn ich das recht verstehe, nicht.

http://whois.net/whois/avrtools.no

Hallo,

einen wunden Punkt befürchte ich allerdings:

Normalerweise werden Vorteile in Werbebeiträgen (und das ist 
letztendlich auch der AVR Tools Link) immer groß herausgestellt.

Aber: keine Angaben ob Freeware -> also wird es wohl  (für einen 
Hobbyisten) viel kosten :-(  also ein dickes "No Go"

Falls ich mir getäuscht haben sollte: um so besser.

Bastler

AchWieLustig schrieb:
> Was meint ihr dazu?

April-Scherz.

Wir brauchen keine Angst haben das der rechtschaffende Programmierer 
ausstirbt :-)

Beitrag "Re: Interesse an Alternative zu BASCOM?"

Das release wird schon seit Jahren immer wieder verschoben...

hp-freund schrieb:
> Wir brauchen keine Angst haben das der rechtschaffende
> Programmierer
> ausstirbt :-)
>
> Beitrag "Re: Interesse an Alternative zu BASCOM?"
>
> Das release wird schon seit Jahren immer wieder verschoben...

große Sprüche liest man immer wieder, Alternativen dafür gibts aber 
längst: http://avr.myluna.de

ldi R16,0x01 ?

Du brauchst sowas nicht ;-)

Wird die übliche nutzlose Pupsware sein. Allein der Schaltplan ist schon 
eine Zumutung: http://avrtools.no/Main.asp?page=7

Das sieht richtig gut aus. Es werden aber nur verhältnismäßig große
Kontroller unterstützt. Mal sehen, ob man es dann mal so ausprobieren
kann, oder ob man es kaufen muß. Da würden die "normalen Menschen",
die 5-6 Sachen im Jahr bauen nicht drangehen.

MfG Paul

Klasse. Das komplizierte ARM Cortex Geraffel sieht wieder ein Stück 
älter aus :-)

Peter Dannegger schrieb:
> Stellt euch mal vor, ein Programm würde wie der Schaltplan einen
> Fernsehempfängers aussehen. Und das wäre auch nur ein mittelkleines
> Programm.

Angriffsziel der kleinen einfachen 8-Bitter sind die Millionen kleinen, 
bitteschön schnell zu implementierenden Aufgaben des Alltags. Dafür ist 
so was grafisches I DE AL.

Jaja, jetzt geht die Diskussion um graphisch oder textorientiert wieder 
los.

>Eh man überhaupt rausgekriegt hat, welche Klötzchen es gibt und wie man
>sie verschalten muß.

LabView lässt sich deutlich schneller als C erlernen.
Bei den graphischen Programmiersprachen hängt es sehr davon ab, wie gut 
die Entwicklungsumgebung gemacht ist.

markus schrieb:
> Jaja, jetzt geht die Diskussion um graphisch oder textorientiert wieder
> los.
>
>>Eh man überhaupt rausgekriegt hat, welche Klötzchen es gibt und wie man
>>sie verschalten muß.
>
> LabView lässt sich deutlich schneller als C erlernen.
> Bei den graphischen Programmiersprachen hängt es sehr davon ab, wie gut
> die Entwicklungsumgebung gemacht ist.

LabView hat auch eine völlig andere Zielsetzung, für Datenerfassung und 
-verarbeitung ist es ja auch brauchbar. Aber niemand würde darauf 
kommen, ein @C-Programm damit zu schreiben, das über einfachste Aufgaben 
hinausgeht.

>Aber niemand würde darauf
>kommen, ein @C-Programm damit zu schreiben, das über einfachste Aufgaben
>hinausgeht.

Denkst Du: Bei uns wird es in riesigen Fertigungsprüfständen zur 
Steuerung eingesetzt.

Peter Dannegger schrieb:

> Geht mir auch so.
> Ich hab mal ein SPS-Programm anpassen müssen, das war vielleicht ne
> Qual.
>
> Eh man überhaupt rausgekriegt hat, welche Klötzchen es gibt und wie man
> sie verschalten muß.

Also das zeigt vor allem zwei Sachen:

1) Auch eine Programmiersprache aus Grafikelementen ist eine 
Programmiersprache. Man muß sie lernen, bevor man sie sinnvoll und 
effizient benutzen kann.

2) Du hast, verdammt nochmal, keine Ahnung von SPS/Step7. Wer mit 
Funktionsplan oder "Schaltplan" (hab' vergessen, wie das, was wie ein 
Schaltplan für Relais-Schaltungen aussieht, richtig heißt) nicht 
klarkommt, kann jederzeit auf AWL-Darstellung umschalten. Das ist im 
Prinzip die Assemblersprache eines virtuellen µC.

Und wer damit nicht klarkommt, kann generell nicht programmieren, weil 
ihm jegliches Verständnis für die Grundkonzepte von µC-Cores fehlt.

> Stellt euch mal vor, ein Programm würde wie der Schaltplan einen
> Fernsehempfängers aussehen. Und das wäre auch nur ein mittelkleines
> Programm.
> Das würde niemandem gefallen.

Deswegen kann man das auch sehr schön in Funktionsgruppen gliedern. Und 
zwar in jeder der zur Repräsentation des logischen Gehalts des Programms 
verfügbaren "Sprachen".

Dein Problem ist also einfach nur eins: Es ist nicht C, also in deiner 
kleinen Welt per Axiom Scheiße.

Darüber solltest du einfach mal nachdenken. Aber klar, das wird nicht 
passieren. Fanatische eingefleischte C'ler können nicht in diese 
Richtung denken. Ist genau wie bei der Geisteskrankheit "religiöser 
Fanatismus", Fakten können diese kranken Leute nur verarbeiten, solange 
sie nicht gegen ihr Weltbild verstoßen. Treten solche Fakten trotzdem 
auf, werden sie einfach ausgeblendet.

Yalu X. schrieb im Beitrag
> noch weitere Kästchen hinzu, die jeweils einzeln parametriert
> werden müssen. Grausig.

In der Tat.

> Und das ist jetzt kein an den Haaren herbeigezogenes Beispiel, sondern
> eine typische Aufgabe für einen Mikrocontroller.

Um Himmels Willen, ist sie nicht! Mach das mit C.

> Diese grafische Datenflussprogrammierung ist für eine begrenzte Klasse
> von Anwendungen sicher ganz praktisch.

Richtig. Auch wenn sich die Geister drüber streiten wie begrenzt diese 
Klasse ist.

...na beruhig Dich und den drüber nach.

>>>Aber niemand würde darauf
>>>kommen, ein @C-Programm damit zu schreiben, das über einfachste Aufgaben
>>>hinausgeht.
>>
>> Denkst Du: Bei uns wird es in riesigen Fertigungsprüfständen zur
>> Steuerung eingesetzt.

>cyberlord schrieb:

>Wo ist da der Widerspruch? Weil etwas groß ist, ist es noch lange nicht
>komplex und noch lange nict auf einem µC.

Es ist aber ziemlich komplex, das kann ich nach 16 Jahren Vorentwicklung 
sagen. Deine Klugschweisere in diesem Forum geht mir übrigens schon 
längere Zeit auf die Nerven.

Scheisserei !!

cyblord ---- schrieb:
> Je
> einfacher desto eingeschränkter, je komplexer desto universeller

Nö. Auch Programmierung lässt sich vereinfachen ohne auf wesentliches zu 
verzichten. Man muß nur über den Tellerrand hinaussehen. Die simpelste 
Programmierung für einen Roboter ist z.B. einen (komplexen) 
Handlungs/Reaktionsverlauf zu zeigen und die Maschine machts nach! Ganz 
ohne jede Textzeile und Verzicht auf wichtige Möglichkeiten :-)

jetzt wird's esoterisch ;-)

Wer einen Praktikanten/Gesellen o.ä. mal schnell eine einfache Schaltung 
realisieren oder ändern lassen will ist meistens mit einer 
Klickibunti-Oberfläche besser bedient, da man den Leuten recht schnell 
zeigen kann wie sie damit grundlegende Aufgaben wie Eingangserfassung, 
Verknüpfungen und Ausgangsschaltungen anlegen können.
Wenn es mehr als zehn "Kaesekaestchen" braucht ist man mit einer 
Programmiersprache besser bedient.
Man kann aber idR die vorhandenen "Kaesekaestchen" als Programm anzeigen 
lassen und darin ändern, was anderes als aus den "Kaesekaestchen" ein 
Programm macht die Oberfläche ja nicht ...
Allerdings ist das ganze halt wie immer in den feuchten Träumen der 
"Entscheider" zu suchen, denn statt dem Ing. mit Studium kann ich ja 
weil es jetzt so einfach ist meine Putze von Zuhause auf die 
Herz-Lungen-Maschine ansetzen, was kann da schon schiefgehen o_O

Heimatland! Die Software ist noch gar nicht herunterladbar, da steckt
hier schon wieder das Messer im Tisch....

@c_Hater
Du meinst weiter oben den KOP (Kontaktplan)

MfG Paul

AchWieLustig schrieb:
> ATMEL stellt eine grafische Programmier-Oberfläche für 8 bit ATMega's
> vor,

Ach...

Ich hatte beim Lesen der Überschrift an ein GDI und eine 
Klasenbibliothek grafischer Elemente für Atmels µC gedacht ... und nun 
sowas.

Das erinnert mich ein bissel an PSOC1 - und ich bin nicht begeistert.

W.S.

@W.S.
Nein, nicht komplizierter, EINFACHER solls werden!
Dafür fehlt manchem Profi der Sinn.

Wir Elektrotechniker arbeiten mit Bauteilen wie Widerständen, 
Kondensatoren, Transistoren, ICs. Die Bauteile verbinden wir mit Drähten 
und Kabeln oder erstellen Platinen.

Unser Ausdrucksmittel und die natürliche Gedankenwelt ist der 
Schaltplan.

Wenn wir Schaltpläne zeichnen und lesen können, wissen wir, was wir tun. 
Wir erreichen unser Ziel und fühlen wir uns wohl. Wir denken graphisch.

Mit LabView erstellen wir in Schalpläne gegossene Programme.
Deshalb lieben wir Elektrotechniker die graphischen Programmiersprachen.

cyberlord schrieb:
>Lieber Marian, aus genau diesem Grund sage ich doch, dass es Blödsinn
>ist, hier überhaupt LabView ins Spiel zu bringen, wo es doch um
>grafische Entwicklung auf Microcontrollern geht.

Wobei es allerdings schon eine Entwicklung von LabView für 
ARM-Controller gab, die allerdings wohl mangels Akzeptanz nich mehr 
weiter gepflegt wird:

http://sine.ni.com/nips/cds/view/p/lang/de/nid/209852

Wohingegen die Programmierung von FPGAs mit LabView sich sehr großer 
Beliebtheit erfreut:

http://sine.ni.com/nips/cds/view/p/lang/de/nid/209853

Der Knaller wäre dann noch die Internet-Anbindung zum Steuern + Abfragen 
von Meßdaten und dem automatischen Datenupload zur eigenen Website. Die 
vorhandene SMS Funktion ist aber schon mal ein Anfang.

AchWieLustig schrieb:
> ATMEL stellt eine grafische Programmier-Oberfläche für 8 bit ATMega's
> vor

Woraus schließt du, dass ATMEL dahinter steckt?

c-hater schrieb:
> Und wer damit nicht klarkommt, kann generell nicht programmieren, weil
> ihm jegliches Verständnis für die Grundkonzepte von µC-Cores fehlt.
>
>> Stellt euch mal vor, ein Programm würde wie der Schaltplan einen
>> Fernsehempfängers aussehen. Und das wäre auch nur ein mittelkleines
>> Programm.
>> Das würde niemandem gefallen.
>
> Deswegen kann man das auch sehr schön in Funktionsgruppen gliedern. Und
> zwar in jeder der zur Repräsentation des logischen Gehalts des Programms
> verfügbaren "Sprachen".

Hehe, deshalb ist Fernsehmechaniker auch ein Ausbildungsberuf 
(gewesen?).

BTW:
Agilent baut doch so tolle Oszilloskope.
Wusstet ihr, das die auch "in VEE machen" ?
http://www.home.agilent.com/en/pd-1476554-pn-W4000D/vee-pro-932?&cc=DE&lc=ger
Ebenso kontrovers zu diskutieren, wie alle anderen genannten grafischen 
Oberflächen auch.
Meist spielt auch die "Haptik" in die Gesamtwertung eines solchen 
Werkzeugs mit rein. Also die Features, die man eigentlich erwartet, wenn 
man den ganzen Tag vor dem Klimperkasten sitzt und in der Entwicklung 
von eben solchen Stützstellen zum Linearisieren irgentwelcher Tabellen 
steckt.
Drücke ich <STRG> und scrolle mit der Maus - was passiert?
Man würde erwarten, das sich die "Strichmännchennudelsuppe" verkleinert 
oder vergrößert. Man also hinein- und herauszomen kann. Wenn man sich 
hierzu dann auch noch Gedanken machen muss, warum dieses oder jenes 
nicht geht, kommt man NATÜRLICH aus dem Gedankenfluß. Das bremst dann 
und macht keinen Spaß, logisch.
Die grafische Programmierung ist ein komplett anderer Ansatz und hat mit 
C-Quellcodezeilen NICHTs gemeinsam.

Man kann (ich kann) mit mit einer grafischen Programmierumgebung zu 
guten Ergebnissen kommen. Man muss es lernen und wollen. Das "wollen" 
spielt zu einem großen Teil da mit rein.
Leider verlieren sich solche Programme im Ziel und vergessen dabei die 
Bedienbarkeit. Auch vielleicht, weil der Stand der Erstentwicklung schon 
Jahre zurückliegt und man die Manpower nicht in die GUI stecken mag.

Leider kann ich zu LabView nicht viel sagen. Wird doch aber an den 
Universitäten und FH's  offensichtlich gern und viel verwendet.

Soweit meine Gedanken hierzu

Axel

>kann jederzeit auf AWL-Darstellung umschalten. Das ist im
>Prinzip die Assemblersprache eines virtuellen µC.
Assembler?
Nein, im Vergleich zu richtigem ASM (bei wirklichen uCs) ist das nichts 
Anderes als kitschiges Spielzeug.

>Wenn wir Schaltpläne zeichnen und lesen können, wissen wir, was wir tun.
>Wir erreichen unser Ziel und fühlen wir uns wohl. Wir denken graphisch.
Nur was tun, wenn die Komplexität 1000e oder mehr (graf.) Schaltbilder 
erfordern würde? Dann würde man auf die Idee kommen, einzelne grobe 
Schaltbilder innen mit Text zu beschreiben.....

MCUA schrieb:
> Nur was tun, wenn die Komplexität 1000e oder mehr (graf.) Schaltbilder
> erfordern würde?

Für diese Größenordnung ist es auch nicht gedacht. Will doch niemand die 
konventionelle Programmierung abschaffen! Für jeden Einsatz das beste 
Werkzeug, das ist und bleibt das Motto.

Dirk P. schrieb:
> Wir Elektrotechniker arbeiten mit Bauteilen..
> ..Unser Ausdrucksmittel und die natürliche Gedankenwelt ist der
> Schaltplan.

Da liegt ein Denkfehler drin.

Bei allem, was parallel und getrennt voneinander arbeitet, ist ein 
Schaltplan richtig. Also Bauelemente auf einer Leiterplatte, Baugruppen 
in einer Hausinstallation und so. Auch verschiedene Gatter und Flipflops 
in einem FPGA gehören dazu. Das alles ist eigentlich prädestiniert zur 
Darstellung mittels eines Schaltplanes. Man merkt an dieser Stell auch, 
daß sowas wie HDL's eigentlich falsch plaziert sind: Ein Quelltext kann 
nicht parallel gelesen werden, sondern nur sequentiell, trotzdem sollen 
HDL's parallele Dinge beschreiben.

Bei Mikrocontrollern ist das komplett anders. So ein µC ist eine 
sequentielle Maschine, da werden Befehlsfolgen abgearbeitet und es 
passiert NICHTS parallel und getrennt voneinander, sondern immer alles 
schön nacheinander. Genau DESHALB ist eine grafische Programmierung hier 
fehl am Platze. Man tut so, als wäre so ein Kästchen eine Baugruppe, die 
man nur zu verdrahten hat, aber in Wirklichkeit ist es ein mehr oder 
weniger komplexes Unterprogramm, das nur dann abgearbeitet werden kann, 
wenn gerade kein anderes solches "Kästchen" dran ist.

Wahrscheinlich muß man es so sehen, daß es ein paar grundlegende 
Unterschiede zwischen Elektrotechnikern und Programmierern gibt.

W.S.

>Bei Mikrocontrollern ist das komplett anders. So ein µC ist eine
>sequentielle Maschine, da werden Befehlsfolgen abgearbeitet und es
>passiert NICHTS parallel und getrennt voneinander, sondern immer alles
>schön nacheinander. Genau DESHALB ist eine grafische Programmierung hier
>fehl am Platze.

Das finde ich nicht. Nach mehreren Jahren C und LabView muss ich sagen: 
Genau das ist der Vorteil an LabView. Die graphische Struktur 
abstrahiert so weit, dass die Programme auch auf dem Mikrocontroller 
parallel zu laufen scheinen. Man hört auf, sequentiell zu denken. Das 
ist ein großer Vorteil, weil rein sequentielle Abläufe eine ziemlich 
starke Einschränkung für das Denken bedeuten und schlichtweg nur durch 
die technologische Beschränkung der MCs verursacht werden.
Die sequentielle Abarbeitung eines Programms wird auch durch ein 
Multitasking-System in gewissen Grennzen "weg abstrahiert".

W.S. schrieb:
> Man tut so, als wäre so ein Kästchen eine Baugruppe, die
> man nur zu verdrahten hat, aber in Wirklichkeit ist es ein mehr oder
> weniger komplexes Unterprogramm, das nur dann abgearbeitet werden kann,
> wenn gerade kein anderes solches "Kästchen" dran ist.

So ist es halt. Aber selbst Multi Thread Programmierung und Interrupts 
setzen sich darüber hinweg und versuchen dem Nutzer eine Parallelität 
und Unabhängigkeit der Bearbeitung vorzugaukeln.

Und warum soll man die durch ein Nassi-Shneiderman Diagrammen 
beschriebene Ablaufsteuerung eines Programms nicht direkt in 
Bearbeitungklötzchen gießen und um den Datenfluss ergänzen.

Wer als einziges mit einem Hammer als Werkzeug umgehen kann, wird in 
jedem Problem einen Nagel sehen.

Nö das ist nicht ATMEL, kannste schon mit ner whois abfrage klären.
(irgendein norwegisches Ingenieurbüro)

Winfried J. schrieb:
> dafür spricht neben der URL auch der Seitenaufbau, das Logo und die
> "device list" und mit dieser ist das Projekt bei mir durch Einarbeitung
> lohnt nicht, da ich nicht jedem Individualisten nach schwimmen will
> dafür bin ich selbst zu viel Individualist. wäre sie sage ich mal halb
> so lang wie des AVR-Studios
> so wäre es schon mal einen blick wert.

Kannst du das bitte noch mal in ein paar sinnvolle Sätze fassen?

W.S. schrieb:
> passiert NICHTS parallel und getrennt voneinander, sondern immer alles
> schön nacheinander. Genau DESHALB ist eine grafische Programmierung hier
> fehl am Platze. Man tut so, als wäre so ein Kästchen eine Baugruppe, die
> man nur zu verdrahten hat, aber in Wirklichkeit ...

... muß die Wirklichkeit nicht wirklich interessieren! Grafisch und 
pseudoparallel wird die Programmierung auf eine höhere, abstraktere, 
funktionellere Stufe gehoben. Der Kleinkram und immer mehr Intelligenz 
steckt in den Bausteinen und muß in Detail nicht bekannt sein.

> Wahrscheinlich muß man es so sehen, daß es ein paar grundlegende
> Unterschiede zwischen Elektrotechnikern und Programmierern gibt.

Wahrscheinlich muß man es so sehen, daß es ein paar grundlegende 
Unterschiede zwischen festgelegten Profis auf eingefahrenen Gleisen und 
Bastlern auf der Suche nach neuen, einfacheren, besseren Lösungen gibt.

>Das reißt einen nicht
>vom Hocker. Das Wow-Erlebnis konnte mir noch keiner zeigen.

http://sine.ni.com/cs/app/doc/p/id/cs-11145

>Da gibt es bspw. Schleifen,
>Case-Konstrukte, Arrays, selbstdefinierte Datenstrukturen usw., also
>vieles von dem, was eine "richtigen" Programmiersprache auszeichnet.

LabView ist eine richtige Programmiersprache.

>Damit könnte man sicher auch mein Linearisierungsbeispiel von oben
>realisieren

Das ist jetzt aber nicht Dein Ernst? LabView wurde ursprünglich zur 
Messwerterfassung komplizierter Laborelektronik entwickelt, da ist die 
Linearisierung eine der grundlegendsten Aufgaben. Dafür gibt es zig 
vorgefertigte VIs:

http://www.ni.com/white-paper/14573/en/

Schonmal auf die Seite von appinventors.com geschaut? Dort setzt man zB 
die einzelnen If-The-Else's als Puzzle Teile zusammen.
So kann man sich Android-Apps basteln. Funktioniert wunderbar. 
Komplizierte Sachen, wie Auswertung des Beschleunigungssensors 
beispielsweise, sind als "VI" (um in Labview zu reden) integriert.
Geht also schon - dem Anwendungsgebiet angepasst eben.
Lego Mindstorms verwendet wohl die gleiche Oberfläche.

Axel R. schrieb:
> Lego Mindstorms verwendet wohl die gleiche Oberfläche.

Lego Mindstroms ist Labview
https://www.ni.com/academic/mindstorms/d/

JA - jetzt geht das auch für Lego Mindstorms.
Das war mal anders! BLOXX hieß das früher und wird es sicher heute noch 
geben. ich habe das Lego Zeuchs mal verkauft. Da war NIE eine LabView 
Installation mit dabei :)

Ach du meine Güte! Die Diskussion ist ja ausgeartet ;-)

Dann werfe ich doch mal MATLAB Simulink in den Ring. :D

Mit Simulink kann man Arduino programmieren. Der Compiler im Hintergrund 
ist die winavr Toolchain mit einem für Arduino angepassten 
make-Template. Theoretisch sollte man also auch andere AVRs leicht damit 
programmieren können.

Ja, Simulink und LabView sind hoch professionelle, realtiv teuere 
Softwarepakete aus dem professionellen Umfeld, die zeigen, was 
graphische Programmiersprachen zu leisten vermögen.

Eben. Mit Matlab/Simulink werden hochkomplexe Algorithmen erstellt, zB 
Bildverarbeitung oder Regelungen wie Einparkassistenten. Die daraus 
generierte Software wird in Sicherheitskritischen Systemen wie 
Fahrzeugen eingesetzt.

Wer also behauptet, mit graphischer Programmierung könnte man nur kleine 
Basteleien umsetzen hat eigentlich keine Ahnung von der Realität.

Zugegeben, die Lizenzen für diese Tools kosten 5-stellig und sind damit 
wohl unerreichbar. Aber diese Diskussion, in der auch hochangesehene 
Forenmitglieder und Mods den Nutzen solcher Sprachen verneinen zeigt 
doch den Tellerrand dieses Forums auf...

PS: mir macht "richtigen " Code hacken mehr Spaß ;-)

bal schrieb:
> Eben. Mit Matlab/Simulink werden hochkomplexe Algorithmen erstellt
Nur - werden diese Algorithmen komplett vom User eingegeben, oder hat NI 
die (komponentenweise) schon fertig gemacht und man muss die nur noch 
konfigurieren/kombinieren? Letzteres wäre in textuellen Sprachen 
natürlich nicht mehr Aufwand, wenn man genauso fertige Komponenten hat. 
Man darf halt nich die Sprache/Arbeitsweise mit den verfügbaren 
Libraries gleichsetzen, wenn man einen prinzipiellen/grundsätzlichen 
Vergleich machen will.

Dr. Sommer schrieb:
> Nur - werden diese Algorithmen komplett vom User eingegeben, oder hat NI
> die (komponentenweise) schon fertig gemacht und man muss die nur noch
> konfigurieren/kombinieren?

Beides. Du kannst vorgegebene Bibliotheken verwenden, die über Eingänge 
konfiguriert werden und nicht als "Quellcode" einsehbar sind oder auch 
eigene aus Daten und Strukturelementen zusammenbauen.

Mike schrieb:
> Beides. Du kannst...
Ja, aber werden o.g. "hochkomplexe Algorithmen" komplett von Hand 
aufgebaut, und ist das dann wirklich weniger Arbeit als in textuellen 
Sprachen?

Genau, wobei aber die mitgelieferten Blöcke schon sehr Umfangreich sind, 
vor allem in Sachen Numerik.
Das Beispiel das oben mal kam (Interpolation mit Stützpunkten) lässt 
sich mit Boardmitteln lösen.Ist auch nur ein Block, soweit ich weiß.

Natürlich muss die unterste Schicht, das OS, die Basissoftware weiterhin 
per Hand programmiert werden. Aber wie immer: das richtige Werkzeug fürs 
jeweilige Problem.

Für den Applikationsentwickler ist es eine Erleichterung, wenn er sich 
aufs Problem konzentrieren kann und der Codegenerator sich mit Dingen 
wie Pufferüberlaufen etc. beschäftigt.

Dr. Sommer schrieb:
> Mike schrieb:
> Beides. Du kannst...
>
> Ja, aber werden o.g. "hochkomplexe Algorithmen" komplett von Hand
> aufgebaut, und ist das dann wirklich weniger Arbeit als in textuellen
> Sprachen?

Definitiv. Ich durfte mal eine Regelung aus einem Simulink Chart in 
C-Code überführen, weil kein Codegenerator zur Verfügung stand. Die 
Logik stand ja schon, trotzdem war sehr langsames, sorgfältiges Arbeiten 
notwendig.
Es wurde Festpunkt Arithmetik benutzt und nach jedem Rechenschritt 
musste die Auflösung/Wertebereich angepasst werden und nachgerechnet 
werden ob ja nichts überlaufen kann. Wenn notwendig mussten 
Limitierungen eingebaut werden.
Es wäre um einiges günstiger und schneller gewesen, hätten wir das 
Modell "kompilieren" können.

Mr. Wu schrieb:
> Und warum soll man die durch ein Nassi-Shneiderman Diagrammen
> beschriebene Ablaufsteuerung eines Programms nicht direkt in
> Bearbeitungklötzchen gießen und um den Datenfluss ergänzen.

Moby schrieb:
> ... muß die Wirklichkeit nicht wirklich interessieren! Grafisch und
> pseudoparallel wird die Programmierung auf eine höhere, abstraktere,
> funktionellere Stufe gehoben. Der Kleinkram und immer mehr Intelligenz
> steckt in den Bausteinen und muß in Detail nicht bekannt sein.

Ihr beide seht den Wald vor Bäumen nicht, obwohl ihr es in meinem 
Beitrag hättet LESEN können.

Den Grund für eure Blindheit sehe ich: es ist prozedurales Denken. Also 
Denken in Ablaufdiagrammen. Aber ein Ablaufdiagramm ist eben KEIN 
Schaltplan, es sieht nur auf den allerersten Blick so aus, weil es 
Kästchen und Striche dazwischen enthält.

Wie gesagt, es gibt nen grundlegenden Unterschied zwischen Schaltungen, 
wo verschiedene Bauteile parallel nebeneinander existieren und echt 
gleichzeitig ihre Funktion erfüllen und Rechnern, die Maschinenbefehle 
sequentiell abarbeiten. Sowas muß doch irgendwann mal reingehen in die 
Köpfe, oder braucht es dazu nen größeren Holzhammer?

Und nochwas zu Moby: Dein "grafisch und pseudoparallel" zu Ende gedacht 
bedeutet eine Abstraktion, die man in die Worte zusammenfassen kann: 
"Mach daß es geht, ich will kein Detail wissen." Das ist die Position 
des Benutzers, z.B. deiner Tochter, wenn sie über's Display ihres 
Telefons wischt. Aber es ist ja dummerweise gerade der Job des 
Programmierers, es eben so zu machen, daß es geht und da muß es 
zwangsweise immer irgendwo einen geben, der die eigentliche Arbeit 
macht.

W.S.

bal schrieb:
> Definitiv. Ich durfte mal eine Regelung aus einem Simulink Chart in
> C-Code überführen
Das ist aber mehr ein Problem von C an sich und weniger von textuellen 
Sprachen allgemein, denn C ist eine ziemlich ausdrucksschwache Sprache 
in der man alles von Hand machen muss. Die Festkommafummelei hätte man 
zB in C++ schon gut abstrahieren & automatisieren können unter 
Verwendung einer entsprechenden Library.

Das stimmt.
Aber im Automotive-Umfeld, wo ich auch das Beispiel angesiedelt habe hat 
sich C++ (leider) nicht durchgesetzt.

Da gibts nur plain C und bunte Blöcke, dazwischen kommt ned viel ;-)

Die Modelle kommen halt auch großteils von Physikern, Maschinenbauern 
oder Fahrzeugtechnikerin.
Aufgabe des Programmieres ist die Basissoftware.
Und, später dann, den aus dem Modell generierten Code mit der 
Basissoftware zu verheiraten.

Übrigens gibts das für PICs schon seit Ewigkeiten:
http://www.parsicitalia.it/visual-parsic-compiler-fuer-picmicro.html

(früher parsic.de siehe:
Beitrag "parsic.de down oder nur Relaunch?"
 )

Ich hab um die Jahrtausendwende oder so mal damit angefangen - lief 
eigentlich ziemlich gut und war für jemanden der vorher viel TTL Gräber 
gebaut hatte recht intuitiv.
Aber C war dann irgendwann doch schöner ;-)

W.S. schrieb:
> Wie gesagt, es gibt nen grundlegenden Unterschied zwischen Schaltungen,
> wo verschiedene Bauteile parallel nebeneinander existieren und echt
> gleichzeitig ihre Funktion erfüllen und Rechnern, die Maschinenbefehle
> sequentiell abarbeiten. Sowas muß doch irgendwann mal reingehen in die
> Köpfe, oder braucht es dazu nen größeren Holzhammer?

Anscheinend hast du noch nie mit Labview gearbeitet.
Mit der sequentielle Abarbeitung der verschiedenen Zweige durch den 
Prozessor kommst du als Programmier der Algorithmen gar nicht mehr in 
Kontakt. Aus Sicht des Programmablaufes läuft der Code in den Blöcken 
quasi-parallel ab. Sobald die Eingangswerte eines Blocks zur Verfügung 
stehen, d.h. von im Datenfluss weiter vorne stehenden Blöcken 
bereitgestellt wurden, wird der Block ausgeführt und liefert wiederum 
sein Ergebnis ab. Das ist vergleichbar mit einem in einer prozeduralen 
Sprache geschriebenen Programm, bei dem in einer schnell durchlaufenden 
Hauptschleife auf Ereignisse (Zustandsänderungen im Programmen) reagiert 
wird, also ein eventgesteuerter Ablauf. Synchronisationsmechanismen 
müssen dabei dafür sorgen, dass es durch unterschiedliche 
Abarbeitungsreihenfolgen nicht zu "Unfällen" kommt (Race-Condition).

bal schrieb:
> Das stimmt.
> Aber im Automotive-Umfeld, wo ich auch das Beispiel angesiedelt habe hat
> sich C++ (leider) nicht durchgesetzt.
Wenn schon textuell dann immer C? Dann ist man natürlich selber 
schuld...

Also falls es jemand interessiert, das Teil soll laut Entwickler am 
15.05. erscheinen und ca. $100 kosten.

W.S. schrieb:
> "Mach daß es geht, ich will kein Detail wissen." Das ist die Position
> des Benutzers, z.B. deiner Tochter, wenn sie über's Display ihres
> Telefons wischt. Aber es ist ja dummerweise gerade der Job des
> Programmierers,

Der programmiertechnische Fortschritt läßt beide Positionen eben näher 
aneinanderrücken ;-)

Harry schrieb:
> Also falls es jemand interessiert,

Ja, z.B. mich. Danke für die Info.

Yalu X. schrieb:
> Das war jetzt aber ein Eigentor

Ach nö.

Deine Idee mit den höheren Ebenen ist mir durchaus bewußt, deshalb hab 
ich ja das Extrembeispiel mit Töchting, die über's Display rubbelt, 
gebracht. Der Knackpunkt ist doch, daß das, was du da als "grafisches 
Programmieren" bezeichnest, eigentlich kein Programmieren, sondern 
quasi nur "grafisches Benutzen" ist. Die eigentliche Programmierleistung 
steckt in den ominösen Kästchen und muß zuvor von jemand anderem 
geleistet worden sein. Aber diese Kästchen können nicht wirklich 
universell sein, sondern sie sind immerzu nur eine Vorgabe eines 
fertigen Programms, geschrieben von jemand anderem für die Zwecke, die 
dieser sich hat vorstellen können.

Verstehst du mich?

Ich hätte da ein Beispiel: Vor Jahren hat mir einer auf der Embedded so 
ein Evalkit für die PSOC1 Bausteine in die Hand gedrückt. O-Ton: "Damit 
können Sie sich ihre eigene Logik ganz einfach wie mit nem Schematics 
kreieren". Beim Ausprobieren wollte ich auch genau DAS. Aber nach einer 
Reihe vergeblicher Versuche hab ich's dann aufgegeben und meinen Kram 
mit nem simplen CPLD von Xilinx gemacht. Später hat es sich dann 
herausgestellt, daß man als "grafischer PSOC1-Programmierer" eben NICHT 
seine eigene Logik dort plazieren kann, sondern mehr oder weniger nur 
das an 'Kästchen' benutzen kann, was ohnehin schon im Repertoire ist.

Man ist bei sowas also nur "grafischer Benutzer" - ohne die Freiheit, 
etwas anderes als vorgegeben benutzen zu können.

Bei LabView scheint das ziemlich ähnlich zu sein: man kann dort (soweit 
ich mir das mal hab zeigen lassen - ich selbst benutze LabView nicht) 
eben auch nur das benutzen, was schon da ist - und wenn man etwas neues, 
anderes haben will, muß man von der grafischen Programmierung 
heruntersteigen und sich sein neues 'Kästchen' in einer althergebrachten 
Programmiersprache schreiben.

Das ist eben die Einschränkung solcher "grafischen 
Zusammenstellungsmittel": Daß die Methode (hier eben grafisch) der 
verwendeten Hardware-Sache eben nicht wirklich angemessen ist, sondern 
mir eher recht aufgepfropft erscheint. Der tiefere Grund liegt in der 
Funktionsweise der Hardware: parallel oder eben sequentiell.

W.S.

W.S. schrieb:
> Daß die Methode (hier eben grafisch) der
> verwendeten Hardware-Sache eben nicht wirklich angemessen ist,

Die einzelnen Peripherie-Units wie UART, SPI usw. sind beim AVR 
hinreichend einfach gestrickt um das grafisch kapseln zu können. Also 
keine wirkliche Einschränkung. Aber nun schaun mer mal. Werds mal 
ausprobieren.

W.S. schrieb:
> kein Programmieren, sondern
> quasi nur "grafisches Benutzen"

Das eine auf einem niedrigeren Level, das andere auf einem höheren.
"Benutzen" und "Programmieren" trifft auf beides zu ;-)

Und das hier, FLOWCODE, gibt es schon seit vielen Jahren als graphische 
Programmieroberfläche für ATMega, PIC und sogar Arm.
Dafür scheint es ja einen Markt zu geben, sonst wären die schon lange 
wieder von der Bildfläche verschwunden.

http://www.matrixmultimedia.com/flowcode.php

http://www.youtube.com/watch?v=f2vuTTy2Iis

Arbeitet einer von euch damit und kann was dazu sagen?

>Bei LabView scheint das ziemlich ähnlich zu sein: man kann dort (soweit
>ich mir das mal hab zeigen lassen - ich selbst benutze LabView nicht)
>eben auch nur das benutzen, was schon da ist - und wenn man etwas neues,
>anderes haben will, muß man von der grafischen Programmierung
>heruntersteigen und sich sein neues 'Kästchen' in einer althergebrachten
>Programmiersprache schreiben.

Das stimmt nicht. Man kann alles malen. Wie schon weiter oben erwähnt 
hat LabView alle Konstrukte einer zeilenorientierten Programmiersprache 
( *,+,- ... and, or ... loops ... usw ). Ich habe mal vor längere Zeit 
ein "4 gewinnt Spiel" damit gemacht. Allerdings muss man sagen, dass 
manche Probleme besser Zeilenorientiert zu beschreiben sind. Dann kann 
man z.B. Matlab nehmen, was sich sehr gut in LabView integrieren lässt.

markus schrieb:
>>und wenn man etwas neues...
>>... muß man ...
>>... in einer althergebrachten
>>Programmiersprache schreiben.
>
> Das stimmt nicht. Man kann alles malen.

markus schrieb:
> hat LabView alle Konstrukte einer zeilenorientierten Programmiersprache

Ja, eben. Du sagst zwar, "das stimmt nicht", fügst aber im gleichen 
Atemzug hinzu, daß man für sowas eben dann doch wieder eine Art 
Skriptsprache benutzen muß, um so ein Kästchen mit innerem Leben zu 
befüllen. genau DAS sagte ich auch.

Moby schrieb:
> Die einzelnen Peripherie-Units wie UART, SPI usw. sind beim AVR
> hinreichend einfach gestrickt um das grafisch kapseln zu können. Also
> keine wirkliche Einschränkung.

Oh doch, ja DOCH. Denz nur mal dran, daß ein Programm ja nicht nur aus 
fertigen Treibern für Standardperipherie besteht. Irgendwo muß ja auch 
der eigentliche Funktionsanteil sein, der die Funktionsweise des Gerätes 
bestimmt, wo der betreffende µC drin werkelt - also die eigentliche 
Applikation. Und die ist wohl in jedem Falle so sehr individuell, daß es 
dafür keinen vorgefertigten Block gibt. Also wie machst du das dann 
grafisch, wenn du eine ganz spezielle Funktion deines zu entwickelnden 
Gerätes programmieren willst? Ein fertiges Kästchen dafür gibt es nicht, 
nur solche für den UART und SPI. Da mußt du zwangsweise so wie oben der 
Markus bei Labview für den Inhalt eines neuen Kästchens zu einer 
Programmiersprache greifen, von Assembler an aufwärts.

Ich bin ja dem Verwenden von sowas wie Schematics überhaupt nicht 
abgeneigt, im Gegenteil. Aber ich sehe doch, daß sowas für Chips, die 
eigentlich ein µC sind, nicht wirklich was Passendes ist und erwarte bei 
sowas eher eine Krampf-Lösung - oder eben etwas, das stramm in Richtung 
Ablaufsteuerung (Kugelschaltwerk auf elektronisch) geht.

W.S.

W.S. schrieb:
> und wenn man etwas neues, anderes haben will, muß man von der grafischen
> Programmierung heruntersteigen und sich sein neues 'Kästchen' in einer
> althergebrachten Programmiersprache schreiben.

So tief willst du gar nicht runter.
Alles was sich aus Kontrollstrukturen (if, while, case, for, ...), 
Operatoren, Variablenstrukturierung (Cluster), Typumwandlungen usw. 
zusammenbauen läßt, kann per "Kästchenverknoten" zu neuen, 
selbstdefinierten Kästchen werden. Selbst vorhandene DLLs kannst du aus 
"Kästchen" heraus nutzen - das wäre dann eine Schnittstelle zu anderen 
Sprachen.

W.S. schrieb:
> erwarte bei
> sowas eher eine Krampf-Lösung

Ich nicht. Für eine vorerst (noch un-)bestimmte Klasse von Millionen 
Anwendungen jedenfalls wirds grafisch ganz sicher einfacher. Aber: Es 
ist klar und wird hier doch nirgendwo in Abrede gestellt, daß die 
Möglichkeiten und die Feinkörnigkeit der Mittel zur Problemlösung bei 
den etablierten, ausgereiften, textorientierten Sprachen sicher noch von 
anderer Qualität sind. Doch ich erwarte, daß ihr Einsatz zukünftig 
zunehmend nur für

W.S. schrieb:
> eine ganz spezielle Funktion

benötigt wird! Also W.S., nicht alles in einen Topf werfen, immer schön 
differenzieren und nicht nur schwarzweiß zwischen perfekt/nutzlos 
unterscheiden ;-)

Als Programmierer, der in der glücklichen Lage ist für jede Aufgabe frei 
aus den Sprachen LabVIEW, Simulink oder C auswählen zu können, kann ich 
nur sagen: Jedes der genannten Werkzeuge hat absolut seine 
Daseinsberechtigung. Die Kunst eines guten Entwickler ist es, das 
jeweils am besten geeignete Werkzeug für eine Aufgabe auszuwählen.
Grob unterteilen ich die Tools z.B. so:
PC-Software (meist kleine Applikationen für Test, Logging und 
Steuerung): LabVIEW
Embedded: Für Statemachines, Strategien und Regelungen -> 
Matlab\Simulink mit Stateflow
Embedded: Für die Bios-Software, Lowlevel Treiber, Protokolle -> C

Damit hat man so ziemlich alles abgedeckt.

 Im Endeffekt wird man sich aber immer eher für das vertrauter Werkzeug 
entscheiden, auch wenns vielleicht nicht das effizienteste für die 
momentane Aufgabenstellung ist ;-) Daher kommen auch ein Großteil der 
hier zu beobachtenden Diskussionen. Keiner will "sein" Tool schlecht 
dastehen lassen.

W.S. (Gast)
>Ja, eben. Du sagst zwar, "das stimmt nicht", fügst aber im gleichen
>Atemzug hinzu, daß man für sowas eben dann doch wieder eine Art
>Skriptsprache benutzen muß, um so ein Kästchen mit innerem Leben zu
>befüllen.

> .... benutzen muß ....

Nein, ich habe geschrieben "kann", nicht "muß". Man kann alles malen.

 peterguy (Gast)
> Die Kunst eines guten Entwickler ist es, das
>jeweils am besten geeignete Werkzeug für eine Aufgabe auszuwählen.
>Daher kommen auch ein Großteil der
>hier zu beobachtenden Diskussionen. Keiner will "sein" Tool schlecht
>dastehen lassen.

Genau so sehe und mache ich es auch.

>Daher kommen auch ein Großteil der
>hier zu beobachtenden Diskussionen. Keiner will "sein" Tool schlecht
>dastehen lassen.
 peterguy (Gast)
Ich glaube es es eher so, dass Entwickler ab einem bestimmten Alter 
"lernresistent" werden. Da interessiert man sich nicht für Neues und 
Anderes, man weiß ja wie es geht.

Klaus I. schrieb:
>> noch gar nicht herunterladbar. Da kann doch noch niemand Erfahrungen
>> damit
>> gesammelt haben.
>
> Als ob das die üblichen Verdächtigen(tm) beeindrucken würde. ;o)

Grundsätzliches lässt sich auch vorab klären :-)
Ansonsten liefert die Homepage ja schon einige Ansatzpunkte was alles 
möglich wird. Andere übliche Verdächtige werden trotzdem nur im Fokus 
haben, was alles NICHT geht...

W.S. schrieb:
> Irgendwo muß ja auch
> der eigentliche Funktionsanteil sein, der die Funktionsweise des Gerätes
> bestimmt, wo der betreffende µC drin werkelt - also die eigentliche
> Applikation. Und die ist wohl in jedem Falle so sehr individuell, daß es
> dafür keinen vorgefertigten Block gibt. Also wie machst du das dann
> grafisch, wenn du eine ganz spezielle Funktion deines zu entwickelnden
> Gerätes programmieren willst?

Na, wie mache ich das wohl in z.B. C, wenn ich etwas brauche, was die 
Sprache nicht schon fertig zur Verfügung stellt (z.B. 
Sättigungsarithmetik)? Ich umschreibe es mit den gegebenen Mitteln der 
Sprache, was natürlich etwas umständlich aussieht. Und dann kapsele ich 
es in eine Funktionsdefinition, damit einem die Umständlichkeit nicht 
bei jeder Verwendung den Blick aufs wesentliche verstellt.

Viel Erfahrung mit grafischer Programmierung habe ich ja nicht, aber 
soweit ich weiß, gibt es da denselben Trick: man kann eigene Kästchen 
definieren, deren Innenschaltung dann der Übersicht halber meist 
verborgen wird.

Und wenn man partout meint, mit den Mitteln der Sprache nicht 
auszukommen (oder nicht effizient genug zu sein), weicht man auch in C 
auf die nächstniedrigere Sprache aus und benutzt inline-assembler (z.B. 
wenn die CPU schon Befehle für Sättigungsrithmetik hat).

Klar kann man sich jetzt hinstellen und sagen, diese 
Kästchenzusammenklicken ist kein Programmieren, weil die eigentliche 
Funktion der Kästchen von irgendeinem "echten" Programmierer in einer 
"echten" Programmiersprache definiert wurde. Aber mit dem gleichen Recht 
kann mir der Compilerbauer vorwerfen, daß ich in C nicht wirklich 
programmiere, schließlich hänge ich ja nur compilerinterne Macros und 
Aufrufe der Laufzeitbibliothek aneinander, die ein "echter" 
Programmierer vorher in Assembler geschrieben hat.

"Scheduled release May 1, 2014!"

Von einer ambitionierten Firma sollte man bei Verspätung doch wenigstens 
eine Aktualisierung des lange angekündigten, mit Ausrufezeichen 
versehenen Releasedatums erwarten können !? Ein "Coming soon" wär sicher 
schlauer gewesen... Schlechtes Zeichen.

Nur keine Eile.
Ich verfolge die Sache seit 2010.

Wir können noch Wetten auf den nächsten Termin abschließen.

Ich sag mal 1.6.2014 ;-)

hp-freund schrieb:
> Nur keine Eile.
> Ich verfolge die Sache seit 2010.

Seit 2010??? Na prima.
Bei der Konkurrenz (Avrfreaks) war zu lesen, daß man auf Anforderung ne 
Betaversion zum Testen bekommen kann.

hp-freund schrieb:
> Ich sag mal 1.6.2014 ;-)

Ein Lebenszeichen- der Postmaster reagiert auf Mails! Und hat daraufhin 
auf Ende Mai korrigiert. Also gut getroffen mit dem 1.6. ;-)

Ach ja, und eine Antwortmail gabs auch noch. Das Projekt sei "leicht 
verspätet" und definitiv kein Fake. Denn immerhin steht schon der Preis 
fest: 100 Dollar via Paypal...

Kay Pohl schrieb:
> "End of May" :-)
>
> Dann wirds "End of June" und dann "End of 214".

Na ja, soll doch auch wirklich ausgereift sein wenns auf den Markt 
kommt. Immerhin, der Preis ist schon "fertig"!

ich hätte mich nicht gewundert, wenn man per Western Union bezahlen 
müsste... ;)

Es tut sich was. Die "Introduction offer, only 99 USD for a year's 
license with free updates !" führt allerdings aktuell nur zu einer 
Zahlung von 8 Cent an besagtes norwegisches Ingenierbüro, ohne weitere 
Gegenleistung...

Kostenlose Testversion? Fehlanzeige!

Moby schrieb:
> only 99 USD for a year's license

Das wars dann wohl, endgültig!

Alles in allem ein leider bislang wenig professioneller und 
überzeugender  Auftritt. Hinter Seite und Programm steht ein gewisser 
Mike Wahl.

Das Einzige was hier konstant bleibt ist die Veränderung- ãh 
Verschiebung. Neuer Termin: 7.Juni

Eigentlich eine ziemliche Frechheit was sich die leisten - und das dann 
auch noch für Geld. Bin ja Hobbyanwender...
Tut sich das dann eigentlich noch irgendeine Firma an, da Zeit zu 
investieren?

Wenn dann gehen wohl wieder mal die Bastler voran! Aber ohne eine 
kostenlose Testversion?

habe gelesen:

 ...... Scheduled release:   7. June  2014

Es wird spannend: Die aktuelle nächste Verschiebung beträgt nur noch 
ZWEI TAGE: Also jetzt bis zum 9.Juni warten...

Die nächste (verkappte) Verschiebung: Jetzt der 23.Juni für die 
vollständige Version- dann Pro Version genannt- für nun 149 Dollar. Eine 
Testversion ist nach wie vor nicht in Sicht. Indem gleich Geld für die 
Katze im Sack verlangt wird dürften sich wohl nur wenige Käufer finden- 
sprich ggf. noch unreife Software fällt vorerst nicht so ins Gewicht = 
nix anderes als eine weitere verkappte Verschiebung  ;-(

Martin Wende schrieb:
> Die machen jetz wohl einen auf BER.
> Immer verschieben und dann ganich aufmachen g

Schaut auch weiter so aus... Die erste "Standardversion" nun angeblich 
am 16.Juni.

Laut Webseite angeblich heute: Final release 17. June  2014

Habe spasseshalber mal auf den BuyNow Button geklickt: funktioniert 
nicht.
Demo Software gibt es auch nicht.
Irgendwie ist das eine groose Verarsche.

"sorry for all delays" - wie nett....

Trotzdem eine Frechheit. Nichtmal eine Demo... Aber in dem Fall muss man 
vermutlich die Katze im Sack kaufen - sonst würden die vermutlich 
nichtmal einen Cent verdienen...
Gibt's solche IDEs denn nicht schon ;-)

Klaus schrub:
>"AVRtools is now complete and ready to download"

Das ist ja mit Sicherheit eine ganz feine Sache, daß das jetzt
"ready to download" ist. Aber es kostet 99 Dollar, wobei man dann
die endgültige Version umsonst kriegt, wenn sie fertig ist.

Es wäre besser, wenn es eine eingeschränkte "Probierversion" gäbe,
um die Leute anzulocken, denn 99 Dollar sind ein Haufen Scheine....

MfG Paul

Yalu riet:
>Dann leg einfach noch einen Dollar Trinkgeld drauf, und schon hat sich
>die Sache auf einen einzigen Schein reduziert.

Arrgh! Grmmlgrmpf!
;-)

...aber: Wo Du Recht hast, hast Du Recht!

Vielleicht findet sich ja einer von den Spezialisten hier:
Beitrag "Was kostet Euer Hobby?"

und probiert es als Erster.

MfG Paul

Thank you all for your interest AVRtools!

We come with a trial version during the afternoon today.

If you order Standard Version before 1 July 2014, you get Pro version 
for
free when it becomes avaiable.

Regards

Avrtools

Magnar

.....and we will work continuously to enter more microcontrollers and 
features.

Especially in sensors, Servo solutions, motor controllers, 
accelerometer, robotics, network  etc.

Regards

Avrtools

Magnar

Jürgen S. schrieb:
> Also ist das neue graphische Tool
> - teuer weil kostenpflichtig ohne vorherige Testmöglichkeit

Für Studenten mögen 99 Euro viel sein, als Berufstätiger hingegen 
erscheint mir das schon fast geschenkt. Was kann man da falsch machen? 
Im schlimmsten Fall sind 100 Euro in den Sand gesetzt, gibt 
schlimmeres...

Jörg, bezahlt Atmel Entwicklungsingenieure so schlecht =) ?

Paul Baumann schrieb:
> Wir lassen jetzt die Arbeit ruh'n
> und freu'n und auf den Afternoon!

Auf welchen After freust du dich?

Kay Pohl schrieb:
> Moin,
>
> konnte schon jemand die Trial testen ? :-)
>
> Gruß Kay

WO zum runterladen?
Eine der vielen leeren Versprechungen?

Nur damits stimmt: $99 ;o) bei aktuellem Kurs 72,7086€

Harry

The free Trial version is now avaiable.

Goto www.avrtools.no and open Order/Trial Map

The trial version has limited features and are not able to program AVR 
microcontrollers!

Regards

Avrtools

Magnar

Ich kann es Downloaden, aber das Zip ist defekt.
Hier mal die Checksumme von dem, was ich erhalten habe:
f6f37243b07ecc024c89e3f2e4312f85 *setuptrial.zip

Es gib wohl Probleme beim download.
Ich musste es drei mal probieren, da fehlte immer was.
Dateigröße ist  17.359.617 Byte.

Wenn schon grafisch, dann Matlab + Simulink + TargetLink. Alles andere 
ist Kinderkram :D

Problem:
Die Kombi vom ersten Absatz kann sich kein normaler Mensch leisten :P

adenin schrieb:
> Dateigröße ist  17.359.617 Byte.

Keine Probleme mit dem Download. Die Zip hat 17.359.617 Bytes und die 
darin verpackte Setup.exe 17.914.036 Bytes

Interessantes Menü ;)

Jürgen S. schrieb:
> Was zum Beispiel einem Webmaster unter Stress passieren
> kann, wenn er eine Binärdatei per FTP im "ASCII MODE" hochlädt, statt im
> "BINARY MODE". Aber das würde ja irgendwie auch heißen, dass der
> Softwareanbieter seinen Download auf der Webseite freigegeben hat, ohne
> ihn selbst zu testen. Merkwürdig.

Dann ließe sich die Zip-Datei wohl kaum ordnungsgemäß entpacken ;-)

Das Fenster war bei mir beim ersten Start auch.

Jürgen S. schrieb:
> Die ZIP-Datei läßt sich öffnen, darin ist eine setup-Datei, die über den
> MSI-Installer die Installation ausführt.
>
> Das zeigt mir die Trialversion an (Bild anbei):

Schick das mal den AVRTools Leuten. Die antworten eigentlich recht 
schnell.

Windows 8.1 wehrt sich auch noch etwas, weil es den setup.exe für 
AVR-Tool (noch) nicht kennt.

Davon, dass Windows den Computer schützt, hör ich das erste mal. ;)

> Zumindest sollte aber der Software-Hersteller seine Kunden vorher auf
> die dann möglichen Warnmeldungen von Windows hinweisen.

Vor allem sollten sie nicht Downloads anbieten, die schon bereits beim 
Installieren Fehlermeldungen werfen oder komische unfertige Menüs 
anzeigen (siehe Screenshots). Das deutet darauf hin, dass hier 
irgendwelche frühen Alpha Schnappschüsse unters Volk gebracht werden 
sollen.

Warum sich treiben lassen? Nichts ist ärgerlicher als halbgare Software 
rauszuhauen, die schon zu beginn einen schlechten Eindruck hinterlässt.

TickiTacka hat fertig schrieb:
> Das deutet darauf hin, dass hier irgendwelche frühen Alpha Schnappschüsse
> unters Volk gebracht werden sollen.

Das sieht eher so aus, als ob sich die Entwicklung erstmal auf das 
Wesentliche, i.e. die Funktionalität im Programm konzentriert hat. Was 
stört mich ein überflüssiger Menüpunkt. Ok, ein paar warnende Worte zur 
Windows-Meckereien bei der Installation würden den User sicher 
beruhigen.

Der Simulator läuft sehr anständig und übersichtlich. In der 
Symbolleiste würde man sich zu Anfang vielleicht Tool-Tips wünschen.

Jetzt ist ja schon seit 2 Tagen die Demo online und man hört von euch 
nichts mehr?
Wer hat es denn schon getestet?

Danke Jürgen für den Bericht.
Da kann man das Tool wohl komplett vergessen.

Ich habe mal das oben von Albert angeführte Flowcode gestestet ( 
http://www.matrixtsl.com/flowcode.php ).
Das ist dann ja um Klssen besser und kann alles das was Du so probiert 
hast. Allerdings ist es auch teurer.

"......AVRtools is now complete and ready to download"

"Available from 01.07.2014"

Wer zu doof oder zu faul ist eine Programmiersprache zu lernen, der 
bekommt auch damit nichts hin. Meine Meinung.

...schrieb:
>Wer zu doof oder zu faul ist eine Programmiersprache zu lernen, der
>bekommt auch damit nichts hin. Meine Meinung.

Wer zu doof oder zu faul ist, sich einen Nicknamen auszudenken, der
aus mehr als 3 Punkten besteht, hat ganz andere Probleme. Meine Meinung.

Schwachkopf by Nature schrieb:
> Meine Meinung.

Wenn du sonst nichts zu melden hast ...

Hat jemand schon irgendwelche Strukturierungselemente gefunden, also so 
Dinge wie Schleifen mit Endbedingung (for, while, until), bedingt 
ausführbare Blöcke (if, select/case)?

Oder Möglichkeiten, um Blocke zu einem "Unterprogramm" zusammenzufassen, 
d.h. selbstdefinierte Blöcke, aufgebaut aus bestehenden Elementen?

Mir scheint, da ist noch einiges zu tun.

"We have some problems with receiving payment via Paypal from certain 
countries!"

Warum funktioniert das just bei Avrtools.no nicht?
Bislang nach 10 Stunden nach Kauf noch keine Reaktion.

Da hättest Du das Geld mal besser hier investiert:

http://www.matrixtsl.com/flowcode.php

Geld ist angekommen, Paypal trifft hier keine Schuld. Angeblich hat 
Avrtools den Lizenzkey sogleich gemailt (traf nie ein). Immerhin, nach 
Nachfrage kam spätnachts doch noch das Bezahlte. Man loggt sich mit den 
Daten ein und kann dann das Programm runterladen.

Das von Jörg Geschriebene kann ich auch bestätigen.
Wer keine Alternative dazu bietet, wird nicht als Lieferant in Betracht
gezogen.

@Cyblord

Schnapp-Atmung bekämpfen und Baldrian einnehmen....

cyblord ---- (cyblord) schrieb:

Johannes S. schrieb:

>> Es kommt prinzipiell einer, der meint, dass sich Paypal unmotiviert
>> Kohle einbehält, und danach ist jede weitere Diskussion sinnfrei.

> Ja dann kommen sie immer alle raus aus ihren Löchern. Die
> ewig-gestrigen, die Nörgel-Greise, die PayPal noch nie kapiert haben.

Na du musst es ja wissen. Hier Georg Schnurer's ganz persönliches 
Erlebnis.

http://www.heise.de/newsticker/meldung/Kommentar-PayPals-Drueckermanier-2242258.html

Mir reicht schon, dass ich neuerdings fortlaufend Mails über (m)ein 
angebliches gehaktes PayPalkonto erhalte, obwohl ich gar kein Paypal 
habe. Hätte ich diesen Dreck wäre ich vielleicht schon beim ersten mal 
auf die verbüffend echt wirkende Mail aus reiner Panik (manchen wird es 
so gehen) hereingefallen, die bei genauerem Hinsehen auf einen Provider 
in Frankreich verlinkt. So ignoriere ich den Dreck verschiebe ich 
ungeöffnet in den Webmail Mailpapierkorb.

cyblord ---- (cyblord) schwafelte:

> Du fällst wahrscheinlich auch auf den Enkeltrick rein,

Ich falle so leicht auf gar nichts rein. Schon gar nicht auf diesen 
Drecksdienst PayPal, den alle nur solange mögen, bis sie mal richtig 
Ärger mit dem Dienst hatten. Ist immer das selbe Lieb. Solange alles 
läuft machen alle mit. Erst wenn's nicht mehr läuft wachen die Leute auf 
und beginnen solche Vereine zu hinterfragen.

Im übrigen betreibe ich aktiv Onlinebanking seit Urzeiten, als noch 
Windows 9x auf dem Rechner installiert war und Jüngelchen wie du 
"Cyberlord" (was für ein kindhafter Nick) mir andauernd geplünderte 
Konten prophezeiten.

Deine Argumentation "wie immer ist an allem der Kunde schuld" ist nichts 
neues und die ewig gleiche Leier von Besserwissern und Dummschwätzern. 
Damit lässt sich nahezu ALLE Kriminaliät rechtfertigen, egal welcher 
Einbruch, immer ist das Opfer "der Trottel", denn er hat sich halt nicht 
ausreichend geschützt. Das der Gesetzgeber (zum Glück) das nicht so 
sieht wie du, merkt jeder wirklich schlaue, denn es gibt Gesetze gegen 
Onlinebetrug und Rufnummermaschen. Die Welt besteht nicht nur aus 
netzaffinen "Cyberlords", sondern auch noch aus normalen Leuten, mit 
denen man sich auch normal unterhalten kann. Die großfressigen, 
oberschlauen Nerds sind immer vom gleichen Schlag - ein unangenehmes 
Volk, das nicht in der Lage ist sich auch nur für 5 Minuten in andere 
hineinzuversetzen. Arme Haut!

To those of you who are concerned about payment by Paypal.

We use PayPal because it is safe and serious participant for payment 
over the internet.
We have, so far, have had no problem with Paypal. Customer Order and 
Payment arrive within seconds, and the customer gets their license key 
via email at the same time.

Ie, we have received reports that ONE customer did not receive their 
license on time.



We do not send out any email on behalf of Paypal.

Everyone should of course take their precautions when they pay over the 
net and look for the URL is starting with "HTTPS"

HTTPS creates a secure channel over an insecure network.

eg: https://www.paypal.com

Also, look for the green or gray padlock + "PayPal.inc (us)"

We take a little self-criticism:
Phone, address and organization number is not available on our website.
This should be done.

Regards
Magnar
AVRtools

PS:
Sorry language, but my German is too bad;)

Next round im Verschiebespielchen. Die angeblich schon ladbare, 
vollständige (=Professional) Version nun am 15.Juli. Alles andere als 
professional... ;-)

Magnar schrieb:
> We take a little self-criticism:
> Phone, address and organization number is not available on our website.
> This should be done.

No. Provide real information when your complete software will be 
available. Every week a new date thats an exhausting game ;-(