Logo, es gibt ja Leute, die das kaufen...müsste es bei Tiny auch gehen..
Aber re-entrante / rekursive Subs bist du ja eh' nicht gewöhnt, soweit ich mich and die PICerei erinnere.
Wenn ich aber diszipliniert, wie beim ASM, programme schreibe, dass immer nur eine SUB laufen wird und erst nach ihrer Beendigung nächste aufgerufen wird, müsste es bei Tiny auch gehen, oder ?
MfG
Logo, es gibt ja Leute, die das kaufen...müsste es bei Tiny auch gehen..
Aber re-entrante / rekursive Subs bist du ja eh' nicht gewöhnt, soweit ich mich and die PICerei erinnere.
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Hallo PickNick!
Ich musste mich bisher nur beim PC ASM in *.exe Programmen für Stapel interessieren. Der BASIC Compiler hat beim ersten Durchlesen des Programms dafür nötige Anzahl von Speicherstellen reserviert und nur beim nicht ausreichendem RAM mich darüber informiert.
Bisher kann ich wirklich das mit der RAM-Grösse und Stapel-Deklarationen bei Tiny AVR's mit 64 Speicherstellen nicht verstehen. Mir würde eine Information ausreichen, wieviel Speicherstellen ich für mein Bascom Programm zur Verfügung habe. Kann ich davon ausgehen, dass bei Programm ohne Interrupts ich 32 von 64 Bytes frei habe ?
Na ja ich probiere es mit "grösseren" Tinys aus, aber wenn ich länger im mit Bascom erstellten Programm unverständliche Fehler z.B. wegen Stapelüberlauf suchen müsste, dann bleibe ich lieber bei ASM in der PICerei.
Es ist eben für mich sinnlos zu versuchen sich selbst an unbeherrsbare Programmiersprache anzupassen.
MfG
Dann mal Tacheles: welchenen TINY hast du nun im Auge ?
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Als 8 Pin Chip kommt für Bascom vor allem der Tiny25 oder Tiny45 in Frage. Da hat man auch kein wirkliches Problem mehr mit dem RAM. 128 Bytes sind nicht viel, aber es reicht auch für Interrupts.
Vor allem Interrupts brauchen in Bascom sehr viel RAM (32 Bytes ?), wenn man da nicht mit ASM nachhilft.
Die Tiny12, Tiny13 programmiert man doch eher in ASM.
Edit: Auch bei den PICs gibt es Errata. Die meisten Fehler bei den AVRs sind nicht so schlimm - es sind vor allem auch fast die gleichen für alle Typen. Schlimm wird es mit den Erratas erst bei dem XMega oder dsPic.
Hallo
Mit dem Tiny13 kann man schon recht nette Sachen machen, z.b. eine RC5-Fernbedienung in Bascom:
https://www.roboternetz.de/phpBB2/ze...=339977#339977(Code)
https://www.roboternetz.de/phpBB2/ze...=339889#339889(Bilder)
Mein Kippler lief auch mit einem Tiny13, allerdings in C:
https://www.roboternetz.de/phpBB2/ze...=326492#326492
Geschwindigkeitsnachteile von Bascom kann ich nicht bestätigen, hier die Bascom-Variante meines Kameraprojekts:
https://www.roboternetz.de/phpBB2/ze...=434314#434314
Viel Erfolg.
Gruß
mic
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
BASCOM muss nicht langsamer sein, kann es aber. Eine Ursache für die Teils geringere Geschwindigkeit in Bascom liegt darin dass man immer nur eine Rechenoperation in eins machen kann. Die Daten gehen entsprechend immer zwischendurch in RAM, etwa so als würde man in C alle Variablen Volatile machen - nur noch etwas schlimmer. Wenn Bascom spezielle Funktionen nutzen kann - geht es damit ggf. auch schneller und kürzer.
Eine weitere Bremse hat (oder hatte man zumindest) man bei Interrupts. Da werden immer fast alle Regeister gerettet. Das kann schon auch von der Geschwindigkeit stören, nicht nur durch den extra RAM-bedarf.
Die meisten Programme sind aber auch gar nicht Zeitkreitisch.
Wenn ich das hier so lese, bekomme ich den Eindruck, dass die Meinung besteht, dass Bascom generell laaaangsaaaamen Code erzeugt. Bis auf ganz wenige Ausnahmen (z.B. GetRC5) kann ich dem so nicht zustimmen. Lediglich ist der erzeugte Code oft (aber nicht unbedingt) größer als bei C.
Zeitkritisches "Multitasking" wie IR-Empfang, Auswertung, 3-Kanal SoftPWM, RDS-Radio und Netzwerk gleichzeitig löse ich allerdings "zu Fuss". Aber auch dann im Bascom Dialekt. Inline Assembler nutze ich entweder um den Watchdog innerhalb der ersten 4 Takte zu deaktivieren oder um die Interrupts schneller zu durchlaufen, wenn ich mir die gewünschten Register manuell auf den Stapel schiebe und zurückhole.
Auch die Frontendprogrammierung auf T-Hack habe ich mit Bascom in Basic erstellt.
C nutze ich nur, wenn ich das Rad nicht neu erfinden möchte und fertigen Code dritter an meine Bedürfnisse anpasse.
Wenn das Herz involviert ist, steht die Logik außen vor! \/
Hallo!
Um nicht überglucklich wegen Bascom zu werden, hatte ich heute ein Besuch beim Zahnarzt. Zum Glück kann ich noch schreiben.
@ PickNick
So wie der Besserwessi vorgeschlagen hat, bloss wegen 2 V Versorgung eine V Version.
@ radbruch
Als Anfänger kann ich leider die tolle Programme noch nicht bewundern.
@ Besserwessi und peterfido
Ich weiss nur sicher, dass ASM ein bisschen schneller als durch jede Hochsprache erzeugter Code ist. Aber wegen zu schnellem Bascom Code dürfte der AVR in meinem Spielzeug nicht abfackeln, oder ? [-o<
MfG
Hallo PICture!
Wenn Du gern die neueren Tinys nehmen willst und auf ein Experimentier-
boad verzichtest, dann bau das Dongle mit dem 74HC125 in den
LPT-Stecker. So hab ich das gemacht, da ich die Programme woanders
(auf meinem Experimentierboard) entwickelt habe. Wenn die Pins,
welche für MISO, MOSI und SCL benutzt werden, möglichst an hochohmiger Peripherie hängen - meistens sind sie dann Ausgänge -
kannst Du problemlos in der Schaltung per ISP flashen.
Obwohl ich ASM nicht beherrsche - trotz Versuch nicht geschnallt und
mit Bascom erschlage ich eh alles - habe ich grossen Respekt vor den
Leuten, die ASM beherrschen. Bei Dir PICture, bin ich überzeugt, dass
Du in kurzer Zeit kein AVR-Anfänger mehr bist, das beweisen Deine
Beiträge, die sich immer auf hohen und kameradschaftlichen Niveau
befinden. VG Micha
Lesezeichen