mega 644 und voegele-fat in bascom

[kolisson]

hallo ihr,

da der mega644 mit seinen 4k-ram ja durchaus für die verwendung mit dem dos-fat von voegele(mcs) und ner sd-karte geeignet sein sollte, wollte ich das mal testen.

beim kompilieren gibt es da aber fehlermeldungen, weill beim 644 einige register anders heissen als beim mega128 (für den das fat ja geschrieben wurde). in anlage poste ich mal die fehlerliste !

ich werde das mal weiter untersuchen, wollte aber schonmal reinhören, ob da schon jemand erfahrungen gemacht hat.

gruss

[linux_80]

Hallo,

mit DOS- und FAT hatte ich noch nix zu tun,
aber man könnte doch das regfile vom 644er so ändern, das er die anderen Register-Namen auch kennt, also nur die unbekannten dazuschreiben,
wäre zumindest ein Workaround.
Beim 2. USART könnte es aber ein Problem geben, musst' evtl. etwas tricksen, also auch im Regfile die Adresse vom vorhandenen USART angeben.

Damit Du dir das original regfile nicht zerschiesst, kann man es evtl. kopieren nach m644adef.dat oder ähnlich. Bei $Regfile aber auch dann so angeben.

Ob das dann läuft, stellt sich dann aber erst noch heraus :-k

[kolisson]

hallo linux80,

interessanter ansatz mit der def-datei. ich hatte mich schon seelisch darauf eingestellt, in den .LBX dateien rumzufuimmeln, wobei ich eigentlich garnicht weiss, ob das geht.

gruss kolisson

[linux_80]

Hallo,

in den LBX kann man schon rumbasteln, das ist auch eine Textdatei, und halt etwas vorcompiliert,
alle Befehle die noch angepasst werden müssen, weil die ein Bestimmtes IO-Register verwenden, kommen noch lesbar vor, die anderen als Data-Bytes.
Man müsste jetzt mit einem Disassembler diese Bytes wieder in lesbare Befehle umsetzen, dann kann man das auch leichter ändern.
Ist nur viel Arbeit. Und auch wohl vom Erfinder (der Lib) so nicht geplant ;-)

[kolisson]

hallo linux,

bin schon etwas weiter gekommen. leider noch nicht weit genug um etwas zu veröffentlichen.

auf jeden fall werden die ersten 3 fehler :

Error : 975 Line : 0 [UBRR1H[C:\PROGRA~1\MCSELE~1\BASCOM~2\BASCOM~1\M644DEF.DAT]] , in File :
Error : 975 Line : 0 [UBRR1L[C:\PROGRA~1\MCSELE~1\BASCOM~2\BASCOM~1\M644DEF.DAT]] , in File :
Error : 975 Line : 0 [UCSR1B[C:\PROGRA~1\MCSELE~1\BASCOM~2\BASCOM~1\M644DEF.DAT]] , in File :

von der initialisierung des 2ten uart ausgelöst, obwohl der 644er ja 2 uarts an board hat. offenbar müsste man den uart2 noch irgendwie aktivieren. da werd ich nochmal nachlesen.

aus gründen der pinkompatibilität mit mega32 bin ich aber sowieso an der verwendung von uart1 interessiert. vielleicht kannst du mir zu folgenden codezeilen noch was schreiben:

$baud1 = 9600
Open "Com1:" As Binary As #1

laut anleitung initialisiert dieser code den uart2 als #1

wie kann ich denn uart1 als #1 initialisieren ?

ne idee?

[linux_80]

Hi,

ich hab auch 644er da rumliegen, aber die haben nur eine UART !

Wenn man nur eine UART hat, brauchts ja nur diese Zeile
$baud = 9600

Tipp wegen dem Open:
Wenns nicht zuviele Zeilen mit Print #1 oder Input #1 sind, bei diesen einfach das #1 wegmachen, und das Open auch weglassen, das braucht man wie schon erkannt nur, wenns mehr als eine UART gibt, damit das Print weiss wo's raus geht.
Hab das aber jetzt nicht ausprobiert !

[kolisson]

also im datenblatt vom 164P/V / 324P/V / 644P/V ... das sind die dip40 versionen... also pinkompatibel zum mega32 steht eindeutig, dass es 2 stück usart hat. der zeite teilt sich beine mit pd2 und pd3. ich habe das im pinout auch lange nicht bemerkt aber es ist so.

mir ist in der zwischenzeit klargeworden wo die fehler so liegen. das hat alles wenig mit dem dos-fat programm von herrn voegele zu tun sondern vielmehr mit der bascom (1.11.81) unterstützung des 644er proz.

und zwar ... wenn man folgendes proggi compiliert:

$regfile = "M644def.dat"
$crystal = 8467200

$hwstack = 128
$swstack = 128
$framesize = 128

Config Clock = Soft

gibt es schon eine fehlermeldung zu TCCR2 (timer counter2)

das liegt daran, dass im vergleich zu mega128 oder 32 das tccr2 register im mega644 nicht mehr existiert. es wurde vielmehr auf zwei register verteilt (TCCR2A und TCCR2B). davon nimmt bascom zuzeit keine notiz.

der nächste fehler bezieht sich auf der verwendung der register SPCR, SPDR, und SPSR durch die mmc.lbx von herrn voegele. das liegt aber weniger an der lbx als an einer, wie ich denke fehlerhaften m644def.dat.
darin werden die genannten register nämlich nicht erwähnt sondern erscheinen als SPCR0, SPDR0, und SPSR0 obwohl das datenblatt diese schreibweise nicht nahelegt. nach korrektut der 644def bleibt die fehlermeldung zumindest aus. ob das proggi dann funktioniert kann ich noch nicht sagen.

soweit die neuesten news dazu

gruss

[kolisson]

hier noch ein nachwort...
das mit der frage ob es beim 644er ein oder 2 uart gibt habe ich nochmal nachgesehen.

es ist beides richtig!!!!!
es gibt nämlich bei atmel ein datenblatt für den 644P/V ... der hat 2 uart.
und ein datenblatt für nen 644V... der hat nur 1 uart.

jetzt stellt sich mir die frage... welchen 644er hab ich eigentlich ?

dies erklärt die uart-frage nicht jedoch die diskrepanzen in den registern respektife der 644def.dat. (im letzten artikel beschrieben).

gruss

[kolisson]

hier noch was zum runterladen:
pdf document für den umstieg von mega32 auf 644 von atmel

[linux_80]

Welchen 644 Du nun hast, sieht man eigentlich am Aufdruck ;-)
Oder Du machst das Flashprogramm von Bascom, o.ä., auf und clickst auf Identify Chip, wenn dann 644 ohne P da steht, ist es der ohne P ;-) denn den mit P kennt Bascom nicht, der hat nämlich eine andere Chip-ID (Singnature-Bytes).

Da fällt mir noch auf, das in der Tabelle der AvR-Übersicht bei Atmel (http://www.atmel.com/dyn/products/param_table.asp?family_id=607&OrderBy=part_no&Direction=ASC) beim 644P auch nur 1 USART steht, obwohl der 2 hat !

Mit fertigen vorcompilierten Libs ist es halt so eine Sache, die laufen dann auch nur wenn die Registernamen auch so heissen wie sie der Programmierer der Lib da reingeschrieben hat, ausser es sind so einige Abfragen in der Lib enthalten die den verwendeten Chip abfragen, dann könnte man das umgehen. Hängt aber auch vom Programmierer ab, wie flexibel die Lib werden soll.