Bascom und Tiny 45

[hrei]

Hallo,

um Anwender von Bascom in Verbindung nicht in die selbe Falle tappen zu lassen, in der ich ein paar Stunden zugebracht habe, folgender Hinweis:

Die Regfile ist noch etwas buggy.

Ich wunderte mich, warum Subroutinen, die seit langem bei mir auf M32, M8 und sogar M168 klaglos laufen, plötzlich völlig unsinnige Ergebnisse ausspuckten. Meine ursprünglich Vermutung ich würde bei den Stacks bzw. der Framegröße Fehler machen, bestätigte sich nicht.

Des Rätsels Lösung:

Immer wenn eine Multiplikation mit einer Variable als Operand im Spiel ist, muss die Variable als Long definiert werden, auch wenn das Ergebnis locker in ein Word oder sogar Byte passen würde.

Beispiel:

Dim Test as Word

Test = 2*3 geht

Test = 2
Test = Test * 3 geht nicht. Resultat ist immer 0.

Wird hingegen Test als Long dimensioniert, geht auch letzteres Beispiel.

Das klingt einfach, es hat mich aber tatsächlich Schweiß gekostet den Fehler zu finden. BTW: Alle anderen Rechenoperationen laufen hingegen klaglos.

Bevor jetzt das Geschrei anhebt: "Bascom taugt eben nichts" sei darauf hingewiesen, daß der Tiny 45 neu ist und noch nicht lange in nennenswerten Stückzahlen angeboten wird. Insofern ist es eher erstaunlich, daß es überhaupt schon eine Regfile gibt.

Grüße
Henrik

[oe9vfj]

Hallo Henrik,

ich habe die Frage zwar schon bei Deinem Parallel-Post http://www.mcselec.com/index2.php?option=com_forum&Itemid=59&page=viewtopic&t=1125 auf dem MCSELEC-Forum beantwortet, möchte aber hier noch kurz darauf eingehen, damit andere Tiny45 Anwender beim gleichen Problem dieses umgehen können.
Gemäß Datenblatt von ATMEL http://www.atmel.com/dyn/resources/prod_documents/2586S.pdf hat der Tiny45 keine Hardware Mulitplizier ASM Befehle. Im BASCOM DAT File für den Tiny45 ist aber der entsprechende Parameter HWMUL=1, d.H. der Compiler geht davon aus, dass der Prozessor HW-Mul unterstützt und bindet die entsprechenden Routinen ein was natürlich auf der Hardware nicht funktioniert.
Ändere im File ATTiny45.DAT die Zeile mit HWMUL auf
HWMUL=0, dann müssten die Multiplizierbefehle für Byte und Word/Integer funktionieren. Da mit der derzeiten Version die HW-Mul Unterstützung für Byte und Word/Integer implementiert ist, aber noch nicht für LONG, wird für LONG die normale bisherige Routine verwendet und daher funktioniert LONG bei diesem falschen Parameter.

[hrei]

Hallo Henrik,

ich habe die Frage zwar schon bei Deinem Parallel-Post http://www.mcselec.com/index2.php?option=com_forum&Itemid=59&page=zeigebeitrag&t=1125 auf dem MCSELEC-Forum beantwortet, möchte aber hier noch kurz darauf eingehen, damit andere Tiny45 Anwender beim gleichen Problem dieses umgehen können.
Gemäß Datenblatt von ATMEL http://www.atmel.com/dyn/resources/prod_documents/2586S.pdf hat der Tiny45 keine Hardware Mulitplizier ASM Befehle. Im BASCOM DAT File für den Tiny45 ist aber der entsprechende Parameter HWMUL=1, d.H. der Compiler geht davon aus, dass der Prozessor HW-Mul unterstützt und bindet die entsprechenden Routinen ein was natürlich auf der Hardware nicht funktioniert.
Ändere im File ATTiny45.DAT die Zeile mit HWMUL auf
HWMUL=0, dann müssten die Multiplizierbefehle für Byte und Word/Integer funktionieren. Da mit der derzeiten Version die HW-Mul Unterstützung für Byte und Word/Integer implementiert ist, aber noch nicht für LONG, wird für LONG die normale bisherige Routine verwendet und daher funktioniert LONG bei diesem falschen Parameter.

