Hallo zusammen, Ich darf mich in aller Kürze vorstellen: Hardware Ing., 47 mit wenig Software Erfahrung. In meiner Jugend habe ich allerdings C, Assembler, Pascal, Ada und so ein Zeugs an der Uni gemacht. Mein aktuelles Problem: ich benötige für eine automatisierte Testumgebung Software. Die Testumgebung besteht aus 2x Atxmega. Die IOs der µC steuern diverse Testsignale. Die kleinste zu realisierende Schaltzeit liegt << 1ms und daran ist ProfiLab Expert von Abacom schon mal gescheitert. Auch gefällt mir die Oberfläche von Profilab Expert 4.0 nicht im geringsten, nicht mal ein CTRL-Z gibt es . Ein Graus^10!! :( Es graust mir allerdings auch vor der Erstinitialisierung des µCs in C. Und ich wäre schon froh, wenn ich eine abstraktere Ebene als C verwenden könnte. Letztendlich strebe ich eine ständige (galvanisch getrennte) USB Verbindung zw einem Laptop und den beiden µCs der Testumgebung an. Das hätte den Vorteil, dass der Laptop loggen könnte, dass er diverse Testmuster vorgeben könnte, etc. Es wäre schön, wenn ich möglichst viel über den LT steuern könnte, statt jedesmal 2 neue Programme laden zu müssen. Mathlab&co scheiden aus. Viel zu teuer und eher an fertige Engeräte gebunden. Bin beim googeln auf Flowcode gestossen. Die V5, die nun rauskamm kennt den µC prinzipiell, jedoch sagt mir das erstmal gar nichts. Wird da graphische Unterstützung z.B. für eine Kommunikation via USB vorhanden sein - und taugt es dann auch was? Das sind so meine Fragen... Ich habe im Forum gesucht und gelesen, dass die meisten von euch Flowcode verdammen und nur auf echtes C/Assembler stehen. Diese Meinung ist akzeptiert - aber in meinem Anwendungsfalle belanglos, denn ich will nicht das Rad neu erfinden, sondern an und für sich nicht anspruchsvolle Software schreiben. Meine Bitte: hat jemand praktische Erfahrung mit Flowcode und werde ich mir einen Gefallen tun, wenn ich 200Pfund raushaue? Evtl kommt noch der in circuit Debugger dazu? Ich nöchte nicht wieder 300 Eier umsonst versenken - nur um dann doch auf C umsteigen zu müssen. Was noch akzeptabel wäre, ist dass ich besondere Routinen in C verfasse und als Makros ablege, aber 80% möchte ich abstrakter als in C erledigen. Gibt es Alternativen für mich zu Flowcode? Andere ähnliche Proggis? Ich danke für die Mühe, Jürgen PS Seit gerstern darf man ganz legal mit Second Hand Software handeln. Gibt es jemanden der eine alte Lizenz an mich verkaufen möchte? Flowcode verlangt beim upgraden nur 50%.
>Die Testumgebung besteht aus 2x Atxmega. Wozu? Nimm EINEN ARM. >Gibt es Alternativen für mich zu Flowcode? Bascom? Schnell weg hier;)
Erzähl doch mal, was du mit den beiden µC vorhast. Was für Zeitabläufe sollen gesteuert werden? "<< 1ms" ist nun wahrlich keine vernünftige Aussage.
Hallo hier die Kurzbeschreibung was die Testumgebung machen soll: - ca 30 Fehlersignale in das zu testende System einstreuen. Das sind normale IOs am µC mit ein bißchen Hardware drumm herum. Die habe ich nun fertig aufgebaut (Optokoppler mit Lastwiderständen drann). - ca 20 analog Eingänge mit rel. langsamen Signalen (<<1kHz Bandbreite). hier soll geloggt werden. - die Reaktion des Prüflings beurteilen; läuft in ferner Zukunft auf eine automatisierte Testumgebung hinaus. Hieraus ergeben sich schon mal ne Menge Anforderungen in Richtung flexibilität des Programmes: Steuerung über einen Laptop. Eine Idee wäre, via USB die zu erzeugenden Fehlersignale vorgeben. Könnte im simplesten Falle eine ASCII Datei sein, die definiert Pin X für Y µSekunden ein/ausschalten, etc... Der µC müsste damit via USB Daten empfangen können und auch ergebnisse an den Laptop zurückliefern. Ich werde sicherlich NICHT die Ressourcen eines ATXMega in Völle ausschöpfen, es geht hier wohl mehr um den leichtesten Ansatz sowas flexibel zu bewerkstelligen. Als µC Modul habe ich an dieses Teil von Alvidi gedacht. http://alvidi.de/avr_xsmodul_ext.html JTAG und PDI sind vorhanden. Hoffe ich konnte mein Anliegen verdeutlichen? Jürgen
Hi >Ich werde sicherlich NICHT die Ressourcen eines ATXMega in Völle >ausschöpfen, es geht hier wohl mehr um den leichtesten Ansatz sowas >flexibel zu bewerkstelligen. Hört sich eher danach an, das ein schon normaler AVR Suizid wegen Unterarbeitung begehen würde. MfG Spess
Jürgen Nobody schrieb: > - ca 30 Fehlersignale in das zu testende System einstreuen. Das sind > > normale IOs am µC mit ein bißchen Hardware drumm herum. Die habe ich nun > > fertig aufgebaut (Optokoppler mit Lastwiderständen drann). > > - ca 20 analog Eingänge mit rel. langsamen Signalen (<<1kHz Bandbreite). > > hier soll geloggt werden. > > - die Reaktion des Prüflings beurteilen; läuft in ferner Zukunft auf > > eine automatisierte Testumgebung hinaus. Wie schnell soll denn der uC die Reaktion des Prüflings an den PC schicken können? Hab selbst schon etwas in der Richtung gemacht (at90usb1287 als Testsystem) und da war definitiv die USB-Schnittstelle und die PC-seitige Ansteuerung davon der Flaschenhals, was die Latenz betrifft. Daher sollte mal ganz genau beschrieben werden, wie schnell das Ganze sein muss.
Hey, das Timing bewerte ich als langsam und ja, der Flaschenhals dürfte eher USB als denn ein 32MHz getakteter ATXmega sein, agreed. Die Reaktionen des Prüflings liegen im Bereich von >1ms < 5ms. Also easy going. Das Timing ist nicht das Problem. Wie erstelle ich die nötige Sowftare (Laptop+µC) mit möglichst wenig Aufwand, das ist die Frage. Ich kann im Übrigen Unterstützung bei der Erstellung der Software gebrauchen, so da jemand Zeit hätte. Bezahlen kann ich es allerdings eher symbolisch, so meine Vermutung. Aber falls da schon ein Proggi existiert das nur angepasst werden müsste, könnte das ganze Sinn machen? Gute Nacht Deutschland, Jürgen
Hallo, warum bist du so wild auf die USB-Verbindung? Ich würde einfach eine SD-Karte dranhängen. Vorteil du sparst den PC und kannst das Logfile einfach später einlesen und bearbeiten. Die Angst vor C kann ich nicht verstehen. Für die Initialisierung bekommst du alles schon vorbereitet hier im Forum. Ich bin auch kein Programmierguru komme aber mit Strg C + Strg V relativ einfach zum Ziel
Hans schrieb: > Ich bin auch kein > Programmierguru komme aber mit Strg C + Strg V relativ einfach zum Ziel Naja, besonders bei C hat diese Methode aber schnell ihre Grenzen. Erinnert mich an das Zitat auf der Benutzerseite von gjlayde. Andererseits sollte man die Sprache nicht komplizierter machen als sie ist. Eines ist allerdings richtig: Für schnelles Entwickeln ist sie - da recht low-lewel - nicht ideal. Da ist Bascom bestimmt besser, wenn auch u.U. etwas langsamer.
Also wenn du das ganze in "schick", "automatisiert" und "flexibel" haben möchtest.. nimm Matlab/Simulink und schreib dir in Java die nötigen routinen um auf deine IO hardware zuzugreifen. wenn du das gemacht hast kannst du zB automatisiert mit dem ReportGenerator, auf basis deiner entworfenen test-cases in simulink reports generieren lassen inkl. bewertung etc. ich rate deswegen zu matlab/simulink, da du sehr abstrakt arbeiten kannst und auch äußerst komplexe auswertungen effizient erstellen kannst!
Hallo, Mathlab fällt wegen zu hoher Kosten aus. Andere Ideen? gruß Jürgen
Also ehrlich gesagt ist das heute mit der µC-Initialisierung nicht das große Problem und Hilfe um den AVR in C zu Programmieren gibt es genug. Der AVR hat ja keine Assembler-Startdatei sondern das Minimalprogramm besteht wirklich nur aus einer main.c mit leerer void main() und sonst nix. Da der AVR sehr robust ist und Schutzdioden hat, so dass man bequem Signal>5V per Widerstand oder direkt über Spannungsteiler zuführen kann, macht es durchaus Sinn diesen in dein Anlagenpotential reinzuheben und sich die OK zu sparen. Als Kommunikation nach außen selbst etwas per USB aufzusetzen, halte ich für gewagt. Treiber bedienen, Schnittstellensoftware und ganz abgesehen davon der Stack im µC... Erschlag doch USB und galvanische Trennung mit einem FTDI USB-UART IC (FT232RL). Der läuft zuverlässig und die UART am µC mit Peter Fleurys Library in C ansteuern. In Windows/Linux taucht er dann als ganz normaler COM-Port auf. Du kannst auch mit dem µC in .csv ausgeben und unter Windows per hterm mitschreiben und direkt abspeichern und in Excel öffnen. Wenn du eh genug Platz auf dem µC hast, kannst du sogar printf() in all seiner Pracht verwenden. Die galvanische Trennung erfolgt dann zwischen FTDI-Chip und AVR and den UART-Leitungen per OK. Der FTDI wird per USB versorgt, ebenso der OK auf seiner Seite. Der AVR wird zusammen mit deiner Anlage auf gemeinsames Massepotential gelegt. Für zuverlässigen Datendurchsatz brauchts dann halt einen 6n137 o.ä. Ganz ehrlich, etwas anspruchsloseres als den AVR in C gibt es nicht. Hier wimmelt es von Tutorials und Einführungskursen. Wenn du dann noch Timer und UART im INT-Betrieb brauchst, wirst du auch vor lauter Beispielen nur so erschlagen. Du kannst ihm sogar einen Bootloader verpassen und in deiner Anwendung später umprogrammieren, denn Bootloader per UART gibt es auch wieder wie Sand am Meer. Flowcode braucht wirklich keine Sau und Bascom sei den Basic-Urgesteinen für den Einstieg auch verziehen, aber bitte nicht für den Produktiveinsatz...
Hallo Renne, danke für deine fundierte Antwort. Ich denke Du hast Recht, werde wohl bei C bleiben .... und mich in den µC einarbeiten müssen. Ich setze ein fertiges Modul ein (Link ist oben), welches den Baustein CP2102 von Silabs als USB <-> UART Treiber verwendet. Ein USB Isolator (aus Taiwan/Ebay für 35E, incl DC/DC) ist vorhanden. Ich habe angefangen mich hier nach fertigen Codes umzuschauen. Finde für nen XMEGA schon mal sogut wie nichts. Suche ich in der falschen Ecke? Habe da nachgesehen: http://www.mikrocontroller.net/articles/AVR_Softwarepool Richtig, auf PC Seite wird ein Treiber benötigt, welcher Daten senden bzw entgegennehmen kann. Das wäre nicht das Problem. Hterm, wie von Dir beschrieben sollte ebenso funktionieren, der USB Port sollte als virtueller COM Port erscheinen. Diesbezüglich existiert auch schon ein Programm Rumpf in Visual C, den ich verwenden könnte. Fragen: - gibt es hier irgendow Treiber (µC) für den CP2101? Kann ich Peter Fleurys Code verwenden/anpassen? - gibt es bereits Code für den CP2101? Habe mit der SuFu hier keinen Code finden können, sehr wohl aber gibt es anderweitige Beiträge zu diesem Chip. Es ist also kein Exot :) - gibt es Code für Timer/Scheduler Xmega? Ich bin sicher ... dass es Code geben müsste, jeder von uns hat doch ähnliche Probleme beim Verwenden der µC..... meine es ist einfach bescheuert das Rad noch mal erfinden zu müssen :( Es wird höchste Zeit für eine höhere Programmiersprache auf funktionalem Level.... wo man nicht hinter dem einzenlen Bit und Byte hersein muß?! Renee, hasst nicht zufällig Zeit übrig? Gruss Jürgen PS. ein Bootloader ist schon auf dem Modul installiert
Für den CPx oder den FTDI braucht es keine Treiber auf µC-Seite. Tx und Rx des USB-Bausteins mit Tx und Rx des µC überkreuzt verbinden. Dann einfach die UART des XMEGA auf z.b. 56kbaud konfigurieren und senden. Wenn du dann bei hterm den Com-Port des CPx mit 56kbaud öffnest, verstehen die sich. Das ist eigentlich nur eine hübschere Version des MAX232, der UART auf RS232 hebt. Genau so macht dir der CPx und der FTDI das unter Windows als COM-Port verfügbar. Wenn du auf dem xmega eh schon einen Bootloader hast, kannst du mit avrdude über den virtuellen Com-Port gleich losflashen. Wenn dir C nixht schon genug Arbeit abnimmt: Es geht auch C++ auf dem xmega, aber das ist mit Vorsicht zu genießen.
Vielleicht willst du dir ja Cypress Creator mal ansehen.
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.