Hi @all, Vorwort: ich bin gerade dabei eine recht gut Dokumentierte Standart Ansammlung von Routinen in ASM für den ATMega8 zu basteln. In erster Linie habe ich mir diese gebaut um Sie in allen zukünftigen Projekten verwenden zu können. dennoch möchte ich diese auch später im Forum zur verfügung stellen, damit einigen der erste Anfang recht leicht fällt. In diesen Routinen habe ich Praktisch einen Hauptbereich und als Includes -> delay routinen, lcd hd44780 routine und eine DS18S20 routine. Ok genug jetzt dazu. Ich möchte natürlich meine LCD Routinen erweitern und zwar um die möglichkeit, LCD Texte zu Scrollen und einige Animations Spielereien?! Wer Lust hat seine Ideen mit zu verwirklichen nur zu :) Aber bitte nur in ASM. So um ehrlich zu sein, hab ich noch keine Idee wie ich einen Text z.b. von oben nach unten oder rechts nach links scrollen lassen kann. Ohne gleiche alle Zeilen shiften zu lassen. Gruß Dennis Brücke
Salut, da das Shifting nix anderes sein wird als ein verbogener DDRAM-Pointer, wird das gar nicht gehen. Wirst also nicht drum herum kommen, jedesmal den kompletten Stringausschnitt in den DDRAM zu schreiben. Für mich persönlich sind Projekte mit LCD-Ausgabe schon eher zu komplex für ASM... ich werde auch in Zukunft mit meinen HD44780-over-SPI C-Routinen arbeiten. Gruß, Mark
wärs nicht mal sinnvoll eine schöne lib sammlung zu machen... z.b bei sourceforge und dann per cvs das ganze zu verwalten??? wär glaub ich ganz sinnvoll.... nur müsste man halt schaun das man zu allen controllern kompatibel wird über defines... c oder asm is wurscht...einfach wrapper drüber dann schluckt der gcc eh alles ;) ich bin aber für c weil das einfach leichter auf neue controller zu porten ist... 73 de oe6jwf
Salut, wenn's da noch keine gute Anlaufseite im Web gibt, klar. Sag bescheid, falls Du das Projekt initiierst. Ich würde dann gern als Developer beitreten, wenn Du mich "rekrutierst". :) C wäre schon mal schön. Man sollte alle möglichen Arten von Interfaces mit reinmachen, und die dazugehörigen Schematics. Damit auch Anfänger damit zurechtkommen. Außerdem hätte man dann ne Referenzumgebung auf die man bei Nachfragen und Problemen verweisen könnte. Eben z.B. der Zugriff über SPI wäre eine Sache. Schon ne Idee für nen Projektnamen? Grüße, Mark
Hey, klingt auf jedenfall interessant... wenn Ihr nen Provider sucht... ich bin einer dabei ;) Gruß Dennis
Salut, das "4all" klingt mir persönlich etwas zu verspielt und zu unspezifisch (bei sf.net ist alles "4all"). Wie wäre "AtmeLCD", "LCD4AVR" oder einfach "AVR-LCD"? Oder wollen wir gleich ne Sammlung aller möglichen und unmöglichen Routinen für AVR anlegen - beginnend mit LCD? Dann sollten wir das LCD aus dem Namen raushalten. Den UNIX-Namen der Projekte kann man bei sf.net hinterher nimmer ändern. Grüße, Mark
Salut, also Andreas meint, im Wiki (http://wiki.mikrocontroller.net) wäre sowas besser aufgehoben. Und ich muß sagen, nachdem ich mir das Wiki mal angesehen habe... bevor wir jetzt nen sf-Projekt machen (Website muß auch gewartet werden), wäre es doch einfacher und praktischer, wenn wir diese Gelegenheit wahrnehmen. Hab mich noch nicht mit Wikis beschäftigt, habe das aber vor. Will auch hier bei µc.net bald mal was beisteuern. Mark
naja wiki schön und gut nur wirds mit sources eben lästig... ich bin für eine schöne lib wo alles mögliche drinnen ist... da sollte man sich mal im ircnet oder wo auch immer mal treffen und das mal bereden... nachdems AVRLib schon gibt müsste man sich einen schönen anderen namen suchen... das mit der page is das geringste problem yo libs..da könnte man sehr viel machen... UART lib für alle Atmels und voll config bar...so mit geschwindigkeit... senden/empfangen per int oder software... LCD wär auch weit ausbaubar.. also alphanum und grafik... spi werd ich mir heut noch anschaun wenn ich wieder wach bin weil ich mmc in nem projekt brauch ... dann noch das standart tools zeug was jeder irgendwas mal gebraucht hat... memcpy, ZeroMemory,... was man halt so vom pc her kennt ;) naja wie gesagt ich mach da gern den maintainer... und wies ausschaut sind eh einige leute daran interessiert... CVS dürfte eigentlich dafür gut geeignet sein.... docu kann man von doxygen einfach machen lassen... auf der page ist nicht viel zu machen wenn man das schön dynamisch machen tut..also infos udgl einfach per mysql rausfischen ausserdem teilt man das dann in teilbereiche auf und dann ist es pro person auch nicht mehr die welt... das mit der keine gute anlaufseite für einsteiger mag stimmen.. vor allem wenn man noch überhaupt nichts mit µCs gemacht hat sind die datenblätter zuerst mal richtig unüberschaubar was aber dann mit der zeit zur idealen info-quelle mutiert... naja man müsste sich da eine schöne lib basteln die mehr oder minder alle stückerl spielt... 73 de oe6jwf | hans
Hmm, da hab ich ja was entfacht.... trotzalledem, eigendlich wollte ich nur eine Sammlung von Sourcen & Ideen in ASM... für C bzw. GCC gibt es doch schon eine Menge an Daten. Ich möchte keine extra seite aufbauen muessen oder cvs repo. aufbauen. Sondern diese Sammlung sollte dem mikrocontroller.net für´s tutorial zur verfügung gestellt werden... sonst ist doch wieder das gleiche problem wie so gut bei jedem projekt... eine menge an seiten wo man sich nur bruchteile zusammen suchen kann... und das ist doch nicht mittel & zweck... der sache Gruß Dennis Brücke
Salut, genau meine Meinung. Tutorial ist eine Möglichkeit. Wiki eine andere. Gegenseitige Links wohl die beste. Mark
Hi Mark, danke erstmal auf deine Antwort im andere Thread auf die GLCD´s suche zwar immer noch... :( Ok jetzt hierzu, links finde ich persönlich nicht so gut, weil sie leider allzu oft auf GCC verweisen... was ich sehr schade finde, weil ich ASM besser finde... einfach mal um besseres Verständniss über die CPU zu vermitteln... Von Wiki halte ich eigendlich gar nichts... Also wie gesagt bin halt immer noch für die Variante Tutorial, denn die Tutorials von mikrocontroller.net sind wirklich für einen einsteiger bisher sehr gut gehalten, und weichen nicht auf bascom oder gcc aus. Leider fehlen halt noch einige dinge wir Timer geschichten... oder halt was mein problem ist wie bringe ich ein LCD Text zum scrollen... sprich eine Animierte Menüführung. Habe jetzt schon einiges an Routinen zusammengebastelt, die bis ins feinste Detail Dokumentiert sind, um diese halt einfach zur verfügung zu stellen. Ob sie in irgendeiner Form dann im Tutorial landen obligt dann halt Andreas. Ich finde es halt immer schade, das wenn ein gemeinschafts Projekt wie z.b. mikrocontroller.net immer wieder dazu ausartet, das jeder gleich am liebsten eine eigene seite aufbaut... naja dann hat man halt eine unzählige Link sammlung und unzählige seiten... nur ob diese dann noch hilfreich sind ?! Ich hatte erst vor kurzem das blöde problem wie bringe ich bin->bcd die antwort lag eigendlich vor meinen Augen, habe aber immer nach den begriff gesucht binär auf lcd ausgeben... naja und hat halt ne weile gedauert bis ich drauf gekommen bin... Hoffentlich Denkt keiner das ich gegen GCC bin oder Bascom das ist nicht der fall, alles relativ mächtige sprachen, nur vermitteln diese halt dem EINSTEIGER nicht wie das Display z.b. wirklich angesteuert wird... denn man hat ja Lib´s und das ist halt der grund warum ich für ASM bin. Gruß Dennis Brücke
sagt ja keiner was gegen asm... aber ich bin der meinung ein schönes CVS wo alles halbwegs vernünftig abgelegt wird (in dirs) und mit kleiner beschreibung dazu bringt mehr wie ein tut wie sie hier sind... nichts gegen die tuts aber jemand der weis was er haben will sucht einfach zu lange also könnte man ja eine lib machen... wie die avrlibc nur eben abgespeckt und als reine source lib (damit sie eben schön klein bleibt) ob man dann in der makefile sich eine asm komponente oder eine c Lib rein holt is doch wurscht finde ich... nur wärs mal wichtig, dass man irgendwo die ganzen libs die schon herumschwirren irgendwie zusammenträgt... avrfreaks.net ist schon soo überladen das man wenn überhaupt nur die appnotes verwenden kann... und ich glaube cvs ist dafür wirklich fein..kann jeder was hinzufügen, jeder kann saugen und hin und wieder macht man ein package (ala linux ;) die idee mit dem wiki schön und gut aber was bringt es dir dort bildchen und irgendeinen code rein zu tun wenn das nur dumm upzudaten ist... 73 de oe6jwf | hans
Hi, ich gebe Dir auf jedenfall recht mit dem CVS, wir sollten vieleicht unterscheiden, zwischen. Anfänger & Fortgeschrittenen. Tutorials -> Anfänger ;) CVS -> Fortgeschrittene. Finde beide Ideen auf jeden fall Ausbaufähig. Gruß Dennis
naja ich meine das muss hand in hand gehen... also cvs tree für die code uploads... hin und wieder werden einfach mal sources komplett gepackt und schön veröffentlicht... dazu kommt noch eine doku die eben tutorial-like ausschaut... und dem zugrunde liegt einfach der source vom cvs ist glaub ich das sinnvollste... und so wies ausschaut gibts auch genug leute die sowas befürworten und vor allem die mitmachen würden... auf jeden fall bin ich der meinung das man nicht nur reine hardware-libs machen sollte sonder auch so sachen wie string manipulation, ringspeicher,... damit haben anfänger die möglichkeit gleich schöne libs zu haben und wenn man was spezielles haben will gibts eh noch die möglichkeit da was reinzupatchen ;) auch wenn viele meinen als anfänger sollte man alles selbst machen so bin ich der meinung wenn man nicht weis was es tun soll und wie es ungefähr funktionieren ist es unmöglich was zu machen... wenn man das ganze auch noch als open hardware projekt betrachen würde... da ließe sich sicher viel machen... und so basic board mit layout usw ... wär sicher eine gute sache...ich weis wie es ist kein reference-layout zu haben und dann fliegend 1-2 lagen über das board drüberzubaun nur um zu schaun wies besser wäre... 73 de oe6jwf | hans
Hi, kurz und knapp gesagt, da gebe ich Dir recht :) Gruß Dennis
gut dann sind wir ja mal zu 2. ;) jetzt noch einen namen finden und los gehts ;P 73 de oe6jwf | hans
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.