ATMEL stellt eine grafische Programmier-Oberfläche für 8 bit ATMega's vor, sogar der Arduino UNO wird explizit unterstützt. Release Date soll der 1. Mai sein. http://avrtools.no/Main.asp?page=2 Jetzt bin ich ja mal echt gespannt auf eure Reaktionen, weil die meisten hier ja solche Klicki-Oberflächen generell verteufeln. Aber jetzt kommt so ein Igit-Teil doch von ATMEL höchstselbt. Was meint ihr dazu?
LabView für die ATmega-Familie. Ich bin gespannt.
Das ist ja mal interessant - Danke für den Hinweis. Hm, Arduino Uno ist explizit aufgeführt bei den unterstützten Geräten. Ist das Atmels Weg um einsteigerfreundlicher zu werden? Was wird den das kosten?
AchWieLustig schrieb: > Aber jetzt kommt so ein Igit-Teil doch von ATMEL höchstselbt. > Was meint ihr dazu? Versteh ich nicht... Das hat doch mit Atmel nix zu tun.. nitraM
Wolfgang schrieb: > LabView für die ATmega-Familie. Ich bin gespannt. Wenn es genauso gut wird man man verdammt viel damit machen.
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
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...
Die Oberfläche erinnert auf jeden Fall stark an LOGO!Soft von Siemens... Ähnlichkeiten sind aber bestimmt rein zufällig ;-)
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 ;-)
Schon die grafische Programmierung der C-Control I damals war ja DER Durchbruch. Hat die überhaupt mal jemand produktiv eingesetzt? Jede auch halbwegs komplexe Aufgabe, zeigte sehr schnell (auch einem Anfänger) dass er hier mit BASIC besser dran war, als mit den Klötzchen. gruß cyblord
Wird die übliche nutzlose Pupsware sein. Allein der Schaltplan ist schon eine Zumutung: http://avrtools.no/Main.asp?page=7
Ich bin ja ansonsten ein Freund von Klötzchen schieben, deshalb habe ich ja auch das Tool Beitrag "Projekt: Virtuelle Instrumente an serielle Schnittstelle" als Freeware entwickelt. Aber ich habe mal einem ähnlichen Programm wie AVR-Tools, nämlich Flowcode ( http://www.matrixmultimedia.com/flowcode.php ) längere Tests gemacht. Ich bin nun kein professioneller uC Entwickler, aber da ist man in jeder Programmiersprache ( C, Luna, Bascom, was auch immer ) um Grössenordnungen schneller fertig. Die grafischen Oberflächen sehen ja schön aus, aber ehe man die ganzen Klötzchen konfiguriert hat, ist man mit den anderen Sprachen längst fertig. Für "Sonderfälle" muss man auch bei Flowcode in die Klötzchenkonfiguration reinen C-Code schreiben. Und die Sonderfälle hat man recht schnell, daran sieht man wie limitiert das Ganze eigentlich doch ist. Bei grösseren Programmen geht bei den Klötzchen die Übersicht schnell verloren. Fazit: Vergesst das Klötzchenschieben für die uC Entwicklung. Aber mit einer Freeware oder Demo Version der neuen AVR-Tools würde ich aus Neugier doch mal rumspielen :)
:
Bearbeitet durch User
cyblord ---- schrieb: > Schon die grafische Programmierung der C-Control I damals war ja > DER > Durchbruch. Hat die überhaupt mal jemand produktiv eingesetzt? Jede auch > halbwegs komplexe Aufgabe, zeigte sehr schnell (auch einem Anfänger) > dass er hier mit BASIC besser dran war, als mit den Klötzchen. > > gruß cyblord Jede auch halbwegs komplexe Aufgabe, zeigte sehr schnell (auch einem Anfänger) dass er hier mit C besser dran war, als mit dem Krüppel-BASIC, was eigentlich nix außer IF und WHILE konnte. Von Strings, Arrays und ähnlichem ganz zu schweigen. Das Klötzchen auch vernünftig geht, zeigt ja z.B. GRC.
:
Bearbeitet durch User
Albert M. schrieb: > Die grafischen Oberflächen sehen ja > schön aus, aber ehe man die ganzen Klötzchen konfiguriert hat, ist man > mit den anderen Sprachen längst fertig. 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ß. Z.B. muß ich mir mühsam ne Mul-Box auswählen, vielleicht noch Formatanpassungs-Boxen und dann alles verdrahten. In der gleichen Zeit kann ich auch 1000-mal a=b*c; hinschreiben. Und lesbar auf Papier ausdrucken kann man sowas auch kaum. 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. Ob ich 1000 Zeilen schreibe oder 1000 Klötzchen verdrahten muß, das ist schon ein riesen Unterschied. Die ganzen Beispiele gehen nur selten über 10 Klötzchen hinaus.
Ich meine dazu: warum nicht? Soll jeder das Werkzeug nehmen mit dem er gut und gerne arbeitet.
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
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. Mag sein. Aber man hat nunmal lange nicht dieselben Möglichkeiten. Oder wieviel Systemsoftware ist in LabView geschrieben? Wieviele 3D-Shooter sind in LabView geschrieben? Entweder einfach und eingeschränkt oder kompliziert und dafür wird mehr möglich. Wer behauptet er hätte ein Tool welches in wenig Einarbeitsungszeit universelle Möglichkeiten bietet, der lügt. Das ist wie 20% Rendite bei Null-Risiko. So was gibts einfach nicht. Aber viele Anwender hätten sowas natürlich gerne und dann fängt man an, an sowas zu glauben. gruß cyblord
:
Bearbeitet durch User
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.
markus schrieb: >>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. Wo ist da der Widerspruch? Weil etwas groß ist, ist es noch lange nicht komplex und noch lange nict auf einem µC.
Wie würde man mit diesen Kästchen eine Linearisierung von Sensordaten bewerkstelligen, bei der die Linearisierungsfunktion stückweise linear in Form von Stützstellen vorgegeben ist? In einem C-Programm würde man das in folgenden Schritten programmieren: 1. Anlegen der Linearisierungsfunktion (Stützstellen-Array mit Initialisierung) 2. Suchen der zu dem Messwert benachbarten Stützstellen (Schleife) 3. Lineare Interpolation (Formel mit 6 Rechenoperationen) Schritt 1: So etwas wie Arrays scheint es bei den AVR-Tools nicht zu geben, ich finde aber auch keinen adäquaten Ersatz dafür. Schritt 2: Ich kann auf der Seite mit den Functions http://avrtools.no/Main.asp?page=3 nichts finden, womit man die Suche halbwegs elegant lösen könnte. Man kann natürlich für jede Stützstelle eine Vergleichsoperation verwenden. Die dabei enstehende Kaskade von Kästchen möchte ich aber bei mehr als 20 Stützstellen nicht von Hand zusammenklicken müssen ;-) Schritt 3: Die Formel für die lineare Interpolation lässt sich aus sechs Kästchen mit arithmetischen Operationen zusammensetzen. Allerdings wird danach kein Mensch, dem diese Formel geläufig ist, sie als solche wiederkennen. Das Diagramm dazu dürfte also recht groß und unübersichtlich werden, während der entsprechende C-Code gerade mal ca. 5 Zeilen lang ist. Wenn man später vielleicht noch ein paar Stützstellen hinzufügen möchte, schreibt man diese beim C-Programm einfach in den Array-Initialisierer. Bei den AVR-Tools fügt man stattdessen in dem ohnehin schon riesigen Diagramm noch weitere Kästchen hinzu, die jeweils einzeln parametriert werden müssen. Grausig. Und das ist jetzt kein an den Haaren herbeigezogenes Beispiel, sondern eine typische Aufgabe für einen Mikrocontroller. Vielleicht wird ja irgendwann so eine Linearisierungsfunktion als fertiger Block nachgereicht. Bis dahin werden einem aber sicher 100 andere Beispiele über den Weg laufen, die man ebenfalls nur äußerst umständlich realisiert bekommt. Diese grafische Datenflussprogrammierung ist für eine begrenzte Klasse von Anwendungen sicher ganz praktisch. Für allgemeine Problemstellungen taugt sie aber überhaupt nicht, da sie viel zu unflexibel ist.
cyblord ---- schrieb: > Mag sein. Aber man hat nunmal lange nicht dieselben Möglichkeiten. > Oder wieviel Systemsoftware ist in LabView geschrieben? Wieviele > 3D-Shooter sind in LabView geschrieben? Jaaaa, Systemsoftware und 3D-Shooter ist auch ganz klar das Anwendungsfeld für LabView. Naja Java taugt offensichtlich auch nix, hat ja noch niemand ein BIOS drin geschrieben. Kann ja gar nix sein.
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.
Marian B. schrieb: > cyblord ---- schrieb: >> Mag sein. Aber man hat nunmal lange nicht dieselben Möglichkeiten. >> Oder wieviel Systemsoftware ist in LabView geschrieben? Wieviele >> 3D-Shooter sind in LabView geschrieben? > > Jaaaa, Systemsoftware und 3D-Shooter ist auch ganz klar das > Anwendungsfeld für LabView. Genau darum ist es Unsinn, zu behaupten grafische Programmierung für Microcontroller ist gut, weil LabView viel einfacher zu lernen ist als C. Jetzt kapiert? Denk halt erstmal nach bevor du quatsch schreibst. Java ist ein gutes Stück abstrakter als C und hat mehr Sicherheitsgurte und ist für den Ablauf auf einer virtuellen Maschine konzipiert. Ja, darum schreibt man damit auch keine Systemsoftware, hat aber deutlich mehr Möglichkeiten als mit LabView. Was genau meine These Stützt: Je einfacher desto eingeschränkter, je komplexer desto universeller.
:
Bearbeitet durch User
cyblord ---- schrieb: > Marian B. schrieb: >> cyblord ---- schrieb: >>> Mag sein. Aber man hat nunmal lange nicht dieselben Möglichkeiten. >>> Oder wieviel Systemsoftware ist in LabView geschrieben? Wieviele >>> 3D-Shooter sind in LabView geschrieben? >> >> Jaaaa, Systemsoftware und 3D-Shooter ist auch ganz klar das >> Anwendungsfeld für LabView. > > Genau darum ist es Unsinn, zu behaupten grafische Programmierung für > Microcontroller ist gut, weil LabView viel einfacher zu lernen ist als > C. Jetzt kapiert? > Denk halt erstmal nach bevor du quatsch schreibst. Dein unsäglicher > bekloppter Kommentar zu Java ist sogar zum zititieren zu doof. Du musst > deine Dummheit ja nicht auch noch zur Schau stellen. Ich fürchte eher, dass du den Sinn von LabView und vergleichbaren Paketen nicht kennst. LabView ist bspw. nicht dazu da, LED-Dimmer zu programmieren...
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.
cyblord ---- schrieb: > Genau darum ist es Unsinn, zu behaupten grafische Programmierung für > Microcontroller ist gut, weil LabView viel einfacher zu lernen ist als > C. Jetzt kapiert? > Denk halt erstmal nach bevor du quatsch schreibst. Meine Fresse - Lieber Cyblord. Auch Du junger Padawan wirst Deinen Platz noch finden. Das wäre gar nicht mal schwer für Dich. Du müsstest nur unterlassen. Und zwar die gefühlten 9/10 Deiner Postings wo Du Dich danach immer besonders gut fühlst. Laß doch mal die Leute hier in aller Ruhe ihre Fehler machen. Echauffier Dich nicht über die ganzen Probleme im Bildungswesen, Du kannst es sowieso nicht ändern und die Studenten heute auch nicht. Du bist doch fachlich sehr gut aufgestellt, Du könntest Dein Wissen auch zum Guten nutzen!
Marian B. schrieb: > Ich fürchte eher, dass du den Sinn von LabView und vergleichbaren > Paketen nicht kennst. LabView ist bspw. nicht dazu da, LED-Dimmer zu > programmieren... 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. Das war nämlich nicht ich, wie du ja sicher gelesen hast. Was also, willst du jetzt eigentlich von mir?
...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.
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 :-)
cyblord ---- schrieb: > Marian B. schrieb: > >> Ich fürchte eher, dass du den Sinn von LabView und vergleichbaren >> Paketen nicht kennst. LabView ist bspw. nicht dazu da, LED-Dimmer zu >> programmieren... > > 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. Das war nämlich nicht > ich, wie du ja sicher gelesen hast. Was also, willst du jetzt eigentlich > von mir? Ich will gar nix von dir. Ich will dir auch nix böses ;) Im Internet redet man vor lauter Übertreibung, nicht erkannter (und nicht markierter) Ironie, ... öfter mal aneinander vorbei. Ist ja nicht schlimm...
markus schrieb: > Es ist aber ziemlich komplex, das kann ich nach 16 Jahren Vorentwicklung > sagen. Komplex ist relativ. Wird diese gesamte Komplexität in LabView umgesetzt, oder eventuell in Unterbaugruppen welchen natürlich nicht mit LabView programmiert sind? Ob nun tatsächlich eine ganzer riesiger Teststand mit LabView gesteuert wird, oder LabView hier lediglich ein paar Protokolle bedient und Daten abgreift, ist eher eine Frage der Sichtweise. > Deine Klugschweisere in diesem Forum geht mir übrigens schon > längere Zeit auf die Nerven. Du musst mich mit jemandem verwechseln den das interessiert.
Micromite schrieb: > jetzt wird's esoterisch ;-) Nein, einfach eine realistische Betrachtung. Man muss sich doch nur mal vorstellen wie es wäre, würde man tatsächlich versuchen einigermaßen Komplexe Programme (inkl. aller Low-Level Dinge, Busse, Protokolle usw.) grafisch zu programmieren. Genau das meinen hier die Leute doch, wenn sie sagen, das geht eben nicht. Und automatisierte Tests und Datenerfassung, sind doch das Paradebeispiel für LabView. Natürlich geht das damit. Aber nur auf einer hohen abstrakten Ebene und nicht für das ganze klein-klein für das man eben Microcontroller einsetzt.
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
Marian B. schrieb: > Ich fürchte eher, dass du den Sinn von LabView und vergleichbaren > Paketen nicht kennst. LabView ist bspw. nicht dazu da, LED-Dimmer zu > programmieren... Wieso nicht? Labview ist nur ein grafisches Gerüst, dass im Hintergrund auch nur C-Code erzeugt, und durch nen Compiler jagt, dabei aber noch äußerst komfortabel zu debuggen ist (obwohl es mit Sicherheit noch Spielraum für Verbesserungen gibt). Labview ist extrem leistungsstark. Es ist zwar primär auf die Entwicklung von Steuerungs- und Regelungsaufgaben zugeschnitten, aber mit dessen Hilfe lässt sich trotz allem simpelste Logik bauen. Labview verteufelt nur, wer entweder viel zu lange, oder noch nie damit gearbeitet hat. Aber wer behauptet, graphische Programmierung für µC sei schlecht, hat das Konzept grundlegend nicht verstanden. Denn ob eine graphische Programmierung funktioniert (oder nicht) hängt vom Grad der Abstrahierung und einer damit einhergehenden sinnvollen Umsetzung ab.
Noch so eine graphische Oberfläche, quasi ein LabView Lite, ist: http://www.dasylab.com/ Ich war vor über 20 Jahren Mit-Urheber dieser Software, die speziell für Data-Aquisition und einfachere Steuerungen gedacht ist.
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.
Abwarten. Das mit dem "Einfacher_soll_es_werden" hat meist so seine Tücken, oft wird's einfach erst mal schwierig. Und Menschen mit Erfahrung Scheuen das Neue. Dann kommen die Unbefangenen und legen los. Kurze Zeit später entscheidet sich ob die Alten sich das noch antun wollen oder die jungen es wieder aufgeben und zum bewährten zurückkehren. Diese Auslese bewirkt dann die technische Evolution ihr Darwinfinken. Namaste
Meine Güte! Man kann super drüber diskutieren wie man am besten im Topf Suppe kocht und im Ofen brot backt, und auch wie es andersherum geht, aber was bringt es sich zu lange darüber auszulassen dass man keine Suppe oder kein Brot mag...
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.
Wolfgang schrieb: > AchWieLustig schrieb: >> ATMEL stellt eine grafische Programmier-Oberfläche für 8 bit ATMega's >> vor > > Woraus schließt du, dass ATMEL dahinter steckt? hm ich gehe ziemlich sicher davon aus das nicht Atmel dahintersteckt sondern jemand der die "AVR Welle" auf seine eigene Art zu reiten versucht. 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. Bei meinem CVAVR beginnen mir nämlich die ersten Devices zu fehlen wie der 1284PPU Und das macht sich blöd
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.
Ein schrieb: > Kannst du das bitte noch mal in ein paar sinnvolle Sätze fassen? sorry ich reiche eine Tüte .te nach. zum selbst drüberstreuen
Finds schon sehr lustig, wie mancher Verbohrte (c-hater) meint, mit üblen Beschimpfungen kann er jemanden überzeugen, das Gegenteil ist natürlich der Fall. Zum Überzeugen taugen nur konkrete Argumente, aber niemals haltlose Polemik. Ich bin offen für neue Lösungen, aber ich habe nicht mehr die Zeit, jedes neue Pferd zu reiten, um damit in den Graben zu fallen. Ich laß das einfach jüngere machen. Und erst, wenn sie Erfolg haben, dann schaue ich mir das auch an. Ich hatte mir als junger Spund auch oft Eval-Samples bestellt, um dann damit auf die Nase zu fallen, weil die Platine fertig war, aber die ICs nicht geliefert werden konnten oder zuviele Bugs hatten. War z.B. echt kraß mit den AVRs, beworben waren 20MHz, geliefert werden konnten gerade mal schlappe 8MHz. Ich nehme nur noch ICs, die mindestens 2 Jahre am Markt sind und bin damit wesentlich erfolgreicher. Und genau das mache ich auch mit neuen Tools. Ich hab ja was, womit ich mich auskenne und effektiv arbeiten kann, also habe ich überhaupt keinen Druck. Labview benutzen auch einige bei uns, aber das sind einfach nur einfachste Datenlesedingsbumse, nichts komplexes. Das reißt einen nicht vom Hocker. Das Wow-Erlebnis konnte mir noch keiner zeigen.
:
Bearbeitet durch User
>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
Dirk P. schrieb: >>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 Sicher eine gute Entscheidung, weil die VME-Bus Module in der Tat sehr teuer sind.
Wobei man jetzt nicht LabView mit AVRtools gleichsetzen sollte. Wenn ich das richtig sehe, hat LabView ein Vielfaches an Funktionen, Datentypen und sonstigen Features auf Lager. Da gibt es bspw. Schleifen, Case-Konstrukte, Arrays, selbstdefinierte Datenstrukturen usw., also vieles von dem, was eine "richtigen" Programmiersprache auszeichnet. Damit könnte man sicher auch mein Linearisierungsbeispiel von oben realisieren (ob man es schneller hinbekommt als in C, ist eine andere Frage). Bei AVRtools hingegen scheinen viele wesentliche Dinge einfach zu fehlen, wobei man natürlich man erst urteilen sollte, wenn das Tool auf dem Markt ist und ein Handbuch oder zumindest ein detaillierteres Spec-Sheet vorliegt.
>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/
Dirk P. schrieb: >>Damit könnte man sicher auch mein Linearisierungsbeispiel von oben >>realisieren > > Das ist jetzt aber nicht Dein Ernst? Was, geht das etwa doch nicht? Dirk P. schrieb: > LabView wurde ursprünglich zur Messwerterfassung komplizierter > Laborelektronik entwickelt, da ist die Linearisierung eine der > grundlegendsten Aufgaben. Also geht es doch? Dann sind wir beide doch einer Meinung :) Trotzdem habe ich nach wie vor Bedenken, ob diese Linearisierung auch mit den AVRtools (um die sich dieser Thread ja dreht und auf die mein gestriger Post gemünzt war) problemlos möglich ist.
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: > Aber diese Diskussion, in der auch hochangesehene Forenmitglieder und > Mods den Nutzen solcher Sprachen verneinen zeigt doch den Tellerrand > dieses Forums auf... Da ich bisher der einzige and diesem Thread beteiligte Mod bin, fühle ich mich angesprochen :) Mein erster Beitrag vom 25.04.2014 18:01 bezog sich – bis auf den letzten Absatz – auf die AVRtools. Wenn du mir zeigen kannst, wie man das angegebene Beispiel mit den in den AVRtools verfügbaren Funktionen sinnvoll umsetzen kann, nehme ich diese Aussagen natürlich zurück. Yalu X. schrieb: > Diese grafische Datenflussprogrammierung ist für eine begrenzte Klasse > von Anwendungen sicher ganz praktisch. Für allgemeine Problemstellungen > taugt sie aber überhaupt nicht, da sie viel zu unflexibel ist. Diese Aussage bezog sich auf die grafische Datenflussprogrammierung im Allgemeinen, also auch auf LabView, und dazu stehe ich auch. Oder wie willst du mit vertretbarem Aufwand in LabView eine Textverarbeitung ähnlich Word, einen C-Compiler oder ein 3-D-Ballerspiel (die Liste ließe sich beliebig erweitern) entwickeln? Und in meinen beiden anderen Beiträgen, habe ich ja geschrieben, dass ich LabView wesentlich mehr zutraue als den AVRtools. Wo habe ich also den Nutzen von grafischen Sprachen verneint?
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...
W.S. schrieb: > 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. Das war jetzt aber ein Eigentor ;-) Du selbst scheinst derjenige zu sein, der in seiner prozeduralen – oder besser gesagt der imperativen – Denkweise gefangen ist. Deswegen kannst du dir nicht vorstellen, dass man einen Prozesor, der auf unterster Ebene imperativ programmiert wird (nämlich in seinem Maschinencode), auf höherer Abstraktionsebene durchaus auch nichtimperativ, also deklarativ programmiert werden kann. Auch grafische Datenflusssprachen wie LabView sind eine Form der deklarativen Programmierung. Natürlich ist die Umsetzung von Labview in Maschinencode schwieriger als dies bei C der Fall ist, aber das braucht dich nicht zu stören, da dir der Computer mit einem entsprechenden Compiler diese Arbeit abnimmt.
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.
Unterhaltet ihr Euch hier nicht über ungelegte Eier? Das Programm ist doch noch gar nicht herunterladbar. Da kann doch noch niemand Erfahrungen damit gesammelt haben. MfG Paul
Paul Baumann 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) Aber mal gucken, wenn es soweit ist. Anscheinend wurden die Release-Daten ja seit einiger Zeit immer nach später geschoben.
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.
Moin, ich glaub so langsam das das nur ein Fake ist :-) Auf der Homepage ist immer noch der 1.5. als Release. Wenn das seit 2010 schon so bei denen abläuft dann braucht man sich damit ja garnicht zu beschäftigen. Kaufen würde ich das dann erst recht nicht. Gruß Kay
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...
"End of May" :-) Dann wirds "End of June" und dann "End of 214".
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... ;)
Harald schrieb: > ich hätte mich nicht gewundert, wenn man per Western Union bezahlen > müsste... ;) Die Zahlungsweise "Russen-Inkasso" wird auch immer wieder gerne genommen...
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!
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 ;-(
Die machen jetz wohl einen auf BER. Immer verschieben und dann ganich aufmachen g
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....
"AVRtools is now complete and ready to download"
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
Bei "buy now" öffnet sich ein PayPal Fenster... Aber ist schon ne gewagte Sache...
Paul Baumann schrieb: > 99 Dollar sind ein Haufen Scheine.... Dann leg einfach noch einen Dollar Trinkgeld drauf, und schon hat sich die Sache auf einen einzigen Schein reduziert. Duck und wech ;-)
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
Paul Baumann schrieb: > Es wäre besser, wenn es eine eingeschränkte "Probierversion" gäbe, > um die Leute anzulocken, denn 99 Dollar sind ein Haufen Scheine.... Die einzigen Leute, die von sowas angelockt werden, sind doch welche, die bereits die kostenlose Arduino-Software ausprobiert und dann festgestellt haben: Ich kann absolut Null Zeilen Code in C++ schreiben. Wer soll so einen "Programmgenerator" sonst kaufen als Leute, denen selbst simpelste Programmierung schon zu kompliziert ist, so dass ihnen die schönsten Arduino-Komfortfunktionen und leistungsfähige Arduino-Libraries nicht helfen? Der Preis ist um 99 Dollar höher als für die kostenlose Arduino-Software. Die Anzahl der unterstützten Atmel 8-Bit Controller ist nur ein Bruchteil dessen, was die Arduino-Software unterstützt. Die Effizienz der Codegenerierung ist offenbar sowas von unterirdisch grausam, dass auf Atmega328-Controllern mit immerhin 2 KB RAM trotzdem keine SD-Karten unterstützt werden laut Liste auf http://avrtools.no/Main.asp?page=4 Mit der Arduino-Software ==> eine handvoll Zeilen Code und die SD-Karte läuft auch auf Atmega328 / Arduino UNO. Von LAN und Internet scheint das neue Tool auch noch nichts gehört zu haben: Im Arduino-Forum dreht sich eine Menge Fragen darum, dass Daten vom Controller über LAN, WLAN, Internet zwischen µController und einem PC oder Server hin- und her übertragen werden sollen. Mit der Arduino-Software==> eine handvoll Zeilen Code und das Ethernet-Shield am UNO läuft. Also ist das neue graphische Tool - teuer weil kostenpflichtig ohne vorherige Testmöglichkeit - unterstützt praktisch nur 3 verschiedene 8-Bit Controller - ineffizient - unterstützt nicht einmal SD-Karten und Ethernet auf Atmega328 - und hat darüber hinaus keine eifrige User-Community wie die Arduino-Software sie hat. Bei Hobbybastlern sehe ich einen schweren Stand für diesen Programmgenerator. Für gewerbliche Anwender dürften die 99 Bucks ein Klacks sein. Und wie ich inzwischen feststellen durfte: Es gibt auch reichlich Anwender aus dem gewerblich-industriellen Umfeld, die sich "inhouse" eigene µC-Gadgets entwickeln wollen. Und mangels tiefgreifendem Knowhow dann mit der Arduino-Software loslegen und oftmals scheitern, weil wirklich Null Programmierkenntnisse vorhanden sind. Wenn das Teil wirklich etwas kann, und es Leuten ohne Programmierkenntnisse ermöglicht, sich per Klick-and-Drag und Drag-and-Drop und ein paar Einstelldialogen eine Anwendung zusammenzubasteln, könnte es Leuten durchaus als Einstieg in die Entwicklung von µC-Programmen dienen. Solange, bis die Kenntnisse reichen, um mit der Arduino-Software weiterzumachen, weil man z.B. doch eine SD-Karte oder einen Ethernet-Controller auf einem Atmega328 nutzen möchte, und die mangelnde Effizienz und Funktionalität des Programmgenerators das nicht hergibt.
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
Mike schrub:
>We come with a trial version during the afternoon today.
Na, das ist doch in Ordnung.
Wir lassen jetzt die Arbeit ruh'n
und freu'n und auf den Afternoon!
;-)
MfG Paul
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...
Matthias schrieb: > Im schlimmsten Fall sind 100 Euro in den Sand gesetzt, gibt > schlimmeres... OK, ich würd sie auch nehmen, wenn du sie sowieso gerade übrig hast. :)
Jörg schribbelte:
>OK, ich würd sie auch nehmen, wenn du sie sowieso gerade übrig hast. :)
Volltreffer.
MfG Paul
Jörg, bezahlt Atmel Entwicklungsingenieure so schlecht =) ?
Matthias schrieb: > Jörg, bezahlt Atmel Entwicklungsingenieure so schlecht =) ? Nö, sicher nicht :), aber einen Hunderter zusätzlich würde ich trotzdem nicht ausschlagen. Ich müsste ja nur versprechen, dass er dafür irgendwas bekommt, so wie ich das verstanden habe …
Paul Baumann schrieb: > Wir lassen jetzt die Arbeit ruh'n > und freu'n und auf den Afternoon! Auf welchen After freust du dich?
Moin, konnte schon jemand die Trial testen ? :-) Gruß Kay
Kay Pohl schrieb: > Moin, > > konnte schon jemand die Trial testen ? :-) > > Gruß Kay WO zum runterladen? Eine der vielen leeren Versprechungen?
Moby schrieb: > > WO zum runterladen? > Eine der vielen leeren Versprechungen? Genau. Wahrscheinlich wurde die Trial verschoben. Kann ja mal passieren. Gruß Kay
Nur damits stimmt: $99 ;o) bei aktuellem Kurs 72,7086€ Harry
Harry schrieb: > Nur damits stimmt: $99 ;o) bei aktuellem Kurs 72,7086€ Dazu kommt doch gewiss aber noch die Märchen, ähem, Einfuhrumsatzsteuer, nicht wahr? Norwegen ist ja kein EU-Land. Schon sind's EUR 86,52.
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
Kay Pohl schrieb: > Genau. Wahrscheinlich wurde die Trial verschoben. Kann ja mal passieren. Der Download der Trialversion von http://avrtools.no/setuptrial.zip wird bei mir vom Google-Chrome Browser wie folgt blockiert: setuptrial.zip ist ein ungewöhnlicher Download und könnte schädlich sein. Mit einem fetten Einbahnstrassenschild und der Option "Verwerfen". Unter "Downloads" von Chrome habe ich dann zusätzlich die Option "Behalten", aber ich trau mich nicht, danach die Freigabe zu erteilen, denn dann fordert Chrome mich mit dieser Meldung nochmals auf, den Download freizugeben: Malware wiederherstellen? Dies könnte wirklich zu Problemen führen. Wir haben Sie gewarnt! [Trotzdem behalten] [Abbrechen] Ist da jetzt eine Malware enthalten oder irgendeine fiese "Systemerweiterung", vor der Google-Chrome warnt? Bis jetzt meckert nur Google-Chrome über den Download. Mein Virenscanner ist dabei gar nicht angesprungen.
Ich kann es Downloaden, aber das Zip ist defekt. Hier mal die Checksumme von dem, was ich erhalten habe: f6f37243b07ecc024c89e3f2e4312f85 *setuptrial.zip
Jürgen S. schrieb: > Der Download der Trialversion von http://avrtools.no/setuptrial.zip wird > bei mir vom Google-Chrome Browser wie folgt blockiert: > > setuptrial.zip ist ein ungewöhnlicher Download und könnte schädlich > sein. Du bist einfach nur einer der ersten, der diese Datei herunterlädt, deswegen hat Google noch keine Informationen darüber, ob sie gut oder böse ist. Also wird sicherheitshalber ein Warnung ausgegeben. Es liegt jetzt an dir, dem Ersteller der Datei zu trauen oder nicht.
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
Yalu X. schrieb: > Du bist einfach nur einer der ersten, der diese Datei herunterlädt, > deswegen hat Google noch keine Informationen darüber, ob sie gut oder > böse ist. Also wird sicherheitshalber ein Warnung ausgegeben. Es liegt > jetzt an dir, dem Ersteller der Datei zu trauen oder nicht. Das kann es nicht sein. Wenn ich selbst eine eigene ZIP-Datei erstelle, mit einem FTP-Programm wie Filezilla ins Internet hochlade, und danach mit dem Browser teste, ob die Datei einwandfrei downloadbar ist, bin ich sogar der allererste, der die Datei mit Google-Chrome herunterlädt. Und dann meckert Google-Chrome nicht, dass es ein "ungewöhnlicher Download" sei und blockiert gar nix. Dann würde ich eher der Vermutung von adenin glauben, dass es womöglich nur ein "broken zip file" ist, bei dem die ZIP-CRC Prüfsumme nicht korrekt ist. 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. Nachtrag: Die von Google-Chrome gesperrte Datei hat auch hier 17.359.617 Bytes
:
Bearbeitet durch User
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 ;-)
Jürgen S. schrieb: > Der Download der Trialversion von http://avrtools.no/setuptrial.zip wird > bei mir vom Google-Chrome Browser wie folgt blockiert: > > setuptrial.zip ist ein ungewöhnlicher Download und könnte schädlich > sein. Meckern wegen "ungewöhnlicher" Datei oder Falschalarme von Virusscannern passieren oft bei geschützter, limitierter Software. Also meist bei Trials oder passwortgeschüzten Programmen. Die enstprechenden Virtualisierungs- und Schutz-Tools (Oreans WinLicence, Enigma Protector usw.) erzeugen oft Bit-Kombinationen, die den Antiviren-Tools oder den Browsern nicht geheuer sind. Der Hersteller der Anwendersoftware kann dann sein geschütztes Programm den Antivirus-Firmen zum Test und Freigabe zusenden. Oder seine Software signieren lassen, was allerdings teuer ist. Das ist ein ganz übliches Verfahren. Ich benutze selber öfter solche Virtualsierungs/Protection Tools für meine selbst erstellten Programme und hatte auch schon öfter solche Probleme mit einem falschen Virus-Alarm.
:
Bearbeitet durch User
Angehängte Dateien:
-
trial_error.jpg
24 KB
Albert M. schrieb: > Meckern wegen "ungewöhnlicher" Datei oder Falschalarme von Virusscannern > passieren oft bei geschützter, limitierter Software. Also meist bei > Trials oder passwortgeschüzten Programmen. Die enstprechenden > Virtualisierungs- und Schutz-Tools (Oreans WinLicence, Enigma Protector > usw.) erzeugen oft Bit-Kombinationen, die den Antiviren-Tools oder den > Browsern nicht geheuer sind. OK, nach diesen Mut machenden Worten, dass der Download vielleicht doch nicht so eine gefährliche Malware ist, wie es Google-Chrome mich glauben machen möchte, habe ich die ZIP-Datei entgegen aller Warnungen freigegeben. 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):
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.
Angehängte Dateien:
-
AVR-Tool_unbenannt.png
7,4 KB
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. ;)
adenin schrieb: > Davon, dass Windows den Computer schützt, hör ich das erste mal. ;) Auch diese Warnmeldung ist bei nicht signierter Software normal. Kleinere Software-Hersteller vermeiden die Signierung ihrer Software oft aus Kostengründen (geht schnell in einige tausend Euro). Zumindest sollte aber der Software-Hersteller seine Kunden vorher auf die dann möglichen Warnmeldungen von Windows hinweisen.
> 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.
Wer denn schon solche Oberflächen einsetzen will, sollte lieber einige Euros mehr ausgeben und sich Flowcode 6 kaufen: http://www.matrixtsl.com/flowcode.php und https://www.google.de/search?q=flowcode&client=firefox-a&hs=uwy&rls=org.mozilla:de:official&channel=sb&tbm=isch&tbo=u&source=univ&sa=X&ei=o-eiU7XdDqak4gSZjIHQDA&ved=0CCEQsAQ&biw=1039&bih=536 Das gibt es schon einige Jahre und macht einen professionellen Eindruck. Allerdings coded man von Hand immer wesentlich schneller. Bei umfangreicher Logic geht auch bei Flowcode schnell die Übersicht verloren, da ist man mit C, LunaAVR oder Bascom immer besser bedient.
:
Bearbeitet durch User
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?
LastLast schrieb: > Jetzt ist ja schon seit 2 Tagen die Demo online und man hört von euch > nichts mehr? > Wer hat es denn schon getestet? Ich habe es mal kurz angetestet. Also die Trialversion und was man damit machen kann im Simulator. Sonst entwickele ich nur mit der Arduino-Software meine kleinen Projekte, aber wenn es etwas noch schnelleres und komfortableres für ein Rapid-Firmware-Development gibt, warum nicht. Mein Fazit als Zusammenfassung vorneweg: Der Programmgenerator hat einen minimalen Funktions- und Leistungsumfang. Viel zu gering, um damit irgendwas sinnvolles anzufangen. Eventuell kann man damit spezielle "Schaltuhren" ganz gut programmieren. Was die "Killer Application" sein soll, weswegen man dieses Tool unbedingt haben muß, hat sich mir jedenfalls nicht erschlossen. Eher das Gegenteil ist der Fall. Im Detail: Man kann sich tatsächlich mit diesem Programmgenerator Anwendungen zusammenklicken und zieht dazu Funktionsblöcke auf die Arbeitsfläche, bei denen man Eigenschaften setzen kann und zwischen denen man dann Linien zieht, ohne auch nur eine einzige Zeile Quellcode zu schreiben. Klick und Klack, hier eine Eigenschaft gesetzt und fertig ist das Programm. Simulieren im eingebauten Simulator möglich und funktioniert prima, hochladen in einen realen Controller funktioniert mit der Trialversion nicht. Als kleine Aufgabenstellung zum Testen hatte ich mir "Temperaturmessung mit NTC und Ausgabe des Temperaturwerts auf Serial" ausgedacht und wollte es zusuammenklicken. Im einzelnen: 1. ADC-Wert auslesen 2. ADC-Wert durch einen Tiefpassfilter glätten 3. ADC-Wert mit der NTC-Kennlinie zu einer Temperatur umrechnen 4. Temperaturwert im Sekundentakt auf Serial ausgeben Geschafft habe ich von diesen vier Teilaufgaben das: 1. ADC-Wert auslesen 2. ADC-Wert durch einen Tiefpassfilter glätten 3. - 4. ADC-Wert im Sekundentakt auf Serial ausgeben Die Errechnung der Temperatur anhand der NTC-Kennlinie war mir leider nicht möglich, da ich keine Möglichkeit gefunden habe, eine Gleitkommaberechnung durchzuführen und die Logarithmusfunktion zu nutzen. Der Programmgenerator beherrscht als Mathematik den Umgang mit Integerzahlen und die vier Grundrechenarten. Das war's. Keine Gleitkommazahlen. Keine trigonometrischen Funktionen wie Sinus oder Tangens. Und auch keine anderen transzendenten Funktionen wie Logarithmus oder Wurzelziehen. Man kann eine Temperaturmessung auch nicht auf eine andere Art realisieren, z.B. mit einem gängigen digitalen Temperatursensor wie dem DS18S20: Es werden überhaupt keine gängigen I2C-Sensoren unterstützt, sondern als einziges I2C-Gerät nur die DS1307 als Realtime-Clock. Als jemand, der sich seine Sachen sonst immer nur mit der Arduino-Software und den Arduino-Komfortfunktionen, der AVR-libc Library und ggf. mit Hilfe von nachinstallierten Third-Party Libraries programmiert, bin ich schwer enttäuscht, wie wenig man mit dem Programmgenerator vergleichsweise auf die Reihe bekommt und an was für Pillepalle-Kram der Generator bereits scheitert. Es kann natürlich sein, dass ich bei meinem Kurztest irgendwas übersehen habe. Aber was ich gesehen habe, hat mich einfach nicht überzeugt. Weil man eben viel zu wenig damit machen kann. Und das Wenige, was man damit machen kann, wie Schalten im kleinsten Schaltabstand von 0,01 Sekunden, oder die vier Grundrechenarten im Integer-Wertebereich, das kann man dem betupptesten Arduino-Hobbyprogrammierer in zehn Minuten beibringen, damit er es auch in der Arduino-Software coden kann.
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.
Pic schrieb: > Warum funktioniert das just bei Avrtools.no nicht? Weil es Paypal ist? Die sind schließlich berüchtigt. Ich hatte das auch mal, als ich Antennen bei einem Funkamateur in den USA kaufen wollte. Er hat mir beteuert, dass ich der erste Fall wäre, bei dem Paypal Späne machen würde … ist halt nicht vorhersagbar, nach welchem Schema sie ihre "Sicherheitsbedenken" so applizieren.
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.
Jörg Wunsch schrieb: > Weil es Paypal ist? Die sind schließlich berüchtigt. Langsam könnte man analog zu Godwins Law irgendein Paypal-Meme postulieren. Es kommt prinzipiell einer, der meint, dass sich Paypal unmotiviert Kohle einbehält, und danach ist jede weitere Diskussion sinnfrei. /Hannes
Johannes S. schrieb: > Es kommt prinzipiell einer, der meint, dass sich Paypal unmotiviert > Kohle einbehält Zumindest in meinem Fall kann ich dir versichern, dass das Realität war. Nicht im Sinne von "Kohle einbehalten", aber eben auch weit weg von deren Versprechen: "Der Empfänger hat dann 'sofort' sein Geld." Es hat einige Tage gedauert, bis sie der Meinung waren, dass der Empfänger sein Geld wert wäre oder was auch immer – erzählen tun sie ja nix dazu. Ich würde den Laden jedenfalls nicht freiwillig verwenden, solange es Alternativen gibt.
:
Bearbeitet durch Moderator
Das von Jörg Geschriebene kann ich auch bestätigen. Wer keine Alternative dazu bietet, wird nicht als Lieferant in Betracht gezogen.
Ich habe mir angwöhnt lieber Vorkasse zu leisten als Paypal zu nutzen. Das habe ich nur einmal auf Verkäuferwunsch hin getan. Im Geschäftsleben ist das als Neukunde nicht außergewöhnlich. Freilich nur wenn der Verkäufer als seriös bekannt ist bzw. der Betrag gering. Namaste
@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.
LM317-TO3 schrieb im Beitrag #3707768: > 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. Sag ich doch, nur Ahnungslose und Internetausdrucker. Wer schon von sich selber sasgt, dass er heute noch auf Phishing-Mails reinfallen würde der lasse es in der Tat lieber sein. Und bestelle sich einen Vormund. Dafür auch noch PayPal die Schuld zu geben setzt dem Fass die Krone auf (oder so ähnlich).
LM317-TO3 schrieb im Beitrag #3707786: > Das ist dummes Gschwätz eines Jünglings der sich für oberschlau hält. Natürlich. Was auch sonst. Es kann ja nicht sein dass der Greis irrt. Und Jüngling bin ich leider nicht mehr. > Glaubst du jeder ist im Stande diesen betrügerischen Paypalmails auf > Anhieb ihre Echtheit anzusehen? Die sind äußerst gut gemacht und nicht > vergleichbar mit dem üblichen Spam. JEDER sollte heute wissen dass man niemals sensible Daten auf Webseiten eingibt, über die man durch E-Mail Links gelangte. Außerdem sieht man der Webseite anhand des gültigen/nicht gültigen Zertifikats sofort an ob echt oder nicht.Es kann nicht zuviel verlangt sein, einen Blick auf die Echtheit zu riskieren bevor man Passwörter oder Kontonummern eingibt. Das reicht erst mal. Dann kann die Mail noch so gut gemacht sein. Außerdem hat das Problem eben nichts mit PayPal zu tun. Von Banken gibt es auch solche Mails, aber ich bin mir sicher, Online-Banking ist auch böse und unsicher. Es geht einfach nichts über die Papierüberweisung, gelle? Du fällst wahrscheinlich auch auf den Enkeltrick rein, leider ist da dann kein Internet schuld. Aber wer soll auch bitte erkennen dass er Enkel nicht wirklich im Knast sitzt und sofort 30.000 Euro braucht. Kann ja nicht jeder wissen.
:
Bearbeitet durch User
tsch tsch tsch beruhige sich der Schnaufer mal, sonst bekommt er noch ein Herzinfarkt pishing mails bekomme ich auch nau und? Und weis auch um die Gefahren von ebanking , nutze es trotzdem und gern. paypal ist mir vor allem zu unerreichbar, Support. Ich bevorzuge deshalb direkte Bezahlung weil hier alles klar und nachvollziehbar ist und eine aufsuchbare Adresse existiert. Ich besaß tatsächlich ein Paypalkonto kann aber mit Paypal nicht mehr in Verbindung treten nach Umzug ins Ausland und Kündigung der alten Mailadresse weder per mail, noch online noch per 600 Ohm, und nun rate mal woran das wohl liegt. Genau keine Telefonnummer welche vom Ausland erreichbar ist und keine gültigen Zugangsdaten mehr vorhanden. Das Unternehmen ist schlicht unerreichbar geworden. Bei meinen Banken passiert mir das nicht. Postbank ausgenommen, mit denen war das auch so ein Kreuz.---> Konto ausgeglichen gekündigt fertig. Nun mich stört das nicht. Ich habe dort weder guthaben noch schulden. c'est la vie Namaste
:
Bearbeitet durch User
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!
cyblord ---- schrieb im Beitrag #3707739: > Ja dann kommen sie immer alle raus aus ihren Löchern. Wer kam hier bei der erstbesten Paypal-Kritik aus dem Loch gekrochen? Geh mal zurück: die Sache fing damit an, dass der Empfänger angegeben hat, das Geld von Paypal nicht erhalten zu haben. cyblord ---- schrieb im Beitrag #3707739: > Mach das mal bei Käufen in Fernost du Schwätzer. Mäßige dich bitte in deiner Ausdrucksweise. Ich möchte dich nochmals an das Thema des Threads erinnern, es ging hier nicht um eine Lieferung aus Fernost, sondern um Norwegen. Das ist Teilnehmer bei SEPA. Was nützt mir ein Unternehmen, welche Zahlungsleistungen im Sinne einer Bank erbringen will, wenn es anschließend nicht die Verlässlichkeit einer Bank hat? Von einer Bank erwarte ich nicht, dass sie „meistens“ alles korrekt erledigt, sondern dass sie das immer tut. Das schließt Paypal aber bereits per AGB aus, denn sie haben da allerlei Vorbehalte eingebaut, unter denen sie sich nahezu beliebige Freiheiten einräumen, das Geld eben auch mal nicht weiterzuleiten. Dass sie von diesen Möglichkeiten zuweilen Gebrauch machen, darüber gibt es mehr als einen Bericht im Internet. Da ist es auch schon hinreichend ärgerlich, wenn es nur „ein paar Tage“ sind und nicht wie bei den krasseren Berichten Monate. Das allein genügt mir, sie nur als allerletzte Alternative bei Zahlungen benutzen zu wollen. Handel mit Fernost gehört da sicher mit dazu, denn dort steht das Risiko, Paypal das Geld zu geben, gegen exorbitant hohe Kosten oder noch größere Risiken für anderweitige Wege, das Geld dahin zu transferieren.
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 ;-(
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.