Hallo Josef,

jupp bereits dankend gelesen.

allerdings missinterpretierte ich das Datenblatt etwas ...

"Some implementations of the
architecture also provide a powerful multiplier supporting both signed/unsigned multiplication".
and fractional format"

hielt ich für eine Form der Hardwaremultiplikationsunterstützung.

Wie dem auch sei, Dein Tip funktioniert, wenn auch zu dem Preis, daß pro Multiplikation 82 zusätzliche Bytes Code erzeugt werden. Aber selbst wenn per HWMUL = 0 die Unterstützung ausgeschaltet wird, lande ich, sobald die fragliche Variable wieder als LONG dimensioniert wird, bei der ursprünglichen Codegröße.

Wie bei MCS schon sinngemäß geschrieben: Man hat die Wahl zwischen Flash- und Ramverschwendung. :-).

Viele Grüße
Henrik

[oe9vfj]

Hallo Henrik,

Ich konnte diesen zitierten Satz in dem Tiny45 Datenblatt nicht finden. Vielleicht könntest Du mal bitte einen Link angeben zu der Datei, wo Du diese Aussage gelesen hast.

Bei meinen Versuchen bin ich auf andere Flash-Bedarfswerte gekommen für WORD/Integer Mulitplikationen.

Die Mul-Routine selbst ist 104 Bytes (52 Word) groß.
Jeder Aufruf benötigt 26 Bytes (13 Word = 13 ASM Befehle) incl. laden der beiden Werte in die CPU-Register und zurückspeichern des Ergebnisses in das SRAM.

[hrei]

Hallo Josef,



Ich konnte diesen zitierten Satz in dem Tiny45 Datenblatt nicht finden. Vielleicht könntest Du mal bitte einen Link angeben zu der Datei, wo Du diese Aussage gelesen hast.


das steht im Datenblatt auf Seite 7, Abs. 4.3 ALU



Bei meinen Versuchen bin ich auf andere Flash-Bedarfswerte gekommen für WORD/Integer Mulitplikationen.
Die Mul-Routine selbst ist 104 Bytes (52 Word) groß.
Jeder Aufruf benötigt 26 Bytes (13 Word = 13 ASM Befehle) incl. laden der beiden Werte in die CPU-Register und zurückspeichern des Ergebnisses in das SRAM.


Die Werte erhalte ich auch (näherungsweise), wenn ich ohne Funktionen und Subs, bzw, lokale Variablen arbeite. Die derzeitige reale Applikation weist aber genau das beschriebene Verhalten auf. Da ich die leider nicht veröffentlichen kann/darf, bekommst Du am Wochenende ein abgespecktes Beispiel, an dem sich der Effekt nachvollziehen lässt.

Bei der Gelegenheit: Der große kleine Tiny45 ist wirklich prima. Für meine Arbeit an diesem Projekt hatte ich ursprünglich etwa 10 Tage eingeplant, bin aber nun schon nach knapp 4 Tagen fertig, trotz der Fehlersucherei und wegen des für einen Tiny großen Flashspeichers von 4kB.

Viele Grüße
Henrik

[Ratber]

Hallo.

Ich hatte das gleiche Problem mit dem 45er.
Und genauso wie oe9 hab ich kurzerhand den HWmul einfach abgeschaltet bis ich weiß ob der Fehler bei Bscom oder bei Atmel liegt.
Wäre nicht das erstemal ds Atmel sich neue Datenblätter einfach aus alten zusammenkopiert und damit unsinn verzapft.

Entweder es gibt keinen HWmul. oder er wurde einfach nur falsch Dokumentiert.

Wie gesagt,abwarten.
Ne Korrektur kommt bestimmt.
Bei 4K Flash kann man das aber derzeit gut verschmerzen.

[oe9vfj]

