Ein frohes neues Jahr wünsche ich allen Mitgliedern. Ich möchte hier gerne mein neues Programm vorstellen. http://www.valentin-diring.de/uC-PCC Ein Programm, mit dem Sie die IO-Register eines AVR-Mikrocontrollers manipulieren können. PS: Feedback ist ausdrücklich erwünscht
Wenn du etwas vorstellen möchtest, dann ist dafür die Codesammlung der richtige Platz. Und es wäre toll, wenn du den ganzen(!) Code in der Codesammlung hinterlegen kannst. Denn die Codesammlung garantiert, dass man auch in 10 Jahren noch den Code von heute dort vorfinden wird. Was man von externen Web-Seiten meistens nicht sagen kann. Danke.
Gast
#2480737
hier könnt ihr das Programm ohne lästige Registrierung Herunterladen. www.valentin-diring.de/uC-PCC/uC-PCC.zip
Es wäre auch nett, wenn dabei stehen würde, was in etwa dabei abläuft. Dann muß man nicht erst mühsam die ZIP entdröseln, um dann festzustellen, daß man es nicht braucht.
Das "Benutzer-Handbuch" in der ZIP sagt aber auch nicht mehr. Ansonsten ein paar *.exe und *.hex. Wozu das Ganze? Ich habe den Verdacht, die 1.6Mb sind für die Katz. Für die Codesammlung ist jedenfalls auch nichts dabei.
Ganz nettes Projekt, leider wird nur so ein alter AVR-Typ unterstützt. Interessanter als die PC-Gui fände ich die Uart-Protokoll-Beschreibung. wenn man das alles, was die Gui kann direkt über ein Terminal machen könnte, wäre das zur Benutzung in Skripten sehr nütlich. Die SPI oder I²C über Gui macht zB nicht so viel Sinn. Ich vermute aber, das Protokoll beschränkt sich auf das Schreiben von Adressen und den Rest macht die GUI, oder? Zumindest wäre das für die Umsetzung des vorgestellten Ansatzes das einfachste. Ich hatte mal etwas ähnliches angefangen, was auf einem Tiny861 basiert, der Befehle per UART entgegennimmt. Ist aber, wie so oft nicht fertig, wird aber nach Bedarf erweitert zur Zeit sind es nur die Basisfunktionen, die unterstützt werden: Digitaleausgänge schalten, Digitaleingänge einlesen Analogeingänge einlessn (auswählbare Referenz) periodisches Einlesen beliebiger Kanäle (Open Format für Logview) PWM und Counter steht noch ganz oben auf der Liste Falls meine Vermutung bezüglich der Implementierung des Protokolls falsch ist, wäre ich daher sehr erfreut, wenn du den Code und eine Protokoll-Beschreibung frei zugänglich machst. MfG Vlad PS: DAs Handbuch ist kein Handbuch, sondern eine Sammlung von Schaltplänen, ohne weitere Erklärungen. Der einzige wirkliche Text ist die Seite mit den sinnlosen Rechtsbelehrungen. WEnn ich mich recht erinnere sind Schaltpläne nicht vom Urheberrecht erfasst, womit auch ein Großteil dieser Belerhungen überflüssig ist.
Damit nicht jeder sich das antun muß hier der Inhalt der ZIP:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
Sieht interessant aus. Würde es dich stören uns einen Blick in die Quellen zu gestatten? Gruß Oliver
dank dieses tollen "Empfehle meinem Freund"-Blödsinns passt die Gui horizontal nicht auf meine (1680-Startleiste) Pixel, was unter anderem auch daran liegt, dass die Tabs rechts ein haufen leere Fläche haben. über den interne/externe Peripherie-Buttons ist auch ein Haufen Platz und bei externer Peripherie ist gar nix. Die Gui könnte also deutlich kompakter sein. Der Impuls-Generator-Button wirklt auch fehl am Platz, den könnte man auch ins Menü packen, was ja auch als Buttonleiste misbraucht wird, da einige Menüeinträge direkt eine Funktion auslösen, anstatt, wie für ein Haupmenü üblich, erst mal ein Untermenü zu öffnen. wiso scrollt das Hauptmenü überhaupt mit hoch, wenn man vertikal scrollt (die Fenster-Startgröße ist kleiner als der Fensterinhalt? Gleiches gilt für die Statusleiste, was aber hier nicht schlimm ist, da die keinen Informationsgehalt bietet. Die Webadresse gehört unter Hilfe/about
Die HExfiles enthalten nur ~100Bytes Programmcode. Ist da ein Fehler unterlaufen, oder stimmt das tatschlich?
Gast
#2480971
Feedback: Die Idee hinter dem Programm finde ich gut. Mit so einem Tool könnte man eine Schaltung schön einfach testen, nach dem Löten die .hex aufspielen und schnell mal ein paar Pins wackeln, PWM ausgeben, ... Sehr nett wäre ein integrierter Bootloader, das wäre dann fast "JTAG für arme" Aaaaaber: - die Registrierung auf der Seite ist mal komplett unsinnig, wozu müssen die Daten erhoben werden? E-Mail Adresse sehe ich ja noch ein, dann aber bitte lokal auf der Seite und nicht über so einen dubiosen Anbieter. Selbst der Link zum Anbieter führt über 4-5 Redirects, ich will garnicht wissen wo eine E-Mail Adresse überall landet. - Empfehlungs-Funktion im Programm: Najaa. Meinetwegen, wäre aber in der Hilfe oder Übersicht besser aufgehoben. 1/3 vom Bildschirm sind von dieser Funktion blockiert, wo auch nicht klar ist wie die Mails überhaupt verschickt werden... - Anonyme Daten-Erhebung: Was soll das denn? Feature-Wünsche oder Kommentare lassen sich per Mail oder Forum viel besser übermitteln. Was nützt dir die Info, das 100 User 50x täglich mit deinem Tool den AD-Wandler ein- und wieder ausschalten?! Bekommt der zugehörige Button dann rundere Ecken, damit der Cursor nicht so hart anstößt? Fazit: Man könnte auf die Idee kommen, hier soll mit einem Programm mit minimalem Gegenwert irgendwie Geld/Ego/Klicks/Adressen gesammelt werden. Wozu? Kommt von den Kindererziehungs- und Dating-Tipps nicht genug rum?
Danke erstmal für den zahlreichen Feedback. > Autor: Karl Heinz Buchegger (kbuchegg) (Moderator) > Datum: 01.01.2012 22:41 > Wenn du etwas vorstellen möchtest, dann ist dafür die Codesammlung der > richtige Platz. Das Programm ist auch für den geeignet, der nicht einfach nur ein Projekt nachbauen möchte. Z.B. Einer, der sich mit CPLDs oder FPGAs beschäftigt, und ein paar digitale Signale braucht. > Und es wäre toll, wenn du den ganzen(!) Code in der > Codesammlung hinterlegen kannst. Der Firmware-Code ist recht klein. Siehe Anhang. > Denn die Codesammlung garantiert, dass > man auch in 10 Jahren noch den Code von heute dort vorfinden wird. Ich mache dann dort ein Thread mit einem Verweis auf Diesen. Danke für die Tipps ------------------- > Autor: 1234 (Gast) > Datum: 01.01.2012 23:17 > hier könnt ihr das Programm ohne lästige Registrierung Herunterladen. > www.valentin-diring.de/uC-PCC/uC-PCC.zip Über den Facebook-Button geht es noch schneller. ------------------- > Autor: Klaus Wachtler (mfgkw) > Datum: 01.01.2012 23:51 > Es wäre auch nett, wenn dabei stehen würde, was in etwa dabei abläuft. Bitte das YouTube-Video vollständig ansehen. Es wurde von mir in HD-Qualität aufgenommen (Evtl. auf HD umschalten bitte). > Dann muß man nicht erst mühsam die ZIP entdröseln, um dann > festzustellen, daß man es nicht braucht. "entdröseln" ist ein Fremdwort für mich, dass ich nicht kenne. > Autor: Valentin Diring (valentin) > Datum: 01.01.2012 22:28 > Ein Programm, mit dem Sie die IO-Register eines AVR-Mikrocontrollers > manipulieren können. ------------------- > Autor: Klaus Wachtler (mfgkw) > Datum: 01.01.2012 23:58 > Das "Benutzer-Handbuch" in der ZIP sagt aber auch nicht mehr. > Ansonsten ein paar *.exe und *.hex. > Wozu das Ganze? > Autor: Valentin Diring (valentin) > Datum: 01.01.2012 22:28 > Ein Programm, mit dem Sie die IO-Register eines AVR-Mikrocontrollers > manipulieren können. > Ich habe den Verdacht, die 1.6Mb sind für die Katz. Hmm? Haben Sie keine Flatrate? > Für die Codesammlung ist jedenfalls auch nichts dabei. Ja. ------------------- > Autor: Vlad Tepesch (vlad_tepesch) > Datum: 01.01.2012 23:58 > Ganz nettes Projekt, leider wird nur so ein alter AVR-Typ unterstützt. Es werden die ATmega16 und ATmega32 vorerst unterstützt, weil diese am meisten verbreitet sind. > Interessanter als die PC-Gui fände ich die Uart-Protokoll-Beschreibung. Dieser ist recht einfach. Siehe Anhang. > wenn man das alles, was die Gui kann direkt über ein Terminal machen > könnte, wäre das zur Benutzung in Skripten sehr nütlich. Ich bin da anderer Meinung. Dank der GUI hast Du voll den Überblick. > Die SPI oder I²C über Gui macht zB nicht so viel Sinn. Da bin ich auch anderer Meinung. Mit I²C kannst Du z.B. ein EEPROM (24Cxx) brennen. Stell dir vor, Du hast ein Projekt indem ein Tiny861 einen 24Cxx EEPROM benutzt. Und Du willst wissen was passiert, wenn ein bestimmter Wert erreicht ist, dann kannst Du diesen ganz gezielt manipulieren (geplanter Feature). > Ich vermute aber, das Protokoll beschränkt sich auf das Schreiben von > Adressen und den Rest macht die GUI, oder? Zumindest wäre das für die > Umsetzung des vorgestellten Ansatzes das einfachste. So ist es. > Ich hatte mal etwas ähnliches angefangen, was auf einem Tiny861 basiert, > der Befehle per UART entgegennimmt. > Ist aber, wie so oft nicht fertig, wird aber nach Bedarf erweitert Schade, klingt aber sehr interessant. > zur Zeit sind es nur die Basisfunktionen, die unterstützt werden: > Digitaleausgänge schalten, > Digitaleingänge einlesen > Analogeingänge einlessn (auswählbare Referenz) > periodisches Einlesen beliebiger Kanäle (Open Format für Logview) > PWM und Counter steht noch ganz oben auf der Liste Veröffentliche es doch, oder schick es mir bitte per Email. Ich würde es mir gerne ansehen. > Falls meine Vermutung bezüglich der Implementierung des Protokolls > falsch ist, wäre ich daher sehr erfreut, wenn du den Code und eine > Protokoll-Beschreibung frei zugänglich machst. Siehe Anhang. > PS: > DAs Handbuch ist kein Handbuch, sondern eine Sammlung von Schaltplänen, > ohne weitere Erklärungen. Da kommt noch der Text dazu. Später. Danke für das große Interesse Vlad Tepesch. ------------------------------------------- > Autor: Klaus Wachtler (mfgkw) > Datum: 01.01.2012 23:59 > Damit nicht jeder sich das antun muß hier der Inhalt der ZIP: Relevant sind nur folgende Dateien: - µC-PCC-Starten.exe - µC-Firmware Ordner mit den Hex-Dateien - WICHTIG.txt und evtl. die - .NetFramework4.exe Ich finde das sollte sich jeder mal antun! ------------------------------------------- > Autor: Oliver J. (skriptkiddy) > Datum: 02.01.2012 00:04 > Sieht interessant aus. > Würde es dich stören uns einen Blick in die Quellen zu gestatten? Kein Problem, siehe Anhang. Danke für das Interesse. ------------------------------------------- > Autor: Vlad Tepesch (vlad_tepesch) > Datum: 02.01.2012 00:11 > dank dieses tollen "Empfehle meinem Freund"-Blödsinns passt die Gui > horizontal nicht auf meine (1680-Startleiste) Pixel, was unter anderem Du kannst die Breite minimieren, diese wird dauerhaft abgespeichert. > auch daran liegt, dass die Tabs rechts ein haufen leere Fläche haben. > über den interne/externe Peripherie-Buttons ist auch ein Haufen Platz > und bei externer Peripherie ist gar nix. Es wird noch was hinzukommen. > Die Gui könnte also deutlich kompakter sein. Breite minimieren. Schick mir bitte ein Screenshot per Email. So könnte ich das Programm an deinen Bildschirm evtl. anpassen. > Der Impuls-Generator-Button wirklt auch fehl am Platz, den könnte man > auch ins Menü packen, was ja auch als Buttonleiste misbraucht wird, da > einige Menüeinträge direkt eine Funktion auslösen, anstatt, wie für ein > Haupmenü üblich, erst mal ein Untermenü zu öffnen. Ja, aber die Icons sind nicht üblich in der Menuleiste. > wiso scrollt das Hauptmenü überhaupt mit hoch, wenn man vertikal scrollt > (die Fenster-Startgröße ist kleiner als der Fensterinhalt? Screenshot bitte. Ansonsten Danke für die konstruktive Kritik ------------------------------------------- > Vlad Tepesch schrieb: > Die HExfiles enthalten nur ~100Bytes Programmcode. > Ist da ein Fehler unterlaufen, oder stimmt das tatschlich? Das stimmt tatsächlich. ********** Das Programm wird von mir laufend weiterentwickelt. Weiter Veröffentlicht wird es nur, wenn genug Leute sich in meine Newsletter-Liste eintragen (sprich das Programm nutzen). MfG Valentin Diring http://www.valentin-diring.de/uC-PCC PS: Bitte über den oberen Link das Programm beziehen, weil es für mich wichtig ist zu wissen, wieviele Nutzer es gibt. PPS: Mist, ich hab vergessen auf die Uhr zugucken. Gute Nacht allerseits.
> Autor: Leo-andres H. (leoloewe) > Datum: 02.01.2012 04:00 > Feedback: Die Idee hinter dem Programm finde ich gut. Freut mich. > Mit so einem Tool könnte man eine Schaltung schön einfach testen, nach > dem Löten die .hex aufspielen und schnell mal ein paar Pins wackeln, PWM > ausgeben, ... Das ist nur ein Anwendungsbereich. Du kannst auch ein PWM für andere Schaltung ausgeben und diesen mit dem Mauscursor, anstatt mit einem Poti, verändern. Mit einem Poti und LCD-Anzeige wäre sowas bestimmt teurer und umständlicher. > Sehr nett wäre ein integrierter Bootloader, das wäre dann fast "JTAG für > arme" Was meinst Du damit? Ein Bootloader, der die Hex-Datei in den Flash brennt, oder die Hex-Datei selbst als Bootloader. > Aaaaaber: > - die Registrierung auf der Seite ist mal komplett unsinnig, wozu müssen > die Daten erhoben werden? E-Mail Adresse sehe ich ja noch ein, dann aber > bitte lokal auf der Seite und nicht über so einen dubiosen Anbieter. > Selbst der Link zum Anbieter führt über 4-5 Redirects, ich will garnicht > wissen wo eine E-Mail Adresse überall landet. Ich benutze die Zurzeit beste und sichere Anmeldungssoftware in Deutschland. Eine Email-Adresse reicht grundsätzlich vollkommen aus. Bitte die Hinweise unter dem Anmeldeformular durchlesen. 1.Sie erlauben mir, mit Ihrer Anmeldung bei meinem Newsletter, Ihnen regelmäßig eMails zuschicken, die Sie über den Verlauf dieses Programms (µC-PCC) informieren. 2.Ich gebe Ihre eMail-Adresse nicht an Dritte weiter ! 3.Mit nur EINEM Klick können Sie sich abmelden ! > - Empfehlungs-Funktion im Programm: Najaa. Meinetwegen, wäre aber in der > Hilfe oder Übersicht besser aufgehoben. 1/3 vom Bildschirm sind von > dieser Funktion blockiert, wo auch nicht klar ist wie die Mails > überhaupt verschickt werden... Sorry, wird noch geändert werden. Die Emails werden über meinen 1&1 Email-Server versendet. Es werden in diesem Fall keine Email-Adressen und auch die Nachrichten selbst nicht gespeichert. Bitte Hinweis durchlesen. > - Anonyme Daten-Erhebung: Was soll das denn? Feature-Wünsche oder > Kommentare lassen sich per Mail oder Forum viel besser übermitteln. Ja, das wäre schön. > Was nützt dir die Info, das 100 User 50x täglich mit deinem Tool den > AD-Wandler ein- und wieder ausschalten?! Bekommt der zugehörige Button > dann rundere Ecken, damit der Cursor nicht so hart anstößt? Zurzeit werden nur die Programm-Aufrufe erfasst. Wie schon gesagt muss ich wissen, wieviele Leute das Programm nutzen. Außerdem hilft es mir später Priorität bei der Entwicklung zu setzen. > Fazit: Man könnte auf die Idee kommen, hier soll mit einem Programm mit > minimalem Gegenwert irgendwie Geld/Ego/Klicks/Adressen gesammelt werden. > Wozu? Mein Ziel ist es mit diesem Programm allen Elektronikern da draußen zu helfen. Und wenn ich dabei ein paar Euros verdiene, dann ist es völlig in Ordnung. Noch habe ich nichts verdient. Und wenn das Programm keinem Menschen hilft, dann habe ich auch nichts zu verdienen. Es würde mich echt freuen, wenn hier jemand schreiben könnte, wie er oder sie das Programm konkret nutzt. Damit meine ich ein konkretes Projekt auf einem Steckbrett aufgebaut, beidem Du alle Taster und Schalter raus geschmissen hast und stattdessen den Mikrocontroller-PCC nutzt.
Gast
#2481094
Hi >Es werden die ATmega16 und ATmega32 vorerst unterstützt, weil diese am >meisten verbreitet sind. Nur bei Amateuren. Ich benutze schon seit ca. 14 Jahren AVRs und habe noch keinen von den beiden in einem Projekt benutzt. Am Anfang waren die zu klein und jetzt sind sie überholt. Also, wenn du dir noch keine Gedanken über die Erweiterung gemacht hast wird das Ganze, ohne deine Leistung in irgend einer Weise schmälern zu wollen, nur eine Programmierübung für dich bleiben. Für künftige Erweiterungen solltest du dir die Partdescription Files des 4er AVR Studios mal ansehen. Dort findest du die Informationen über Speicherausstattung, IO-Module, Registeradressen, Bitdefinitionen usw. der aktuellen AVRs. MfG Spess
Valentin Diring schrieb: >> wenn man das alles, was die Gui kann direkt über ein Terminal machen >> könnte, wäre das zur Benutzung in Skripten sehr nütlich. > Ich bin da anderer Meinung. Dank der GUI hast Du voll den Überblick. Sicher um mal ein paar kleine Sachen zu testen, ist es sicher gut. Wenn man den µC aber als verlängerten Arm des PCs benutzen möchte, ist es reichlich unpraktisch. >> Die SPI oder I²C über Gui macht zB nicht so viel Sinn. > Da bin ich auch anderer Meinung. wenn man dann aber in der Gui einzelne Bytes für komplexe Initialisierungen eintippern und absenden muss ist das unhandlich. Ebendso die Auswertung der Antworten > Mit I²C kannst Du z.B. ein EEPROM > (24Cxx) brennen. Stell dir vor, Du hast ein Projekt indem ein Tiny861 > einen 24Cxx EEPROM benutzt. Und Du willst wissen was passiert, wenn ein > bestimmter Wert erreicht ist, dann kannst Du diesen ganz gezielt > manipulieren (geplanter Feature). >> Ich hatte mal etwas ähnliches angefangen, was auf einem Tiny861 basiert, >> der Befehle per UART entgegennimmt. >> Ist aber, wie so oft nicht fertig, wird aber nach Bedarf erweitert > Schade, klingt aber sehr interessant. > Veröffentliche es doch, oder schick es mir bitte per Email. > Ich würde es mir gerne ansehen. wie gesagt, es ist erst in einem Stadium, in dem ich es selbst zwar benutze, in dem man es aber eigentlich niemand anderen zumuten möchte. Die Eingaben werden zB nicht validiert. Aber vielleicht setze ich ja wirklich mal einen Artikel auf - obwohl es von der Komplexität her nicht wirklich etwas weltbewegendes ist. Valentin Diring schrieb: >> Autor: Vlad Tepesch (vlad_tepesch) >> dank dieses tollen "Empfehle meinem Freund"-Blödsinns passt die Gui >> horizontal nicht auf meine (1680-Startleiste) Pixel, was unter anderem > Du kannst die Breite minimieren, diese wird dauerhaft abgespeichert. dann gibts ja aber Scollbalken. >> Die Gui könnte also deutlich kompakter sein. > Breite minimieren. Schick mir bitte ein Screenshot per Email. So könnte > ich das Programm an deinen Bildschirm evtl. anpassen. eine individuelle Anpassung macht ja nicht so viel sinn. Lieber alles unnütze rausschmeißen. Meine Verbesserungsvorschläge: - Die "Verbindung zum Mikrocontroller"-Elemente könnten in das PC-Schnittstelle-Fenster, das bei Programmstart automatisch geöffnet wird, sofern nicht das Häkchen fürs automatische Verbinden gesetzt ist. Der Verbindungsstatus gehört in die Statusleiste. - wenn Statusleiste keine wichtigen Infos bekommt, dann weg. Link in einen Hilfe/About-Dialog, oder ganz rechts in Menü - Den Freundes-Quatsch kann man, wenn man ihn unbedingt braucht ja auch ins About-Fenster verbannen, oder einen seperaten Dialog draus machen. - Kosmetik:Interne/Externe Peripherie als Tabs, die dann die Untertabs enthalten. - Analog Devices ist ein eingetragener Firmenname >> Der Impuls-Generator-Button wirklt auch fehl am Platz, den könnte man >> auch ins Menü packen, was ja auch als Buttonleiste misbraucht wird, da >> einige Menüeinträge direkt eine Funktion auslösen, anstatt, wie für ein >> Haupmenü üblich, erst mal ein Untermenü zu öffnen. > Ja, aber die Icons sind nicht üblich in der Menuleiste. in den sich öffnenden Untermenüs schon. Aber was spricht dagegen dem Generator ebenfalls ein Tab neben den anderen zu spendieren? eventuell auch neben den interne/externe Peripherie. >> wiso scrollt das Hauptmenü überhaupt mit hoch, wenn man vertikal scrollt >> (die Fenster-Startgröße ist kleiner als der Fensterinhalt? > Screenshot bitte. lässt sich doch einfach reproduzieren: veringere die vertikale Fenstergröße und scrolle dann hoch und runter. Menü und Statusleiste werden mitgescrollt. Und noch ein Bug: wenn man bei unverbundenen Controller in den Einstellungen rumklickt kommt ständig (je einmal nach verlorener Verbindung sollte reichen) ein Fehlerfenster, manchmal gibts aber auch eine unhandled Exception: zB unter Timer eine "Clock Select"-Option auswählen.
Valentin Diring schrieb: > Es würde mich echt freuen, wenn hier jemand schreiben könnte, wie er > oder sie das Programm konkret nutzt. Damit meine ich ein konkretes > Projekt auf einem Steckbrett aufgebaut, beidem Du alle Taster und > Schalter raus geschmissen hast und stattdessen den Mikrocontroller-PCC > nutzt. Darauf würde ich mal nicht setzen. Denn der Scharm eines µC besteht nun mal darin, dass er nach dem Anlegen der Versorgungsspannung sofort mit seiner Arbeit loslegt. Wenn ich da erst mal ein PC-Programm booten muss, um dem µC eine Reaktion zu entlocken, dann ist das nicht prickelnd. Was ich mir aber vorstellen könnte: Wenn der µC die übermittelte Konfiguration im EEPROM ablegt und nach dem Einschalten automatisch wiederherstellt, dann hätte das zumindest soweit einen Sinn, dass man sich mit dem µC 'Custom-Chips' bauen kann, die ohne externe Interaktion auskommen. Edit: Wenn ich genauer darüber nachdenke, ist auch das sinnlos. Ohne ein wenig Logik der Form "Wenn 'Eingang' dann 'Ausgang'" kommen wohl die allerwenigsten Projekte aus. Und wenn man eine Schaltung auf dem Steckbrett zusammengesteckt habe, dann schreib man auch schnell ein entsprechendes Test-Programm dazu. Recht viel mehr Potential als das Austesten einer Schaltung während oder unmittelbar nach deren Aufbau auf dem Steckbrett sehe ich ehrlich gesagt nicht in der Idee. Und selbst da seh ich bei den Nicht-Anfängern eher wenig Potential, weil ein angepasstes einfaches Erst-Programm schreiben nun mal schneller geht und letztenedes ohnehin nicht ausbleibt. Oder auf Deutsch: Es ist nett, wenn ich vom PC aus einen Portpin auf 1 stellen kann. Aber in der Praxis soll das dann doch eher passieren, wenn ein Taster oder eine Lichtschranke oder ein ADC Pegel oder .... einen entsprechenden Auslöseimpuls gibt.
Gast
#2481337
Hi Vor einiger Zeit hab ich mal etwas ähnliches vorgehabt und dank OOP auch realisiert. Ein Programm, um eine Logig-Schaltung zu erzeugen, mit Und, Oder, Flipflops usw. Schließlich sollte die Schnittstelle ein Controller sein. Bis dahin kein Problem, allerdings, und das ist genau der Tenor von KHB, macht es keinen Sinn, einen PC anzuwerfen um eine Steuerung damit zu betreiben. Ich denke, das wird später mal ein interessantes Rentner-Projekt, wenn ich weiß, wie externe EEProms gelesen und beschrieben werden, Dann ist es möglich, mit so einer grafischen Oberfläche eine Schaltung zu erzeugen und daraus eine Befehlsfolge im EEProm abzulegen. Aber auch die "kleine" Anwendung macht sicherlich Spass. Dabei möchte ich noch mal auf "OpenEye" verweisen, welches die Variablen in einem Controller zur Laufzeit sichtbar macht und damit bei der Programmentwicklung unter Assembler eine wertvolle Hilfe ist. Ich hab's hier irgendwo veröffentlicht. Gruß oldmax
ich sehe den Zweck eines solchen etwas eher als Werkzeug um andere Schaltungen zu entwickeln. zumindest war das von mir erwähnte TinyControl dazu gedacht. Wenn ich etwas baue, was auf bestimmte externe Signale wartet, die ich nicht zum Testen des Gerätes zur Verfügung habe, kann man die so scriptgesteuert vom PC aus generieren, ohne dass ich ein zweites Etwas auf dem Steckbrett aufbauen und dafür ebenfalls eine Software schreiben muss. Das und als billig-Scope oder eher als Datenlogger in Verbindung mit Logview (wenn hierfür jemand Alternativen kennt - gerne her damit). Der von Valentin angedachte Einsatzzweck als Bedienelemente-Ersatz erschließt sich mir auch nicht, da auf dem µC ja nix anderes Läuft, als die Lese/Schreibe-Register-Anwendung. Achtung, nicht zuende gedachte Idee: Da sollte man lieber eine Art Standard-Protokoll erarbeiten über das ein µC-Programm seine Parameter/Ausgaben kund tut und über das es Änderungen entgegennuimmt, sowie Messwerte übermittelt. Ein PC-Programm verbindet sich mit dem µC, ließt die Parameterliste und erzeugt Gui-Schaltelemente, die dann vom Benutzer angeordnet, konfiguriert und letztendlich bedient werden können. Vorteil: Unabhängig vom µC-Typ Als optionale Erweiterung für beliebige µC-Anwendungen definiertes Protokoll -> scriptbar Nachteil: Abhängigkeit vom PC recht viel Text auf µC-Seite -> Flashverbrauch
Gast
#2481612
Wenn es im Prinzip nur um Register/Ports lesen/schreiben geht, vor Jahren hab ich mir das mal aufgebaut: http://www.recursion.jp/avrcdc/cdc-io.html Über USB-CDC werden einfach Textbefehle wie:
1 | |
(setze PORTC mit FF) bzw.
1 | |
(lies PORTB) abgesetzt. So war mittels simpler GUI z.B. eine Sensorsteuerung über I2C möglich.
Gast
#2482286
Hi Ich hab euch mal einen "schnellen" Entwurf in VB angehängt. So in etwa könnte ich mir eine Bedienoberfläche für einen Controller vorstellen. So etwas funktioniert in der Simulation und sollte auf einem Controller in einer Art "Anweisungsliste" in den EEProm geschrieben werden. Die paar Bytes reichen allerdings nicht aus, so das ein externer EEProm angeschlossen werden muss, um eine einigermaßen umfangreiche Programmstruktur zu hinterlegen. So ein paar Checkboxen auf eine Oberfläche zu setzen und dann den IO-Registern zuzuweisen macht zwar Spass, ist aber keinesfalls anspruchsvoll. So, nun hab ich mal eine interessante Vorlage geliefert..... macht was draus. Gruß oldmax
super, du hast einen FPGA erfunden ;)
Gast
#2482764
oldmax schrieb: > Hi > Ich hab euch mal einen "schnellen" Entwurf in VB angehängt. So in etwa > könnte ich mir eine Bedienoberfläche für einen Controller vorstellen. So > etwas funktioniert in der Simulation und sollte auf einem Controller in > [...] > So, nun hab ich mal eine interessante Vorlage geliefert..... macht was > draus. > Gruß oldmax
Die Idee mit dem "verlängerten Arm eines PCs" finde ich hingegen interessant. Wenn es ein kleines C-Kommandozeilenprogramm oder python-Script gäbe, welches ein Register setzt
1 | |
oder einliest und als exitstatus
1 | |
2 | |
oder als Text auf stdout
1 | |
ausgibt, wäre das schon ne feine Sache. Rumgeklicke in einem, sorry, dot-würg Programm "zum Testen" brauch ich so direkt nicht wirklich. Wenn ich was zum Testen brauche, mach ich das direkt über die Serielle mit einem Terminalprogramm. mfg mf
> Autor: spess53 (Gast) > Datum: 02.01.2012 10:17 > Also, wenn du dir noch keine Gedanken über die Erweiterung gemacht hast > wird das Ganze, ohne deine Leistung in irgend einer Weise schmälern zu > wollen, nur eine Programmierübung für dich bleiben. Was haltet ihr von folgenden Erweiterungen: - Multi High-Speed ISP Programer (mehrere, hardware) - Mehrere serielle Schnittstellen emulieren (mit Hardware USARTs), integrierte Editoren parallel anzeigbar, ... - Variable Ladungspumpen - Schritt(motor) Ansteuerung - Spannungs- und Stromsteuerung - Akku-Ladegerät - Background-Prozesse (z.B. Akku-Ladegerät, etc.) - uvm.
Valentin Diring schrieb: > Was haltet ihr von folgenden Erweiterungen: > - Multi High-Speed ISP Programer (mehrere, hardware) > - Mehrere serielle Schnittstellen emulieren (mit Hardware USARTs), OK > integrierte Editoren parallel anzeigbar, ... > - Variable Ladungspumpen > - Schritt(motor) Ansteuerung > - Spannungs- und Stromsteuerung > - Akku-Ladegerät > - Background-Prozesse (z.B. Akku-Ladegerät, etc.) > - uvm. Geht für mich zu weit und ist das andere Extrem. Das ist schon nicht mehr das 'einfache', schnell benutzbare 'Schaun-wir-mal' Programm. Eine einfache Skripting Möglichkeit, bei der man dann auch kleine Logiken bauen kann, dann wäre für mich Ende der Fahnenstange. Alles weitere schreit dann schon förmlich nach einer direkten µC-Programmierung und da gibt es ja Programmiersprachen zuhauf. Das was oldmax da skizziert hat, das wäre das, wo ich hingehen würde (und auch getan hab, ich betreue das Frontend einer Firma die Gebäudeautomatisierung genau mit derartigen graphischen Editoren und zusammenstellen von Logiken durch Malen realisiert. Nur dass es dann da eben auch fertige Module auf höherer Ebene, wie zb PID Regler u.dgl. gibt)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.






