hallo forianer, ich habe ein kleines problemchen mit dem tiny. ich habe eine kleine schaltung gemacht, die ein 0...10V signal einlesen soll (adc) und dann seriell raustelefoniert. hardware steht mit dem tiny15L, led blinkt auch schon, nur leider kann ich keine variablen initialisieren. habe bislang nur mit dem tiny26 gearbeitet, macht der 15 irgendwas anders ? beiliegender code schmeißt irgendwas mit "not possible with $tiny" raus, ich programmiere auf bascom (gekauft) 1.11.7.7 any ideas ?
Im Gegensatz zum Tiny15 besitzt der Tiny26 etwas SRAM. Vielleicht liegt es daran.
aber mit der anweisung $tiny sollte es doch gehen ? oder was verstehe ich daran nicht ? :o) Action Instruct the compiler to generate initialize code without setting up the stacks. Syntax $TINY Remarks The tiny11 for example is a powerful chip. It only does not have SRAM. BASCOM depends on SRAM for the hardware stack and software stack. When you like to program in ASM you can use BASCOM with the $TINY directive. Some BASCOM statements will also already work but the biggest part will not work. BASCOM will support a subset of the BASCOM statements and function to be used with the chips without SRAM. There will be a special tiny.lib that will use little registers and will have at most a 3 level deep call since tiny chips do have a 3 level deep hardware stack that may be used for calls. Note that the generated code is not yet optimized for the tiny parts. The $tiny directive is just a start of the tiny parts implementation! No support is available for this feature until the tiny.lib is implemented.
mmmhh... weißt du das, weil du es weißt oder rätst du ? :o)) ich schreib mal an bascom...
Ich weiß es, weil du die "Jungs" oben zitiert hast. Du kannst den Controller in Assembler problemlos programmieren. Scheinbar auch per BASCOM-(inline-)Assembler.
naja, meine bascom-version ist veraltet, leider kann ich über den dummen updatemanager nicht updaten, das sperrt unser zentralistisches konzernnetz. nu habe ich gerade mal an mcselec geschrieben, wie ich an ein update komme.
mmhh... das sieht nicht gut aus, da werde ich wohl inline assembler machen müssen. könnte mir da jemand einen tip geben ? ich muss einen analogwert zwischen 0...2,55V einlesen und diese variable an einem softuart raustelefonieren. in bascom habe ich das auf dem mega schon oft gemacht, aber noch nie in assembler. kann mir da jemand ein paar tips geben ?
Assembler-Beispiele sollte es im Datenblatt zum Tiny15 geben. Eine SoftUART hat Atmel als ApplicationNote veröffentlich. Wenn es nur ums Senden geht, ist das nicht mal dolle schwierig.
Übrigens würde ich mir in diesem Fall den Umweg über Bascom sparen und gleich in Assembler programmieren. Als hilfreiche Internetseite hat sich da www.hanneslux.de erwiesen.
oder Tiny13. Aber das bisschen Assembler ist doch auch nicht die Welt, das bekommt man noch mit copy&paste aus den app.notes von Atmel zusammen.
aber die tiny13 und 45 und 85 werden doch von bascom garnicht unterstützt oder doch ? naja, den adc habe ich schon am laufen mit inlineassembler, aber im moment wühle ich mich durch die avr305 app note wegen des seriellen sendens. wenn man sonst nie assembler macht, ist es schon etwas nervig :)
so siehts im moment aus, ich habe nur den senden-teil der app note eingebaut. irgendwas sendet er auch, zumindest habe ich am ausgang ein high mit zyklischer null alle 500ms. gebe ich allerdings eine spannung auf den adc, ändert sich..... nichts :) ich forsche mal weiter und bestelle parallel den tiny13, denn mit meiner soeben bekommenen neuen bascom version wird der ja unterstützt froi dann klappts auch in bascom. trotzdem entwickelt man ja einen gewissen sportlichen ehrgeiz, das nun auch in asm hinzubekommen.
Hast du den Oszillator auf 1,6MHz calibriert? Oder tuckert der irgendwie mit umbekanntem Takt vor sich hin? Wobei ich UART mit RC-Oszillator sowiso für Roulett halte. Nimm lieber einen AVR mit Hardware-UART und Baudratenquarz, das erspart viel Ärger. ...
jop - wobei das (noch) nicht not tut, denn er macht noch nicht viel. ein hardwareuart lohnt eigentlich nicht: die schaltung soll lediglich circa (!) alle 20ms ein (!) byte raustelefonieren und das immer wiederkehrend. nicht zuhören, nicht prüfen, nix. nur rausschieben. fehlererkennung macht der empfänger. ausserdem passt ausschließlich ein 8pinner in den gewählten subd-stecker, der bauraum ist also arg begrenzt.
Ich vermute, dass das nicht so hinhaut, wie es hinauen soll, liegt an Bascom (soll jetzt keine "Bascom-Hass-Kritik" sein). Bascom stellt sich ja beim Sprung in Subroutinen immer etwas mädchenhaft an und sichert erst mal alle Register und was weiß ich noch alles. Die Anwendung schreit ja förmlich danach, sie komplett in Assembler zu machen. Schliesslich hast du Assembler (wenn auch Inline) ja jetzt schon verwendet. Ich gehe davon aus, dass du das auch so (mit etwas Hilfe vielleicht) in Assembler hinbekommst. Sooo aufwändig ist die Aufgabe nicht.
edit bascom ist halt für mein sonstiges aufgabengebiet (steuerbüchsen und benutzerinterfaces mit displays) echt super, aber für solche sachen einfach gelöscht *grrr*
könnte mir denn vielleicht jemand auf die sprünge helfen, wie überhaupt ein solches programm anfängt ? assembler ist so lange her... funktionalität ist ja klar, ich bräuchte also eine ca. 10ms zeitschleife, serielles rausschieben (wenn die appnote funzt, habe ich die ja) und einlesen am ad...
Angehängte Dateien:
-
int010.jpg
400 KB
hier nochmal der schaltplan - wäre toll, wenn jemand mir da zumindest mal auf die sprünge hilft, fehler suchen kann ich dann sicherlich selber ;)
Guck doch mal bei www.hanneslux.de vorbei. Und dann vielleicht noch ins AVR-Tutorium auf dieser Seite.
> Guck doch mal bei www.hanneslux.de vorbei.
Aua-ha...
Gleich zweimal (jetzt dreimal) in einem Thread???
Gut, wie man ein kleines ASM-Programm für Tiny15 strukturiert, kann man
da schon finden, wie man der Timer konfiguriert und nutzt, findet man
auch, ebenso den Umgang mit dem ADC. Aber mit Software-UART in ASM
findet man da mit Sicherheit nix.
Duck & wech...
...
>Aber mit Software-UART in ASM >findet man da mit Sicherheit nix. Dann wird das aber mal Zeit! (duck und wech in die andere Richtung)
Irgendwie mache ich gerne Werbung für deine Seite. Du machst das je nicht mehr so dolle. Übrigens gibt es für die SoftUART ja die ApplicationNote (zweite bis dritte Erwähnung...).
> Du machst das je nicht mehr so dolle. Stimmt... Seit der Diskussion um den obligatorischen Link auf IBWeißDerGeier.de verweise ich nur noch auf meine Seite, wenn dort die Lösung des Problems zu finden ist. Und das auch nur dann, wenn es noch niemand Anderes getan hat. ;-) Nun nochmal zur Schaltung. Die RTFs habe ich mir nicht angesehen, dieses Format öffne ich online nicht. Aber int010.jpg verstehe ich nicht ganz. Da werden einige Pins des SubD-Steckers (Buchse?) direkt mit AVR-Pins verbunden... Die Pegel auf SubD-UART sind +/-15V (mindestens +/-9V), ich glaube kaum, dass der AVR das mag. ...
>Seit der Diskussion um den obligatorischen Link auf IBWeißDerGeier.de >verweise ich nur noch auf meine Seite, wenn dort die Lösung des >Problems zu finden ist. Und das auch nur dann, wenn es noch niemand >Anderes getan hat. ;-) Das ist ja nun (zumnidest für mich) ein kleiner Unterschied: Auf deiner Seite sind interessante Sachen wie Anhänger-Rangier-Geräte-Konstruktionen oder auch eine Menge Code-Beispiele zu finden, die auch noch kommentiert sind. Auf der IBinteressierteigentlichniemandenmussaberinsNetz.de-Seite finde ich das alles nicht. Das ist einfach nur eine Werbe-Seite für ein IB (hat Ähnlichekeiten mit IBM, wozu mein Prof nur meinte "Invented By Monkeys"). oder habe ich da etwas übersehen?
die appnote habe ich ja bereits in arbeit, den rest suche ich mir schon irgendwo zusammen... @hannes: ja, das schaltbild siehst du richtig, aber wie kommt ihr darauf, das, nur weil es ein 9poliger subd stecker/buchse ist, da auch ein rs232 pegel drauf liegt ? der stecker stellt einen steuereingang für eine gerade entwickelte steuerelektronik dar und die hat eine eigens von mir ausgedokterte steckerbelegung und ein entsprechendes protokoll... :o) also in der hardware sind keine fehler, dafür übernehme ich die garantie. nur dieses asm gewürge ist halt nicht mein ding :o/
OK... Nur bei SubD9 und UART ergibt sich ein zwangsläufiger Zusammenhang. Denn meist wird UART zur Kommunikation mit dem PC benutzt. Dass das bei dir anders ist, ist nicht die Regel, sondern die Ausnahme. Vielleicht solltest du darauf hinweisen, denn diese Info ist bedeutend wichtiger als der Hinweis, dass Tiny12 und Tiny15 zwei I/Os vertauscht haben. ;-) Das ASM ist aber kein Gewürge, alle benötigten Infos findest du im Datenblatt bzw. dem AVR-Instruction-Set, das ich für einen ausgelagerten Teil der Datenblätter halte. Man hat also Programm (AVR-Studio) und Informationsquellen aus erster Hand (ATMEL) und ist nicht auf irgendwelche Drittanbieter angewiesen. Dazu ist das auch noch kostenlos, auch dann noch, wenn die Programme größer werden. Ein weiterer Aspekt ist die Nachvollziehbarkeit des Codes, man kann zu jedem Code leicht die benötigte Rechenzeit überschauen (Takte zählen). Also ich persönlich halte AVR-ASM für überschaubarer als BASCOM, obwohl ich seit über 15 Jahren in mehreren BASIC-Dialekten programmiere. Auch Projekte mit Menü und LCD sind in ASM kein Problem, wie du am Stoppuhr-Projekt und am Feuerwerks-Zünduhr-Projekt sehen kannst. Es hat sogar den Vorteil, dass man nicht mit "fremden" Bibliotheken arbeitet (was Vertrauen zum Anbieter dieser Libs voraussetzt), sondern mit selbstgeschriebenen Routinensammlungen, die man wenigstens versteht und bei Bedarf an andere Bedingungen anpassen kann. Was man für "Gewürge" hält, ist immer subjektiv. für mich persönlich ist es (trotz fundierter BASIC-Kenntnisse) BASCOM. Aber wie gesagt, für mich persönlich. Wenn du mit diesem Baukasten zurecht kommst und dir die mitgelieferten Bausteine reichen, dann ist ja gut... Viel Erfolg... Bit- & Bytebruch... ...HanneS...
ja, schon klar, ich weiß schon, was du meinst. nur wenn man halt nicht "drinsteckt", ist es halt schwer, auf die schnelle eine lösung zu finden. in bascom ist die ganze sache eigentlich ein 5zeiler, und wenn ich nichts zeitkritisches habe, kann ich damit hervorragend die aufgabenstellungen lösen, zumal wir bei den meisten projekten ausreichend rechenpower und ressourcen haben (m128 etc). nur bei dieser einen adapterkiste muss es halt klein sein und schnell fertig, deswegen hänge ich ein wenig durch :) mein kollege könnte das auch schnell auf dem pic machen, der macht nur asm, kennt aber die atmels überhaupt nicht. zudem hat der in frage kommende 8pinner pic keine interne referenzspannung und die passt nicht mehr auf das pcb drauf :)
Tja, wer es gewöhnt ist, mit Kanonen auf Spatzen zu schießen, der kommt schnell ins Schwitzen, wenn er mal ein effizientes Programm schreiben soll... - Sorry... Da ich mich aber noch nicht mit Software-UART mit automatischer Baudraten-Anpassung beschäftigt habe, kann ich dir leider nicht helfen. Denn mit einer fest berechneten Baudrate wird das ein Lottospiel, weil der interne RC-Oszillator für UART zu ungenau/instabil ist. Vielleicht kannst du ja eine andere Form der seriellen Kommunikation nutzen (also kein RS232-Protokoll). Schau dir mal das Zünduhr-Projekt an und untersuche mal die Datenübertragung von der Zünduhr zu den Endgeräten. Dies ist auch eine serielle Datenübertragung, wobei die Information im Tastgrad steckt. Da sich die Timer bei jedem Bit synchronisieren, sind Taktabweichungen von über 30% kein Problem. UART würde da schon schlapp machen, da die Timer sich nur einmal pro Byte (zu jedem Startbit) synchronisieren. ...
mmmh :) ein gutes pferd springt nicht höher, als es muss. für mich bedeutet effizientes programmieren eben nicht, minimalistische software zu produzieren, welche auf dem kleinstmöglichen prozessor läuft (so etwas macht mein kollege... :o) ), sondern wie effizient ich mit den gegebenen möglichkeiten ans ziel komme - das ist bei den meisten meiner aufgabenstellungen eben bascom und ein dicker proz, bei welchem ich nicht lange überlegen muss, ob da irgendwas dran fehlt. ausserdem wird von unseren kunden immer viel nachgeflickt, dann will ich nicht immer an der hardware schrauben müssen, nur weil mir ein pin oder etwas speicher fehlt. zum thema: nun, da ist folgendes problem: der empfänger ist ein serienteil und somit nicht "mal eben" zu ändern. der wartet auf dem port und liest genau ein byte seriell ein. kommt innerhalb einer zeit x der gleiche wert, nimmt der empfänger diesen als sollwert. ich will also mal mutmaßen, das es herzlich egal ist, wie genau der uart läuft, solange er bei der übertragung von 10 einzelnen bits noch keinen großen mist baut. die regelvorgänge bewegen sich im sekundenbereich, also hat er ein paar übertragungen zeit, den neuen sollwert rauszufinden.
habe jetzt den (pinkompatiblen) tiny13 eingesetzt und die sache mit 15 zeilen bascom inklusive allem am laufen. in assembler mache ich das nochmal, wenn mir wieder langweiliger ist :) danke trotzdem allen für die tips, ich sehe ein, das ich nicht umhinkommen werde, mich mal wieder öfters mit assembler auseinanderzusetzten.
Eigentlich stehts doch eindeutig da: BASCOM benötigt SRAM für den Stack, es gibt da auch ein nettes Büchlein zu dem Thema (Claus Kühnel), der Name fällt mir gerade nicht ein, aber da wird auch auf diesen Umstand hingewiesen..
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.