Die von Henrik zitierte Passage scheint mir ein allgemeines Statement zu den AVR-Prozessoren zu sein, die in jedem Datenblatt stehen könnte.
Da weder im Instruction Set (Seite 173) die ASM MUL Befehle aufgeführt sind, und auch in der Parametric-Tabelle für alle AVR-Prozessoren http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC in der Spalte "Hardware Multiplyer" nur 2 Striche stehen, gehe ich mal davon aus, dass der Tiny45 tatsächlich nicht die MUL Befehle implementiert hat, was sich ja auch in der Praxis gezeigt hat.
Das gleiche gilt übrigens für den Tiny25.

[Ratber]

Ja 25/45/85 sind Identisch bis auf Speicheraustattung.
Deswegen auch nur ein Dtanblatt für alle drei.

Die Unterschiede zwischen den Megas und den Tinys sind ja
im Wesentlichen Multiplizierer,Jtag,I2C,Uart und
es hätte mich gewundert wenn man einen Tiny mit HWMul
ausgestattet hätte.

Und wenn ich mal die Datenblätter durchstöbere dan finde ich
auch bei den Megas fast immer den gleichen Abschnitt zur ALU.
Aber bei den Tinys nirgens bis auf die relativ jungen 25-85er.

Ich bin mir ziemlich sicher das es wirklich so ist das sich mal wieder einer
das Datenblatt aus anderen zusammengeklebt hat und
den betreffenden Passus bei nem Mega ausgeliehen hat.
Wäre ja nicht das erstemal das sowas passiert.




Die von Henrik zitierte Passage scheint mir ein allgemeines Statement zu den AVR-Prozessoren zu sein, die in jedem Datenblatt stehen könnte.

Ich hab das mal nachgesehen.


Beim Tiny11,12,15 und 28 finde ist in der Sektion ALU zb. folgenden Satz:


.................The ALU operations are divided into three main
categories – arithmetic, logic and bit-functions. Some
microcontrollers in the AVR product family feature
a hardware multiplier in the arithmetic part of the ALU.

und beim Tiny13 und 2313 steht beui der ALU.:



Some implementations of the architecture also provide
a powerful multiplier supporting both signed/unsigned
multiplication and fractional format.
See the “Instruction Set” section for a detailed description.

Das Datenblatt vom Tiny22 sieht dagegen ganz anders aus.
Da wird die ALU in der Übersicht nur mal so nebenbei behandelt

Unterm Strich merkt man das zumindest die Verantwortlichen/ausführenden
für die Datenblätter öfters gewechselt wurden und jeder selbstverständlich so
seine Eigenarten (Oder manchmal auch Unarten) mitgeschleppt hat.



Wie das Leben so oft spielt ist vermutlich MCSelec auch drauf reingefallen.
Die sind ja dafür bekannt das bei Bascom noch einiges an Arbeit liegengeblieben ist.
Neben der immernoch Schauerlichen Hilfe auch die Integration der Controllerfamilien.

Die Tinys sind da besonders von betroffen.
Das Zwischenprodukt von 90er und Megas hat die größten Lücken
geschlagen weil es nun zig Anpassungen und Kniffe gibt die sehr oft
nicht zuendegedacht wurden.

So wundert es nicht wenn kurz vor dem letzten Update von den Tiny 25/45/85
nur der 45er mal eben mit einer hastig gestrickten Config bedacht wird
die flüchtige Lesefehler beinhaltet die wiederum auf nicht korrekte
Datenblätter beruhen.

Wie gesagt habe ich auch eine Weile über den seltsamen Multiplikationsfehler
gebrütet bis mir auffiel das der HW-Support an war was für Tinys eben untypisch ist.
Nach studium des Datenblattes (Könnte ja immerhin sein das Atmel dem neuesten und
vermutlich letzten Tiny tatsächlich nen HWMul aus nem Mega verpasst hat) kam ich
aber zu obigem Schluss das dies nur ne Ente ist die auf einigen Flüchtigkeitsfehlern beruht.
Die Änderung in der Config vorgenommen und ruh is.

Eine Mail an Mcselec hab ich auch rausgeschickt aber bis auf ne Bestätigung das man sich drum kümmert kam noch nix.


Wie gesagt Arbeite ich bis dahin ohne HWMul.
Genug Speicher für den Mehraufwand ist ja da.





Edit:
Ich tipper mal wieder zu lange.