ZitierenDanke dir.Zitat von oberallgeier
Im Moment komme ich gut voran. Die initializer2.hex brauche ich auch nicht weiter zu zerlegen, da ich mittlerweile alle Infos zusammen hab, um den Coprozessor selbst programmieren zu können.
Flo
Stimmt Flo, das ist eine ziemlich gute Möglichkeit etwas gut zu machen - dass man sich den eigenen Blick nicht von bestehenden Lösungen beeinflussen lässt.
WENN ich zu meiner Testzeit der nibobee schon PFleury´s Help-Manual gekannt hätte, hätte ich so einen Aufbau ja den nicai-Leuten empfehlen können (wär aber sicher, wie manche andere Testkommentare untergegangen). Aber das ist ja immer so ne Sache mit dem wenn und dem hätt ...
Jedenfalls wünsche ich Dir viel Erfolg (Geduld, Überblick, einen guten Wirkungsgrad ...) für Dein Projekt - und bin mal gespannt
Ciao sagt der JoeamBerg
Danke dir.
Im Moment komme ich gut voran. Die initializer2.hex brauche ich auch nicht weiter zu zerlegen, da ich mittlerweile alle Infos zusammen hab, um den Coprozessor selbst programmieren zu können.
Flo
Hallo geekalert
Dass Du eine eigene NiboLib kreieren willst, finde ich ganz interessant; mir als NIBO2-User wäre daran gelegen, eine einfache Schnittstelle zum CoProz zu haben - sprich: man sollte den CoProz ALLEINE und unabhängig vom Hauptproz programmieren/flashen können - derzeit geht das ja nur über das initializer2-hex (mit der unterlagerten tool-chain boost-lib, hex2carray.c usw) und als "simpler user" habe ich leider keine Möglichkeit, den CoProz alleine zu programmieren (außer ich installiere die tool-chain...)
Also wenn Du da was "auf die Beine stellst", womit man problemlos den CoProz alleine programmieren kann - DAS(!!) WÄRE hilfeich!
Hero_123
Geändert von Hero_123 (18.12.2011 um 22:00 Uhr)
Hallo
ich kann mich der Meinung von Hero nur anschliessen. Es sind viele Sachen unklar. Da kommt so etwas gerade recht. Ich mit der Schnittstelle währe es sehr gut. Kannst uns ja ein bisschen teilhaben lassen an deinen Erfolgen. Mit Hero und mir hast du gleich die richtigen Tester gefunden. Bin gespannt was weiter kommt.
achim
Hallo geekalert
Lass mal sehen, wie Du das machst: "Für die Übertragung auf den PC werde ich erst mal WLAN verwenden, da ich die passende Hardware gerade rumliegen habe." => wie sieht da der Code aus, wleche HW verwendest Du denn?
Hero_123
Das Gerüst habe ich zwischenzeitlich schon mal in ein Inkubations-Projekt auf github gesteckt (https://github.com/falbrechtskirchinger/jdp-incubator).
Tatsächlich arbeite ich aktuell daran den Coprozessor zu programmieren. Neben mir sitzen momentan ein ATmega2560 auf einem STK600 und ein ATmega8 auf einem STK500. Ziel ist es den ATmega8 über den ATmega2560 zu programmieren. Kompliziert ist das ISP-Protokoll nun ja nicht. Ich rechne mal vorsichtig morgen Abend mit ersten Ergebnissen.
Nach erfolgreichem Test möchte ich dann Nibos Coprozessor selbst programmieren.
Später wäre es durchaus interessant den Coprozessor direkt vom PC zu programmieren. Da fallen mir spontan mehrere Möglichkeiten ein. Für den Anfang würden sich wohl IR + Bootloader auf dem Coprozessor anbieten.
Das WLAN-Modul stammt von Avisaro. War zumindest vor ein paar Jahren im Vergleich zu XBee noch unverschämt teuer, aber lohnt sich aus meiner Sicht, da ich nun von jedem PC/Smartphone aus darauf zugreifen kann. Angesprochen wird es über USART, SPI, I2C oder CAN. Die Datenrate ist jedoch mit maximal 1 MBit/s nicht berauschend.
Flo
Geändert von geekalert (18.12.2011 um 22:43 Uhr)
Tester sind immer gut. Allerdings muss ich betonen, dass ich ausschließlich unter Gentoo/Linux arbeite und meine Scripts darauf abgestimmt sind. Mittel- bis langfristig wird als Build-System CMake herhalten müssen. So wie schon für meine libat32uc3/libabl32. Das generiert dann auch Makefiles für z. B. Windows.
Ich bin nicht abgeneigt andre Plattformen zu unterstützen, aber optimaler Weise würde mir hier jemand mit CMake-Kentnissen aushelfen, der Zugriff auf die jeweilige Plattform hat. In erster Linie geht es darum, die Suchroutinen für die Toolchain anzupassen.
Worauf arbeitet Ihr denn?
Flo
Geändert von geekalert (18.12.2011 um 23:07 Uhr)
Hallo geekalert
Ich arbeite mit WIN7, habe da das AVRStudio4 4.18 Build 700 installiert, und damit programmiere ich den NIBO (mit UCOM-IR von nicai); ich habe CYGWIN als LINUX-Ersatz installiert - und natürlich den mingw; programmiert wird bei mir mit C.
Hero_123
Na mal sehen. Zum Testen kann ich auch prekompilierte Dateien erzeugen.
Mein ISP-Programmierer war gestern noch erfolgreich. Es geht also voran. Weiter möchte ich den Thread nun aber nicht Off-Topic führen. Sobald es mehr zu berichten gibt, mache ich einen eigenen Thread auf.
Flo
Hallo geekalert
Prekompilierte Dateien - wenn ich den kompletten SourceCode habe (alle *.c und alle *.h Dateien) kann ich mir doch selbst die Lib kompilieren (entweder mit dem mingw unter WIN7 oder mit dem GCC unter CYGWIN- wenn es in C geschrieben ist) - oder sehe ich das falsch und ich benötige ZUSÄTZLICH eine andere Lib?
Wie schon erwähnt - das für mich (und wahrscheinlich auch für viele andere Nibo-User) wirklich Interessante ist eine Möglichkeit, den CoProz ALLEINE programmieren zu können (was gehen würde, wenn die ISP-Schnittstelle des CoProz offen gelegt und mittels ISP-Programmer zu programmieren wäre); die NiboLib ist ja auch "OpenSource" (da ist ja immer der Source Code mit entsprechendem Makefile mit dabei - danke workwind!!), somit kann man sich ja selbst Programme mit dazu schreiben oder bestehende verändern (z.B den return-wert).
Einer der am häufigsten geäußerten Wünsche war eine bessere Kommentierung des Source Codes, denn was nützt der beste Code ohne Kommentar - diesen Code ohne Kommentar kann letztendlich nur der Ersteller lesen....
Hero_123
Berechtigungen
Lesezeichen