Bascom Bug melden

[Frank]

Diesen Thread habe ich geschaffen um Bug´s in Bascom zu melden.

Jeder der eindeutig einen Fehler gefunden hat, sollte diesen hier auflisten. Und anmerken ob er es an den Entwickler schon weitergegeben hat.
Wichtig ist jedoch das ihr die neuste Vollversion oder Demo nutzt, so das nicht schon behobene aufgelistet werden.


Bitte unbedingt Bascom Version und Controller angeben bei welchem der Bug auftritt!


Der Thread soll auch dem Entwickler helfen. Dieser ist gewöhnlich sehr fix und korrigiert die Bugs sehr schnell, was heute in dem Software-Bereich nicht mehr alltäglich ist.

Gruß Frank

[Frank]

Bug-Report

Version IDE 1.11.8.4 Version und Vorgänger
Bei der Programmierung des Mega2560 kommt es bei den höheren Ports als Eingang zu falschen Ergebnissen. Sie können somit nur als Ausgang genutzt werden. Untere Ports (A bis F) funktionieren.
Der Fehler wurde bereits an den Entwickler weitergegeben und auch schon korrigiert. Ein Update sollte jederzeit kommen.


Version IDE 1.11.8.4
Bei der Programmierung des Mega2560 in Verbindung mit dem USBISP kommt es zu Fehlermeldung oder/und Absturz. Andere Programmer funktionieren.
Der Fehler wurde bereits an den Entwickler weitergegeben und auch schon korrigiert. Ein Update sollte jederzeit kommen.

PS. Dieser Fehler scheint auch bei einigen anderen Controllern mit USBISP Programmierung aufzutreten. Sollte aber inzwischen im neusten Update der VOllversion behoben sein

[Paisley]

1.11.8.3 (hoffe noch nicht behoben)

Die .def Datei für den Tiny44 gibt an er habe HWMUL, bei mir hat es erst funktioniert seit der Wert auf 0 steht. Problem noch nicht weitergeleitet, da meine Fritbox mich partout nicht auf deren Seite lässt...

Gruß Denis

[linux_80]

Hab in Sachen ADC einen kleinen Bug gefunden:
https://www.roboternetz.de/phpBB2/viewtopic.php?p=244479#244479
hätte auch schon 'ne Mail an MCS gesendet, aber darauf noch keine Antwort o.ä. bekommen.

Hab wegen dem Tiny45 noch ein paar kleinere Bugs gefunden, die hab ich schon vor längerem mal an MCS gemeldet.
Das sind u.a. die FuseBits EF, da sind die Buchstaben vertauscht,
und der Chipname wird beim 45er als Tiny25 angezeigt, ist aber nur ein optischer Fehler.
Da hab ich auch schon die neuen ausgebesserten Dat-Files bekommen, sind für Tiny25 / 45 und 85 ziemlich dieselben.

1.11.8.3 Demo und Voll

[-tomas-]

Bascom Version 1.11.8.1 and 1.11.8.3

Ich habe beim Projekt Bascom Datalogger mit dem Butterfly vier Bugs im Zusammenhang mit den Registern des ATmega169 festgestellt.

' Config Spi = ...
' Config Clock = Soft
' Powersave
' Clockdivison

Diese sind alle im Quelltext dokumentiert.
siehe https://www.roboternetz.de/phpBB2/viewtopic.php?t=23231

anbei die vier Code-Ausschnitte mit den Workarounds

' Config Spi = ...

'!!!there is a bug in Bascom SPI I/O-Routine with "Config Spi ..."
'M169: Bascom checks a wrong Register, not the SPI Interrupt Flag SPSR.SPIF
'Config Spi = Hard , Interrupt = Off , Master = Yes , Polarity = High , Phase = 1 , Clockrate = 4 , Noss = 1

'SPI double speed settings
Spsr = &B00000001
'Enable SPI in Master mode, mode 3, Fosc/4
Spcr = &B01011100

' Config Clock = Soft

'!!!Bascom BUG in Timer-Interrupt
'M169: the Bascom-Statement "Config Clock = Soft" set the false Interrupt Timer0
'you can correct this Bascom-ERROR with two extra code lines:
' Timsk0.toie0 = 0 'Disable Timer0 Overflow Interrupt
' Timsk2.toie2 = 1 'Enable Timer2 - Timer/Counter2 Interrupt

'...but we use Async Timer with Bascom-Softclock as workaround
'its easy to extend the SUB _soft_clock (mcs.lbx) -> "$external _soft_clock"
Config Clock = User 'Async, Timer2-Interrupt,
'don't use the alternative "Clock = Soft,GOSUB = SECTIC" its stress the hwstack with extra 30 Byte (Push/Pop)

'...schnipp...

'*********ISR Timer2 - Async **************************************************
'---------------------------------------------------------------
'Interrupt: Isr_softclock
'Call from: Interrupt Vector Timer2
'Forward to: Bascom internal ISR _Soft_Clock
'Purpose: increment RTC: clock and date
' external 32kHz Oscillator (Async Modus)
'Result: _sec, _min, _hour, _day, _month, _year
'---------------------------------------------------------------
$external _soft_clock
Const _sectic = 0 'Compilerstatement for CONFIG CLOCK = USER , GOSUB <> SECTIC

Isr_softclock:
$asm
PUSH R24 'save used registers
IN r24, SREG
PUSH R24

LDI R24, 1
sts {Timer_Key_Event},R24 'variable for detect a new second

'If _sec = 0 Then Incr Powersavetimer
LDS R24, {_sec} 'Load direct from data space
CPI R24,0 'Compare with immediate
BRNE no_timer_incr 'Branch if not equal
LDS R24, {Powersavetimer}
SUBI R24,&HFF 'incr Auto Power Down timer one minute
sts {Powersavetimer},R24

No_timer_incr:
POP R24 'get content of SREG
!OUT SREG, R24
POP R24

'internal Bascom ISR-Routine: Softclock
JMP _SOFT_CLOCK 'original RETI
$end Asm
Return 'unused dummy RETI



' Powersave

'***SLEEP***
ldi r24, 7 'PowerSave Modus
!Out Smcr , R24
Enable Interrupts
sleep

' Clockdivison

$crystal = 1000000 'only Bascom internal
'now set register Clkpr to 1 Mhz
'RTFM: First, set first *only* Clock Prescaler Change Enable...
Clkpr = &H80 'Clkpce
LDI R24,&B0011 'Clkps1&Clkps0
STS Clkpr,R24 '...then (max. 4 Clocks!) prescaler = 8, Inter RC 8Mhz / 8 = 1Mhz

[kolisson]

Bascom Version 1.11.8.1 and 1.11.8.3 (demo)

ich habe unstimmigkeiten bei der registerzuweisung in verbindung mit atmega644V festgestellt.

1. bei der verwendung von spi-spezifischen kommandos wie z.B. folgender code:




$regfile = "M644def.dat"
$crystal = 1000000
$hwstack = 128
$swstack = 128
$framesize = 128

Config Spi = Hard
Spiinit




gibt es beim compiliren folgende meldung:
Error : 202 Line : 20 .EQU not found, probably using functions that are not supported by the selected chip [SPCR] , in File : .....

es wird also das register SPCR nicht gefunden. ein blick in die m644def.dat zeigt, dass dieses register dort auch nicht definiert wird. laut datenblatt ist es aber vorhanden. allerdings findet man in der def datei folgende einträge:

SPDR0 = $2e
SPSR0 = $2d
SPCR0 = $2c

ob nun schreibfehler oder nicht.. kann ich nicht so genau sagen. im prinzip komme ich zu dem schluss, dass bascom mit der 644 cpu nicht so recht kompatibel ist. es scheitern scheinbar sämtliche zugriffe über spi.bus in verbindung mit der mmc.lib.

gruss
gruss kolisson

[kolisson]

ein weiteres problem mit dem mega 644 und bascom ergibt sich bei der verwendung des bascom befehls CONFIG CLOCK = soft

hier wird ein fehlen des registers tccr2 gemeldet.

da der 644er dieses register nicht mehr hat, sondern diese auf die register tccr2a und tccr2b verteilt hat, ist das nicht weiter verwunderlich.

[bertl100]

Mega2560 und Bascom 1.11.8.3 und .8.4

Interrups urxc2 für 3.usart UND URXC3 FÜR 4.usart nicht nutzbar.

Fehlermeldung: unknown interruptsource


MFG

Bertl

[tholan]

BASCOM Demoversion 1.11.8.1 (Als Download immer noch aktuell) :
Das Register UCSRA und UCSRB sowie deren Bits lassen sich beim ATTiny2313 nicht ansprechen.
Die Registerbezeichnungen entsprechen hier wohl noch dem Datenblatt des 90S2313.
Wer will kann ja mal die 2313DEF.DAT bzw die ATTINY2313.DAT durchackern u. ggf. korrigieren.
Hab und werd auch sonst nix weitermelden, da ich auf den Gnuavr umgestiegen bin.
Hier stehen die Register in der iotn2313.h und scheinen im Vergleich mit dem aktuellen Datenblatt
des ATTiny2313 auch zu stimmen.

[kolisson]

Hier mal ne noch ne meldung zu den vorher erwähnten problemen mit atmega644 in bezug auf timer2 und spi. ich hatte das problem letzte woche an mcs gemeldet. heute am 20.2.2007 habe ich auch ne antwort bekommen, die ich hier mal weiterreichen will:



Hi

These issues are resolved. Atmel used new register names. We support both names now.
I advise to download a new demo when it becomes available next week.


Best regards,

Mark Alberts


dann kann man ja noch hoffen.

gruss

[linux_80]

1.
Wollte letztens die glcdSED.lib übersetzen, weil ich die Init-Bytes geändert habe.
Die LBX funktionierte zwar so auch, man musste aber dann nochmal die Initialisierung wiederholen (bzw. selber machen), damit das LCD richtig anzeigt. Ist das vom Pollin Nr. 120292 .

Also ich hab nur die Bytes geändert, und über Bascom vorcompiliert, danach ging das auch neu compilierte Programm nicht mehr, das LCD zeigte nichts mehr an.

Nach etwas forschen hab ich herausgefunden, das die vorcompiliete Version die 1.0 ist, die lib aber schon V2.0 !
In dieser ist etwas für den M128 optimiert worden, und dabei wurde STS und OUT verwechselt, was bei gleichem Register natürlich nicht geht, da für STS $20 dazugezählt werden müssen.

Hab den Fehler schon gemeldet, und ist auch schon ausgebessert.
Mark A. meinte, das bei Verwendung von OUT automatisch auf STS geswitcht wird, wenn man den Bereich der normalen IO-Register verlässt.


2.
Dann hab ich noch was gefunden im DAT-File vom M32 (m32def.dat), dabei weiss ich aber nicht mehr, ob ich das selber mal verbrochen habe :-k
Also, bei der definition des Bits PD1 stand bei mir
PD1 =1PD0 =0
ohne CR dazwischen, was zum problem kommt, wenn man das mal so verwendet, hab ich aber noch nicht, hab das nur zufällig in der Compiler ausgabe gefunden.

Also bitte nachschauen, ob das bei euch auch so (falsch) ist, dann kann man das mal melden, ansonsten vergessen :-)


Bascom V1.11.8.3 Voll

[bertl100]

Neueste Version von Bascom .8.5
-Graphlcd funktioniert nicht 240x128 tc controller
-Input bei den höheren Kanälen wie input #3 zeigt fehler

[Frank]

Achtung!
Bitte hier im Thread keine Diskussionen sondern nur Bugs posten!
Es sollte sichergestellt sein das es auch ein Bug ist, also möglichst erst in einem anderem Thread oder mit Mark (bascom Hersteller) abklären.

Andere Diskussionen oder Beiträge ohne Angabe der Version muss ich aus diesem Thread löschen, er soll übersichtlich bleiben! Also auch keine Vermutungen posten, es muss schon belegbar sein.

Ist der Bug behoben könnt ihr Euer Posting editieren und dies dort noch anmerken!

[Brantiko]

PWM Anweisungen beim Attiny26 funktionieren nicht korrekt. Manuelle Konfiguration über Register geht.
Edit: Version 1.11.8.3
Alex


Etwas editiert vom Admin ums verständlicher zu machen. Bitte ändern falls ich das falsch verstanden habe.

[jar_]

Getrc5(address , Command)
Thirdline
Home Third 'goto home on line three
Lcd "Address=" ;
If Address < 255 Then Lcd Address Else

Bascom 1.11.8.3 serial Demo spinnt, in der GetRC5 macht der Auto Syntax Check address klein, in der Abfrage groß, trotzdem funzt es , aber wehe ich übernehme das nach C gemischte Groß- Kleinschreibung

PS. bin neu hier, habe nach diesem Bug gesucht aber nix gefunden,

jaja, sagt jeder der Doppelposting macht 8-[

Bug noch nicht dem Entwickler gemeldet, muss mich erst orientieren

[jar]

Bug noch nicht dem Entwickler gemeldet, muss mich erst orientieren

ich bin nun jar ohne _

[linux_80]

Hallo,

ich weiss nicht ob das Bugs sind, bzw. waren, aber es wurde zumindest geändert ;-)
und zwar bei Bascom 1.11.8.5:

1. Programmer
Im Programmer auf der Seite der Fusebits hat sich der Frame mit der Fusebitliste nicht an die Fenstergrösse angepasst.

2. a) Fusebits KLA987:
Beim Mega16 sind die Fusebits KLA987 noch anders zusammengepackt, und benannt, obwohl diese gleich wie beim Mega32 sind, bis auf die Grösse des Bootloaders.

2.b)
Weiterer Schönheitsfehler bei den KLA987-Fusebits ist, dass bei einer Kombination, die es nicht in der Liste gibt, einfach irgendwas anzeigt, aber nicht das, was mit den Fusbits der aktuellen Zeile zu tun hat.
Es gibt demnächst einige Einträge, die sich reserved nennen, da diese Kombinationen bei Atmel nicht dokumentiert sind, aber zustandekommen, wenn man mit einem anderen Programmer (zB. Pony) die Fusebits geändert hat, und nicht ins DB geschaut hat. ;-)
Das ist bei allen AVR (dat-Dateien) geändert.

Alles behoben für das nächste Update.

[Chriss123]

im Bascom-AVR:
ich weiß nicht ab das als eindeutiger fehler gilt aber:
bei mir lässt sich der chip nicht programmieren. Denn jedes mal wenn ich auf send to chip klicke bekommme ich immerewieder die meldung : Datei nicht gefunden. und die meldung ,dass ich zwei verschidene chips als standard hab. obwohl ich schon überall ATmega16 als standard eingetellt hab! :-k

Gruß
Chriss123

[Ratber]

In der 1.11.8.5 (In der 1.11.8.3 funktionierts noch bei 1.11.8.4 weiß ich es nicht) lassen sich zb. auf dem Tiny2313 die Timer nicht mit den Systeminternen Routinen konfigurieren.(Händisch in die Register gehts natürlich)

Das bedeutet konkret das der Befehl "Config Timerx......" nicht funktioniert und einige bis alle Makros die Timer nutzen (zb. SendRC5) ebenfalls nicht.

Bug ist gemeldet.


@Chriss123

Der Gehler liegt bei dir denn sonst könnte keiner damit arbeiten.
Soweit tesaten die Jungs von MCS dann doch vor dem Release :D

[robby-fant]

...Der Gehler liegt bei dir denn sonst könnte keiner damit arbeiten.
Soweit tesaten die Jungs von MCS dann doch vor dem Release Very Happy....



.... eine in dieser Form überflüssige Bemerkung dazu .....


(PicNick)

[Ratber]

1. Schau auf deine Tastatur dann bist du im Bilde.

2. Wer im Glashaus sitzt............
Wenn du schon auf Oberleherer machst dann solltest du mal deine
Shift-Taste nutzen ;)

3. Ist das hier kein Labertopic


Zip,Zap,Zerap ;)

[gpo]

Hallo,

habe einen Fehler entdeckt, der mir sehr viel Zeit gekostet hat. Hier ein kleines Programm, um den Fehler zu zeigen.


$sim
$regfile = "m8def.dat"
$crystal = 16000000
$baud = 9600
$hwstack = 40
$swstack = 16
$framesize = 10



Dim Sio(3) As Word
Dim X As Byte

Sio(1) = &B0000_0001_0011_0000
sio(2) = &B0000_0001_1110_1000
sio(3) = &B0000_0001_1111_0000



Print Bin(sio(1))

Print Sio(1).15;
Print Sio(1).14;
Print Sio(1).13;
Print Sio(1).12;
Print Sio(1).11;
Print Sio(1).10;
Print Sio(1).9;
Print Sio(1).8;
Print Sio(1).7;
Print Sio(1).6;
Print Sio(1).5;
Print Sio(1).4;
Print Sio(1).3;
Print Sio(1).2;
Print Sio(1).1;
Print Sio(1).0;


End


Mit Print Bin(sio(1)) stimmt das Bitmuster, versucht man aber die Bits einzeln auswerten, geht es daneben. Andere Bitmuster wie z.B. Sio(1) = &B1010_1010_1010_1010 funktionieren aber. :-s

Gruß
Günter

[bastelbaer]

Bascom Version: 1.11.8.7

Bei dem unten angehängtem Programm wird der Circle-Befehl, der die übergebenen Koordinaten im Aufruf hat, nicht richtig ausgeführt.
Die Variablen sind ok, es scheint so, dass der Circle-Befehl die Parameter falsch übernimmt.

Fehler ist noch nicht gemeldet



' Testprog glcd
$regfile = "m16def.dat"
$hwstack = 128
$swstack = 128
$framesize = 128

$crystal = 16000000
$baud = 19200
Baud = 19200

'First we define that we use a graphic LCD
Config Graphlcd = 240 * 128 , Dataport = Porta , Controlport = Portb , Ce = 2 , Cd = 3 , Wr = 0 , Rd = 1 , Reset = 4 , Fs = 5 , Mode = 8

Declare Sub Tacho(nr As Byte , Xcenter As Byte , Ycenter As Byte , Radius As Byte , Maxval As Long , Aktval As Long)

Const Black = 255
Const X1 = 200
Const Y1 = 100
Const R1 = 20

Dim Xc As Byte
Xc = 60
Dim Yc As Byte
Yc = 70
Dim Rr As Byte
Rr = 50
Dim Nn As Byte
Nn = 1
Dim Vmax As Long
Vmax = 200
Dim Vakt As Long
Vakt = 200

Cls
Cursor Off , No Blink
Call Tacho(nn , Xc , Yc , Rr , Vmax , Vakt)
Wait 1
Circle(xc , Yc) , Rr , Black ' Ok, draw a circle

End 'end program



Sub Tacho(nr As Byte , Xcenter As Byte , Ycenter As Byte , Radius As Byte , Maxval As Long , Aktval As Long)
Circle(xcenter , Ycenter) , Radius , Black ' failed, one dot at Coordinate X=YCenter, Y=0 (radius=0 ?)
Circle(30 , 30) , 20 , Black ' Ok, draw a circle
Circle(x1 , Y1) , R1 , Black ' OK, draw a circle

End Sub

[Horstmann]

Bascom Version: 1.11.8.7

Controller: Tiny24

der Befehl getadc (pinadresse) muss zweimal hintereinander ausgeführt werden, ehe der ausgelesene Wert aus dem Register gelöscht und ein neuer ADC-Wert eingelesen werden kann. Fällt erst auf, wenn man mehrere verschiedene Spannungen einlesen möchte.

Dieser Fehler hat mich echt zur Weißglut getrieben. Ich hoffe meine Fehlerbeschreibung ist zu verstehen.

An den Hersteller habe ich diesen Bug nicht gemeldet.

mfg
Hostmann

[Steffen44]

Fehler entdeckt mit Bascom 1.11.8.x bis 1.11.8.8 sowie dem ATMega2560.

Die ADC Kanäle 8-15 können nicht mit getadc( 8 ), getadc( 9 ) ... usw. ausgelesen werden. Die ADC Kanäle 0-7 hingegen funktionieren normal.

Die Lösung des Problem ist Adcsrb.mux5 zu setzen.

Hier ein Beispiel wie es funktioniert :


Adcsrb.mux5 = 0 'Enable ADC 0 - 7
getadc(x) ' x = 0 ... 7

Adcsrb.mux5 = 1 ' and now disable ADC 0-7 and enable ADC 8-15
getadc(x) ' x = 0 ... 7

Hier der Tread zum Thema : https://www.roboternetz.de/phpBB2/viewtopic.php?p=295067#295067

Vielen Dank an linux_80 für die Lösung des Problems.

Edit: seit Bascom Version 1.11.8.9 ist dieses Problem behoben.

Getadc() will set adcsrb.mux5 bit for channel>7 on m2560, m1280

----------------------------------------------------------------------

RC5 Receiver - Fehler entdeckt in Bascom 1.11.8.x - 1.11.8.8 :

Standart Code RC5 Empfänger aus der Hilfe funktioniert nicht. Der Code wird im Bascom nicht kompiliert:

Lösung :

-öffne m2560def.dat mit notepad etc.
-suche nach timsk0
Code einfügen das es so ausieht :

TIMSK0=$6e
TIMSK=$6E

-Speichern-

Gruß
Steffen

Edit : Das ADC Problem wird in der nächsten Version behoben sein.
Vielen Dank MCS Mark ;-)

[linux_80]

Hallo,

Probleme beim ADC mit Tiny24, 44 und 84,
Bascom Version bis 1.11.8.8 (bei 1.11.8.9 steht noch nix davon in der History)

Thread:
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=32204

Beim Compilieren wurden die Register in der internen BascomLib durcheinandergebracht, was ein nutzen des ADC mit dem Bascom-GetADC unmöglich macht.

Fehler an MCS gemeldet.


Edit:
(MCS-Antwort 31.07.2007):
Wird im nächsten update behoben.

Edit 2:
Workaround, bis das Update verfügbar ist:
https://www.roboternetz.de/phpBB2/viewtopic.php?p=310182#310182

[bertl100]

Ich hab mich jetzt mit der .8 und der .9 er Version schon Stunden gespielt, aber der urxc interrupt bei meinem Mega2560 funktioniert leider nicht.
Habt ihr das gleiche Problem??
Habs noch nicht an Bascom gemailt, wollte zuerst mal nachfragen.

[peterfido]

Bei mir unterbricht Bascom das Herunterfahren von Windows. Ich muss Bascom erst beenden und erst dann lässt sich Windows beenden. Habe inzwischen Version 1.11.8.8. Ich habe den Fehler heute gemeldet.

[pickelrobert]

Problem erledigt.

[roboterheld]

.....offensichtlich gibt es bei der Übergabe von mehr als 2 Parametern Probleme. Konkret: Die einer SUB übergebenen Werte sind in dieser falsch!
....


nein, ist kein fehler, setzt dieses hier .

$hwstack = 32
$swstack = 32
$framesize = 64

dann geht es.

[mull]

Bei der Version 1.11.9.0
können die ADC Kanäle 8-15 immernoch nicht richtig ausgelesen werden.
Habe es versucht, allerdings kam kein vernünftiger wert zurück.

Nachdem ich den Mux5 = 1 gelegt habe, konnte ich die Kanäle auslesen, allerdings konnte ich nicht wieder auf Mux5 = 0 umschalten und die ersteren Kanäle verwenden.

Bug habe ich schon weitergeleitet.

Grüssle

[mull]

Hi,

we know about this problem and fix for this will be in next release.

Best regards,

Tomi
MCS Electronics
www.mcselec.com

[Brantiko]

Die Servo Funktion (Config Servo) klappt erst ab 8Mhz was ja nicht schlimm wäre, wenn nicht ein Hinweis in der Anleitung dazu fehlen würde.

Version 1.11.8.7


Gruss,

Alex

[chr-mt]

Version 1.11.9.1
Code hints gehen nicht mehr
CLS Text und CLS Graph gehen nicht mehr.
ADC Kanäle 8-15 gehen immer noch nicht richtig

Ist an den MCS Support weitergeleitet.

Gruß
Christopher

[constructor]

Version 1.11.9.1

Bereits bestehendes Programm mit vorheriger Version fehlerfrei compiliert meldet nun in Line 1 Error : 202 Line : 1 .EQU not found, probably using functions that are not ...

....aber da steht nur eine 'Kommentarzeile !!!!!!

Ich bin schier am verzweifeln!

[Ratber]

Da gibt es ja mehrere Möglichkeiten

Entweder ein neuer Bug oder eine Änderung. (Was ich vermute)

Gib doch einfach mal den entsprechenden Codeschnipsel mit Zeilennumerierung an.

[Horstmann]

Version 1.11.9.1

Bereits bestehendes Programm mit vorheriger Version fehlerfrei compiliert meldet nun in Line 1 Error : 202 Line : 1 .EQU not found, probably using functions that are not ...

....aber da steht nur eine 'Kommentarzeile !!!!!!

Ich bin schier am verzweifeln!

Habe selbes Problem. Früher Programme ohne Fehler werden nicht mehr compiliert.

Und ich habe sogar selbige Fehlermeldung, obwohl ich noch nichtmal ein Programm geschrieben habe. Es reicht schon die erste Zeile, wo nur der Controller definiert wird (und diese Zeile ist garantiert richtig).

Installation auf einem anderen Rechner half auch nichts. Weiß auch nicht mehr weiter. Bin bald soweit auf C umzusteigen :-k

Zum Glück bin ich nicht der einzige mit dem Problem

[Ratber]

Ich hab mal upgedatet und probiert.

Keine Probleme auf 3 Rechnern.
Wenn das ein genereller Bug wäre hätten sich sicher schon wesentlich mehr Leute gemeldet also vermute ich mal das sich Bascom bei euch mit irgendwas im System beißt.

Oder ist mal wieder ein P2P-Fake unterwegs ? ;)

[helimike0705]

Hatte auch ein paar Probleme, habe mich in anderen Foren schlau gemacht.Mir wurde angerade mal bei geöffnetem Bascom die Hilfe anzuklicken,dann auf "Über" gehen.In dem angezeigten Fenster auf den Dateiverweis "App data dir" klicken.Dann Bascom schliessen, es bleibt das Fenster offen. Die Datei "bascom-avr xml" löschen und Bascom neu Starten,es kommt die gelöschte Datei wieder und es gehen einige sachen wieder wie vorher.Bei meinem Fall konnte ich Bascom nicht minimieren und andere Sachen. Jetz gehts wieder.

Mike

[Ratber]

Aha, interessant.
Also mehr ein Problem des Parsers mit dem Dokument.

Wäre mal interessant ein solch fehlerhaftes Dokument einzusehen.

Wenn jemand noch einen solchen Fehler hat wäre es nett dieses Dokument hier einzustellen (Um evtl. vorhandene persönliche Einträge gekürzt natürlich)

[maikatze]

Hallo,
ich habe das gleiche problem wie constructor, ratber und Horstmann (Bereits bestehendes Programm, mit vorheriger Version fehlerfrei compiliert, meldet nun in Line 1 Error : 202 Line : 1 .EQU not found, probably using functions that are not ... ).

Bei mir tritt der Fehler auf, wenn ich als regfile den ATTINy 24, 44, oder 84 angebe.
Bascom compeliert den gleichen code problemlos wenn ich als regfile z.B. den ATTiny 45 angebe. Es scheint ein problem der DAT-Dateien zu sein.

[Ratber]

Hallo,
ich habe das gleiche problem wie constructor, ratber und Horstmann.......


Sorry aber ich hatte kein Problem damit.




Bei mir tritt der Fehler auf, wenn ich als regfile den ATTINy 24, 44, oder 84 angebe.
Bascom compeliert den gleichen code problemlos wenn ich als regfile z.B. den ATTiny 45 angebe. Es scheint ein problem der DAT-Dateien zu sein.


Nur Standard in den ersten Zeilen und schon die Fehlermeldung ?
Hast du es mal versucht wie helimike0705 es beschrieben hat ?
Behalt aber mal ne Kopie der "bascom-avr xml" zurück.
die interessiert mich doch mal.

[maikatze]

Hallo,
der tip von helimike0705 funktioniert nicht.
Die Fehlermeldung:
Error 202: EQU not found, probably using function that are not supported by the selected chip .........
Das Program :
$regfile = "ATtiny44.DAT"

Do
nop
Loop

Die DAT-Datei ist definitiv vorhanden. Mit Attiny 45 wird problemlos compeliert. Habe mal die Attiny44.dat-datei von einer älteren Version in das Verzeichnis kopiert. Damit wird compeliert. Habe aber keine Ahnung, welche konsequens das haben könnte?

[Ratber]

Ja dann vermute ich mal das die DAT nicht korrekt ist (sind).
Frag mal bei MCS an ob die schon was wisswn bzw. meld es einfach (Email)

[linux_80]

Zum Thema ADC8-15 beim Mega2560 und Co:

Hab mal wieder geforscht, rausgekommen sind diese beiden Posts ;-)
https://www.roboternetz.de/phpBB2/viewtopic.php?p=368892#368892

[merijnwijnen]

Hello all,

Bascom 1.11.9.1 , volversion

It took me quite some time to discover why the harware UART receiver on the M169 (used in the butterfly board) does not work.
Answer:
In the M169def.dat file under the [IOEXT] header the following line is missing:
UCSRC=$C2

Greetings,
Merijn

[spaceduck]

Interne Referenzspannung beim Mega8 wird durch den Befehl

Config ADC ... reference = internal

nicht gesetzt . Bascom 1.1.9.0 Am betreffenden ARef Pin kann keine Spannung gemessen werden -> keine A/D Wandlung möglich!
Workaround: Register ADMUX manuell setzen funktioniert.

Admux = &B11100000
' ^^-----------------Voltage Reference:11=Internal
' ^----------------Left Adjust
' ^---------------Not Used
' ^^^^-----------Analog Channel:0000=ADC0

[Brantiko]

Moin!
Ein Programm welches ich für den Attiny26L geschrieben habe kompiliert Bascom in der Version 1.11.8.7 problemfrei und zeigt an dass 99% des Speichers voll sind. Nun habe ich mir die Version 1.11.9.1 heruntergeladen und die BAS Datei geöffnet. Hier zeigt mir Bascom dann an dass das Programm 30 Zeilen zu lang sei! (101%)
Trotzdem kann ich das Programm in den Flash brennen und es funktioniert auch. ( 2046 von 2.048 Byte)

Gruss

Alex

[DeKalle]

Hi,

ich habe eine Dual-Monitor System mit zwei Monitoren. Wenn ich die Bascom-Hilfe öffnet, so erstreckt Sie sich über die Breite des Desktop, also über beide Monitore.

Kleiner Bug, aber ärgerlich :)

Gruß
Kalle

[spaceduck]

Das Hilfe Fenster kann man doch skalieren...???

[DeKalle]

Aber es merkt sich die Einstellung nicht. Bei jedem neuöffnen erstmal das Fenster über 2 Monitore.

Ich sag ja, ist nicht schlimm!! Aber ein Bug ;)

[Blue72]

Bascom IDE 1.11.9.3(.001)

Der neue USB Progger Elektor AVR MKII kann genau 1x proggen, danach wird die ISP Geschwindigkeit auf 8MHz gesetzt und muss mit (bei mir z.B.) WINAVR wieder runter gesetzt werden. Ich habe keine Möglichkeit gefunden diese in Bascom selbst zu ändern.

Werd es gleich an MCS melden.

Gruß
Jens

[Ratber]

Der neue USB Progger Elektor AVR MKII

Elektor ?
Neu ?
Hab ich was verpasst oder nennt Elektor den nur zufällig wie den von Atmel ? (Ich lese die Elektor seit Jahren nicht mehr)



Was dein Problem betrifft :

Ich hab selber den Atmel MKII (Gekauft als er rauskam.Weiß nicht mehr wann das war) aber meiner macht kein zicken.
(AVR-Studio aktuell,Bascom aktuell.Unter W2K und XP SP2)

Vieleicht hast du nen Montagsgerät erwischt.

[Blue72]

Hi,

nene, seit der 1.11.9.3 wird der USBprog 3.0 von Embedded Projects ("Hersteller") unterstützt. Dieser wird nicht nur vom Erfinder sondern auch jetzt wohl von der Elektor vertrieben (siehe hier: KLICK (http://www.embedded-projects.net/index.php?page_id=205) ) Sorry wenn ich mich falsch ausgedrückt habe :(

Das Teil arbeitet einwandfrei, wenn man das Programm mit Bascom compiliert und mit WinAVR hochlädt. Ich will aber die neue Unterstützung von Bascom jetzt nutzen, sodass ich nicht den Umweg über WinAVR gehen muss.

Gruß
Jens

[Ratber]

Yo, das Modell kenn ich nicht.
Da kann ich dir leider nicht helfen.

[yyyy]

Hallo,

ich habe den gleichen Fehler mit usb1287.dat bei der Bascom-DEMO 1.11.9.1.

Wie ist die Sache ausgegangen ?

[Blue72]

Noch gar nicht, MCS wollte eine Möglichkeit inplementieren die ISP Geschwindigkeit manuell einstellen zu können.

Ich hab unter Vista32 nur Probleme damit, ich nehm die "altmodische" Variante über WinAVR ;)

Gruß
Jens

[Ent19]

Hab noch so ein paar kleine Bugs die mich schon öfter geärgert haben. Die anderen Sachen die nicht ging sind schon in den neuen 1.11.9.X version schon weg.

Der erste wurde hier schon mal gepostet und ist immer noch in der 1.11.9.3 vorhanden.

Dim Cnt1 as Byte
Dim Testvar as Word

Testvar = &B1100100111100011 'Beliebig definieren
Print Bin(Testvar) 'Druckt: 1100100111100011

Cnt1 = 0 'Druckt: 1100100111100011
While 16 > Cnt1
Print Testvar.cnt1;
Incr Cnt1
Wend
Print

Print Testvar.0; 'Druckt: 1110010011100100
Print Testvar.1; 'Statt Bit 8 druckt es Bit 0,
Print Testvar.2; 'Statt Bit 9 druckt es Bit 1, usw
Print Testvar.3; 'Statt Bit 16 käme wieder Bit 0
Print Testvar.4;
Print Testvar.5;
Print Testvar.6;
Print Testvar.7;
Print Testvar.8;
Print Testvar.9;
Print Testvar.10;
Print Testvar.11;
Print Testvar.12;
Print Testvar.13;
Print Testvar.14;
Print Testvar.15;
-----------------------------------------------------------------------------------

Hatte noch ein Problem mit Konstanten

Const xy = "Hello " 'Normaler const
Const xz = xy 'Diese Zuweisung geht nicht
Const yz = xy + "Welt!" 'Diese Wiederrum doch
Const az = xy + "" 'Diese geht auch


Hatte das bei so ein ähnlichen Fall:

Const Version_short = "Version:1.0"

#If Beta = 1
Const Version_long = Version_short + "Beta"
#endif
#If Beta = 0
Const Version_long = Version_short
#endif

Print Version_long
------------------------------------------------------------------------------
Und ein weiteren Bug den ich gefunden hatte war auch bei Arrays

Ich wollte in ein Bytearray ein Wert speichern der ein Bitwert speichert.

Dim Arraymultiausgang(8) as Byte 'Mehrere Ausgänge gespeichert
Dim Tmpausgang as Byte
Dim Ausgangaktiv as Byte
Dim Ausgangbit as Byte

Arraymultiausgang(1) = 2
Arraymultiausgang(2) = 7
Arraymultiausgang(3) = 1
Arraymultiausgang(4) = 3
Arraymultiausgang(5) = 6
Arraymultiausgang(6) = 5
Arraymultiausgang(7) = 4
Arraymultiausgang(8) = 0
Tmpausgang.Arraymultiausgang(1) = 1 'Dieses ging nicht
'Fehler Tmpausgang ist kein Array

Ausgangbit = 2
Tmpausgang.ausgangbit = 1 'Selber Befehl
Tmpausgang.2 = 1 'Selber Befehl


Diese Probleme hatte ich mit Atmega16, Atmega32 und Atmega644 mit der Bascom Version 1.11.8.9 - 1.11.9.3.
Diese Beispielprogramme sind sehr vereinfacht worden um die Problematik zu erläutern und nicht die anwendungsbeispiel zu erklären wo ich solche Probleme bekommen habe.

Ein weiteren Fehler den ich jetzt nicht Beweisen kann, aber der mich schon genug geärgert hat ist und den ich mittlerweile umgehen kann ist folgender:

Wenn man eine Hardware Uart und eine Software Uart benutzt, und man auf den Flag Ucsr0a.txc0 = 1 wartet (Wenn der Hardware Uart fertig ist mit senden und der Buffer leer sein 'SOLL'). Dummerweise hat der Inkey(#2) Befehl wohl ab und zu diesen Flag auch gesetzt oder eine ähnliche Handlung vorgenommen, da auf einmal angeblich das Senden fertig war. Dieser Fehler kam aber nur dann vor wenn auch wirklich etwas an #2 eingelesen wurde, sonst hat alles funktioniert.
Mit der Prüfung _rs_bufcountw0 = 0 und eine Warteschleife von 1ms habe ich diesen Bug umgangen (Falls der Ucsr0a.txc0 gesetzt wird beim senden vom Letzten Byte musste ich die 1ms warten). Das Programm aktiviert andere MCs der reihe nach und schickt diesen einzeln Befehle, wenn der Befehl raus ist soll es zum nächsten wechseln, das Problem war immer das es vor der Beendung des Befehls schon umgeschaltet hatte, und das ist immer nur dann passiert wenn etwas auf dem Software Uart eingelesen wurde, in Beispiel #2. Sobald der Software Uart entfernt wurde oder nicht benutzt wurde Funktioniert alles einwandfrei. Naja ich hoffe es lässt sich so ein Problem mit den Software UARTs beheben und das dann die Software Uarts wieder normal benutzt werden können.



Gekürzter Codebeispiel:
----------------


$regfile = "m644def.dat" ' specify the used micro
'$crystal = 14745600 ' used crystal frequency
$crystal = 18432000 ' used crystal frequency
$baud = 9600 ' use baud rate

$hwstack = 64 ' default use 32 for the hardware stack
$swstack = 20 ' default use 10 for the SW stack
$framesize = 80 ' default use 40 for the frame space

Config Serialout = Buffered , Size = 128 ' Speichert 128 Bytes im Seriellen Buffer

Open "COMA.7:9600,8,n,1" For Input As #2 'TR_RxD (Transponderleser) Pin PortA.7

...

If Ucsr0a.txc0 = 1 Then 'Hier springt das Programm auch bei Software Uarts rein.
Readcheck:
If _rs_bufcountw0 = 0 Then 'Prüft Zusätzlich ob Hardware Uart wirklich leer ist oder ob Software Uart wieder Flag gesetzt hat.
If Readingtran = 0 Then
Readtranok = 0
If Sendreaddata <> "" Then
Errorcnt = 0
Gosub Sendread
Else
If 2 > Progstatus Or Progstatus > 13 And Hudset.hdtrans = 1 And Tr_voll = 0 Then Readtranok = 1
End If
End If
Else
Ucsr0a.txc0 = 1
End If
...

If Readtranok = 1 Then
C_sw = Inkey(#2)
If C_sw > 0 Then
...


Ich hoffe ich habe euch wieder mal interessante Sachen zum Suchen gegeben wie beim letzten mal ^^. Diese Fehler sind zwar schon einmal geschickt worden aber entweder ist die Mail nicht angekommen oder wurde nicht gelesen, ich hatte darauf keine Antwort bekommen und die Fehler sind ja noch immer drin.

[ikarus_177]

Hi,

ich meine, auch einen Bug in der neuesten Vollversion (1.11.9.3) gefunden zu haben.

Das Problem tritt beim Einlesen und Vergleichen des Wertes eines kompletten Ports auf (8 Bit).

Wenn ich habe:

config PORTB = input
inputport alias PINB

const buffer = 129
dim inputbuffer as byte

inputbuffer = inputport
if inputbuffer = buffer then
[...]
else
[...]
endif

Hier wird der else-Zweig der if-Selektion ausgeführt, obwohl am Port nachweislich der Wert 129 anliegt.

Wenn ich das Programm minimal abändere:

config PORTB = input
inputport alias PINB

const buffer = 129
dim inputbuffer as byte

inputbuffer = inputport
if inputbuffer = 129 then
[...]
else
[...]
endif

... wird allerdings der else-Zweig ausgelassen, sondern die if-Bedingung als 'wahr' beurteilt.

Hat das vielleicht sonst jemand beobachten können?
Ich werde dann noch eine Mail an MCS richten.

Viele Grüße
ikarus_177

[Ent19]

Ich habe es mal getestet mit einem ATMega644 und Bascom 1.11.9.3 und hatte folgende Ergebnisse:

das 1.
! = 129 (mit =Const)
? <> 129 (mit =Const)
das 2.
! = 129 (mit =129)
? <> 129 (mit =129)



Mit interne Pullups:
11110011?? <--Hierfür habe ich keine erklärung das beim ersten auslesen nicht &HFF kommt
11111111??
10000001!!
10000001!!



Config Portb = Input
Inputport Alias Pinb
Portb = &B11111111

const buffer = 129
dim inputbuffer as byte

Inputbuffer = Inputport
Print Bin(inputbuffer);
if inputbuffer = buffer then
Print "!";
else
Print "?";
endif
If Inputbuffer = 129 Then
Print "!"
else
Print "?"
endif



Ohne interne Pullups:
11100011?? <-- Undefinierter zustand
10100000?? <-- Undefinierter zustand
11110011?? <-- Undefinierter zustand
10000001!! <-- Alle auf Ground oder 5V
10000001!! <-- Alle auf Ground oder 5V




Config Portb = Input
Inputport Alias Pinb
Portb = &B00000000

const buffer = 129
dim inputbuffer as byte

Inputbuffer = Inputport
Print Bin(inputbuffer);
if inputbuffer = buffer then
Print "!";
else
Print "?";
endif
If Inputbuffer = 129 Then
Print "!"
else
Print "?"
endif



versuch es mal mit den Pullups oder so, vielleicht hilft das? und lass dir auch den Wert ausgeben

[ikarus_177]

Hi,

der Wert am Port wird mit 8 LEDs angezeigt, drum bin ich ja so überzeugt davon, dass der Zustand am Port 129 ist ;-)
Der angeschlossene uC macht aber erst das, was er machen soll, wenn ich den Wert direkt in die if-Anweisung stelle :-k

Viele Grüße

[stefan_Z]

Könnte ggfs. ein Bug sein (riecht zumindest so)...
https://www.roboternetz.de/phpBB2/viewtopic.php?t=47297

Wenn man das Regfile per Conditional Compile einbinden will, dann wird immer nur die #IF Bedingung gewählt, egal welche Bedingung erfüllt ist.


Const Test = 1
#if Test = 0
$Regfile = "M32def.dat"
#Else
$Regfile = "M16def.dat"
#Endif

Ergebnis: immer M32def.dat

[chr-mt]

Hi,
unter der neuen Version 1.11.9.4 scheint es Probleme beim Zugriff auf das interne EEprom zu geben.
Ich habe das schon mal im MCS-Forum gepostet.
http://mcselec.com/index2.php?option=com_forum&Itemid=59&page=viewtopic&t=7458&sid=4253631a864454613efccb41d92ed412
Bugreport ist unterwegs zu MCS.

EDIT:

komischerweise ist der Fehler Heute weg und war nicht mehr reproduzierbar.
Habe auch einige Testprogramme geschrieben, die das EEProm ständig befüllen und auslesen.
Keine Fehler mehr feststellbar.
Warum auch immer.....


Gruß
Christopher

[Mitch64]

IDE 1.11.9.5

Vergabe von gleichen Namen für Labels und Konstanten werden vom Compiler nicht als Fehler erkannt. Die Kompilierung erfolgt fehlerlos.

Das Programm läuft aber nicht. Das Programm verzweit an die Adresse, die in der Konstante angegeben ist.

Das Problem trat auch schon bei Vorgängerversionen auf und ist unabhängig vom verwendeten Controller.

Das Problem habe ich nicht bei mcselec.com gemeldet, da der Zugriff auf die Supportseite verweigert wurde.

Beispiel:


Const Test1=1
Const Test2=2

gosub Test1
goto Test2

_Start:
Do
NOP
Loop

Test1:
' Code
Return

Test2:
' Code
goto _Start

Gruß Mitch.

[peterfido]

Ein Const bedeutet, dass der Compiler alle Stellen im Code durch die Konstante ersetzt.
Demnach müsste ein gosub Test1 das gleiche bewirken wie ein gosub 1, was natürlich zu einem Absturz führt.

[marvin42x]

Ich benutze zurzeit die Version 1.11.9.4.001
Windows XP Service Pack 2

Ich weis nicht ob man das folgende als Fehler oder als mimosenhaft bezeichnen soll. Es hat mich aber geraume Zeit gekostet bis ich dahinter kam da mein Programm doch scheinbar fehlerfrei war.

Beispiel:

bla
bla
bla
gosub Iam_start

Iam_start:
bla bla
Return


Wenn ich im Programm eine Sprungmarke habe und hinter dem Doppelpunkt ist ein Leerzeichen meckert Bascom das mit der Fehlermeldung: „unknown Statement[Iam_start]“ an.
Mache ich das Leerzeichen weg, also direkt hinter dem Doppelpunkt Return, ist er zufrieden.
Habe ich einen Kommentar beginnend mit einem Hochkomma hinter der Sprungmarke ist er auch zufrieden. da stören Ihn mit einem mal auch die Leerzeichen dazwischen nicht.

Netter Gruß

[ex535]

Hi,
Vers. 1.11.9.8 funktioniert.

Gruß
Kurt

[marvin42x]

Vielen Dank für die Überprüfung. ich werde nächstes mal lieber erst mal updaten.

Netter Gruß

[TomEdl]

Hallo!

Kleine Frage zwischendurch: Was ist denn eigentlich die neueste, funktionierende Bascom-Version? Ich hab schon ewig kein Update mehr gemacht und hab irgendwie total den Überblick verloren...


Grüße
Thomas

[chr-mt]

Hi,
1.11.9.8 ist die aktuellste Version

EDIT:
Habe gerade nochmal nachgesehen, die aktuelle Vollversion ist 1.11.9.9 !
Scheint ziemlich neu zu sein.
Die Demoversion ist noch die 1.11.9.8

Gruß
Christopher

[TomEdl]

Hi Christopher!

So nun hab ich das Problem: Ich finde keinen Updatewiz im Programmordner? Meine Version ist 1.11.9.5 .

Weiß da jemand Rat?


Grüße
Thomas

[chr-mt]

Hi Thomas,
du hast die Vollversion ?
Hast du dich schon registriert ?
Dann kannst du dir den Updatewizard unter "Registration/Updates" runterladen.

Gruß
Christopher

[TomEdl]

Hi Thomas,
du hast die Vollversion ?
Hast du dich schon registriert ?
Dann kannst du dir den Updatewizard unter "Registration/Updates" runterladen.

Habe ich soeben gemacht und meine BASCOM-Vollversion auf 1.11.9.9 geupdatet.
Danke für die Hilfe!


Grüße
Thomas

[TomEdl]

Hallo!

Soeben habe ich gesehen, dass es ein neues Update für Bascom gibt.
Die neue Version ist:
1.12.0.0

1.12.0.0
- Xmega caused a bug in non-xmega timer handeling : non xmega have a normal abd absolute address for IO regs which differ by 32. (normal registers space).
This offset was determinted too late, resulting in a wrong address for internal variables like timer0.
These special byte variables are now placed in the dat file.
This error was not visible when you compiled your code more then once! Only a fresh start and first compilation would reveal this bug.
- swap supports swap of double too. Also, swap with a single parameter can swap a nibble or 2 bytes:
swap b where b = &B11110000 will result in 00001111
for word/integer, it will swap the bytes : w=&B11110000_1100_0000 -> 1100_0000_1111_0000 or &HABCD becomes CDAB.
- bccard port parameter changed into full port name. See help.
- config twislave has a new option : userack=ON|OFF. When on, you can set ack/nack from your code. Also fixed a bug where the default setting did not save all registers.
- m32U4 : getadc() did not used ADC_MUX value from the dat file.
- myAVR programmer, changed error messages to info msg.
settings : 19200 baud.
- internal assembler allowed a backwards jump of 1 too many. in glcdeadogm128x6 this caused a wrong jump for chips>64KB.
- using $noramclear in combination with $initmicro could give an memory access error(invalid pointer).
- m32U4.dat file had missing mux5 bit, also corrected interrupt section.
- Windows 7-64 bit support added for LIBUSB.
- crc16 change for word sized arrays did not work for words but only bytes.
- internal loadbit routine which was rewritten in 11199 to check for boundery errors, had a bug for arrays with a constant index. The offset was 1 off.
this means that sombit=ar(3).8 would load the wrong bit location.
- RTF export will place the content in the clipboard too.
- power mode bug fixed: SE was not set when none of the SM bits were 1.
- usbasp (and other atmel programmers) gave a division by zero error for AT90XXXX chips (chips that do not use page programming)
- replaceChars string, oldchar,newchar will replace all characters in string.
- added tiny4313 support(programming untested)
- added button to insert $regfile, and $stack to the editor


Habe sie gerade runtergeladen aber noch nicht installiert und geteset.


Grüße aus Österreich
Thomas

[funkheld]

ist schon asbach.
bei euch österreichern dauert es wohl immer ewas länger als bei den bayern und die sind noch langsamer als die Nordländer...

ich habe schon die 1.12.0.1 zum test.

[PicNick]

Da hast du recht. Wir Ösis lassen neuer Zeug immer erst von den flotten Nordländern testen. Sollen die sich die Nase stossen. *g*

[hardware.bas]

Hoffentlich für 90 EUR kein Problem gekauft, wo bei der Gratisversion alles funktionierte, na dann, die bisherigen Probleme mit der Vollversion:
- Es funktioniert nur Speichern ohne Umbenennung (Save As fehlt)
- Viele Programme, welche in der Freeversion compilierbar sind, lassen sich bei der Vollversion nicht kompilieren.
- Dimensionierungen z.B. Dim Sp(9) as Byte geht nicht, brauch ich zum Auslesen des DS18S20
- BASCOM läuft seit Aufrüstung auf Vollversion dem ziemlich instabil
Für Hilfe wär ich dankbar. VG Micha

[hardware.bas]

Das Problem mit dem Umbenennen beim Speichern konnte ich lösen, denn es lässt sich in der Symbolleiste bewerkstelligen. Alle anderen Probleme, insbesonders mit dem Dimensionieren - ich habe es nochmals intensiv probiert - sind leider weiterhin vorhanden. VG Micha

[chr-mt]

Hi Micha,

Dimensionierungen z.B. Dim Sp(9) as Byte geht nicht
"SP" ist reserviert. Musst es also umbenennen.
Geht denn die Dimensionierung grundsätzlich nicht ?
Also zb. "Dim meine_variable(9) as byte"
Grudsätzlich vermeide ich solche kurzen Variablennamen, da man sich schlecht was drunter vorstellen kann.

Es funktioniert nur Speichern ohne Umbenennung (Save As fehlt)
"Save As" ist bei mir vorhanden und macht keine Probleme.

Viele Programme, welche in der Freeversion compilierbar sind, lassen sich bei der Vollversion nicht kompilieren.
Ist die Vollversion schon auf dem neuesten Stand ? (1.12.0.0 )
Hast du mal ein Beispiel, was sich nicht kompilieren läßt ?

BASCOM läuft seit Aufrüstung auf Vollversion dem ziemlich instabil
Was genau läuft denn instabil ? Abstürze ?
Ich habe bisher noch keine Probleme mit der neuesten Version gehabt.

Gruß
Christopher

[hardware.bas]

Hallo, Christopher,
vielen Dank für den Tip, ich habe nicht damit gerechnet, daß es in der
Vollversion zusätzliche Reservierungen gibt. Die Vollversion brauchte ich
für ein Projekt sehr kurzfristig, so daß ich mich nicht "extra" damit
eingelesen habe. Nun, es funktioniert nach den Umbenennen und damit
auch die anderen Programme, da Diese diesen Patch auch drin hatten .
Das einzige Problem ist noch die teilweise Instabilität auf dem Rechner,
jedoch vermute ich, daß es an der "älteren" Performance des Rechners
liegt. VG Micha

[raidy]

Erstes Byte im Eram nicht benutzen! Warum habe ich hier beschrieben: https://www.roboternetz.de/community/threads/55331-Bascom-Bug-in-quot-Dim-Variable-as-Eram-Byte-quot?p=528935&viewfull=1#post528935
Da es in C funktioniert und in Bascom nicht, liegt die Vermutung eines Fehlers in Bascom nahe. Aber ganz sicher bin ich nicht.

Ich beschreibe es nochmals kurz:

Wenn man im Programm Dim X a eram byte stehen hat, ist das erste Byte im Eram zwar beschreibbar, aber nicht mehr richtig lesbar. Und es bleibt auch nicht im Speicher.
Deshalb empfehle ich, das erste Byte wie folgt zu blockieren:

Dim Bascom_Bug As Eram Byte ' wichtig: erste dim Anweisung für Eram dieses Byte nicht im Prgramm verwenden!
Dim X As Eram Word ' ab jetzt gehen alle Eram Variablen


Bascom Version 2.0.7.0, Fehler aber auch schon in 1.x.y.z

[for_ro]

Hallo raidy,
dieser Hinweis steht schon seit 2004 in der Hilfe zu WriteEEProm:

According to a data sheet from ATMEL, the first location in the EEPROM with address 0, can be overwritten during a reset. It is advised not to use this location.

Begründung ist, dass die Speicherzelle überschrieben werden kann, wenn es beim Starten zu schwankender Versorgungsspannung kommt oder bei zu niedriger Spannung im Betrieb.
Daher wird empfohlen, den Brown-Out Detektor zu verwenden, damit der Controller definiert abgeschaltet wird.

Würde ich jetzt nicht wirklich als Bascom Bug bezeichnen.

[raidy]

Danke für den Hinweis. Ich habe Nächtelang nach dem Fehler gesucht und du machst einfach klick und da isser. Wer hätte da auch an einen Fehler des AVR gedaxht wo doch 99,9% der Fehler vom User kommen.
Ja, es ist dann kein Fehler von Bascom. Aber ich würde entweder in der Doku drauf hinweisen oder im Compiler erst beim 2.ten Byte anfangen.

[Thomas E.]

Ich scheine nun auch einen Bug entdeckt zu haben: Bei anhaken der Checkbox "Terminal" im Simulator stürzt Bascom komplett ab. Bascom-Version: 2.0.7.6
:(

[raidy]

Ich scheine nun auch einen Bug entdeckt zu haben: Bei anhaken der Checkbox "Terminal" im Simulator stürzt Bascom komplett ab. Bascom-Version: 2.0.7.6
:(
Bekannt. Deine Schnittstellenparameter stimmen nicht! Prüfe, welche COM Schnittstelle eingestellt ist und wie die Einstellungen in der Systemsteuerung sind.

[Thomas E.]

Bekannt. Deine Schnittstellenparameter stimmen nicht! Prüfe, welche COM Schnittstelle eingestellt ist und wie die Einstellungen in der Systemsteuerung sind.
Ich habe COM3 eingestellt, worüber manchmal auch "reale" RS232-Kommunikation stattfindet.

[raidy]

Dann kann ich dir auch nicht helfen, bei mir gehts.

[jo_robot]

Bin mir nicht sicher ob das als Bug läuft, aber

Bascom Version 2.0.7.5.003 fehlt eine m324Adef.dat Der Chip mit der id: 0x1E9515 wird nicht erkannt.

[Dnerb]

Ich habe COM3 eingestellt, worüber manchmal auch "reale" RS232-Kommunikation stattfindet.

Wenn da reale Kommunikation läuft, dann kann natürlich Bascom in dem moment nicht darauf zugreifen. -> Problem

[Thomas E.]

Wenn da reale Kommunikation läuft, dann kann natürlich Bascom in dem moment nicht darauf zugreifen. -> Problem
Nein, die reale Kommunikation findet nicht in jenem Moment statt, in der ich den Simulator benutze (kein Terminalprogramm geöffnet). Trotzdem stürzt Bascom ab. :(

[kritias]

Bug Report:

Betrifft Bascom nach dem letzten Update auf 2.0.7.7
Hier liegt ein Fehler bei der Berechnung von Single-Variablen vor. Wenn man eine Variable nur oft genug mit 0.9 multipliziert, wird die wie erwartet 0. Wenn man weiter macht wird sie irgendwann NAN und dann irgendwann irgendwas ganz großes. Hier ein Beispielprogrämmchen mit dem der Fehler auf einem xmega nachvollzogen werden kann.


$regfile = "xm256a3def.dat"
$crystal = 32000000 '32MHz
$hwstack = 256
$swstack = 256
$framesize = 256
$lib "xmega.lib"
$external _xmegafix_clear
$external _xmegafix_rol_r1014

Config Portf.3 = Output
Config Portf.2 = Input

Dim A As Single
Dim Loopcount As Long

Config Osc = Enabled , 32mhzosc = Enabled
Config Sysclock = 32mhz , Prescalea = 1 , Prescalebc = 1_1
Config Com7 = 9600 , Mode = Asynchroneous , Parity = None , Stopbits = 1 , Databits = 8

Open "COM7:" For Binary As #1
A = 10
Wait 5
Do
Incr Loopcount
A = A * 0.9
Print #1 , Loopcount ; " " ; A
Loop


Der Fehler tritt nach 853 Durchgängen (NAN) und nach 1485 Durchgängen (3924871168.0) auf. Ändert man die Zeile A=A*0.9 in
A=A*9
A=A/10
funktioniert alles einwandfrei. Es scheint, daß der Fehler nur bei Multiplikationen von sehr kleinen Werten auftritt. Ob es noch andere Fälle gibt ist mir zumindest nicht bekannt. Bei Bascom 2.0.7.6 tritt der Fehler nicht auf.

[kritias]

Das ist kein Bug. Das war die NSA!
http://www.elektor.de/news/EmbedNet-Mikrocontroller/

[kritias]

Es gibt Neuigkeiten. Mark Alberts hat ein Update veröffentlicht. Einfach in Bascom auf Hilfe und Update. Der ganz normale Vorgang.

An dieser Stelle nochmal besonderen Dank an Mark Alberts für die extrem schnelle Reaktion.

[Searcher]

BASCOM-AVR Demo Version 2.0.7.5 auf ATTiny25

Es ist kein unmittelbarer Fehler, den ich in BASCOM-AVR Version 2.0.7.5 festgestellt habe, aber doch ein Verhalten, daß eine intensive Fehlersuche zur Folge hatte.

Zum schnellen Datenaustausch hatte ich eine Interruptserviceroutine in Assembler mit auch noch einem timingkritischen Abschnitt darin ohne Sichern der Prozessorregister (bzw manuellem Sichern, Stichwort: nosave) geschrieben.

Da es zu Problemen kam, nahm ich das Programm mittels Disassembler unter die Lupe und fand heraus, daß BASCOM ohne Meldung Assemblerbefehle austauscht, anstatt eine Fehlermeldung oder zumindest eine Warnung zu erzeugen. Außerdem wird dabei ein Register benutzt, daß man in einer "nosave ISR" möglicherweise nicht gesichert hat. Siehe Kommentare im Code:

'### Verkürztes kompilierbares Demo zur Problembeschreibung
'### BASCOM-AVR Demo Version 2.0.7.5 (Compiler Version 2.0.7.5)
'
$regfile = "ATtiny25.DAT"
$framesize = 32
$swstack = 32
$hwstack = 34
$crystal = 16000000

Pcmsk = Bits(pcint3 , Pcint4)
On Pcint0 Isr_receive_data_compelled Nosave 'keine Register sichern
Enable Pcint0
Enable Interrupts

Do
Loop

End 'end program


Isr_receive_data_compelled:

sbi gifr, pcif 'löschen Interrupt Flag

'### Mit Bascom assembliert und dann mit ReAVR von ja-tools zum Überprüfen
'### disassembliert zeigte, daß aus der SBI Zeile ohne Warnung Folgendes entstand
'### und dabei r23 verändert wurde.
'###
'### lds r23,(p3A+0x20) ; io register
'### ori r23,k20
'### sts (p3A+0x20),r23 ; io register
'###
'### OK, SBI kann nicht auf das GIFR im ATTiny25 zugreifen, da das Register außerhalb
'### des Adressbereiches von SBI liegt.
'###
'### In einer ISR, die keine Register sichert kann die Änderung von r23 OHNE Warnung
'### aber fatal werden. Bei zeitkritischen Routinen können außerdem die zusätzlichen
'### Takte des Ersatzcodes noch graue Haare wachsen lassen wenn man von dem Austausch
'### zunächst nichts mitbekommt - Programm läuft ja eigentlich.

Return

In der gleichen "nosave ISR" verwendete ich folgendes Kommando:
Loadadr Flash_data(write_block_array_pointer) , X
Hier wird das Register r10 verändert. (Das X für r26, r27 steht, ist normalerweise bekannt)

Problem ist nicht weitergemeldet und vielleicht ist das ja auch irgendwo dokumentiert.

[kritias]

Ich gehe da immer so vor:
ich schließe zeitkritische Teile mit einer Menge NOP ein und kompiliere das ganze. Das Ergebnis sehe ich mir dann im AVR-Studio in Assembler an. Durch die vielen NOPs ist die Stelle auch leicht zu finden. Den Zeitkritischen Assembler-Teil optimiere ich dann. Also das unnötige wegspeichern der Register entfernen, so wenige wie möglich Register verwenden und was einem sonst so auffällt. Dann muss ich im Falle eines Interrups nur noch die verwendeten Register sichern. (Nosave!) Dabei hat Bascom noch nie etwas einfach so geändert.Die NOPs kommen nach getaner Arbeit weg. Verzählen darf man sich halt nicht wenn man den Stack von Hand beackert. Da hab ich schon meine bösen Überraschungen erlebt. War dann aber meine Dummheit und kein Fehler von Bascom.

[Searcher]

Ich gehe da immer so vor:
.
.
Ja, so oder so ähnlich werde ich das auch in Zukunft machen. Ich war halt total überrascht, daß ein Assemblerbefehl ausgetauscht wurde. Mit gutem und richtigen Grund, da ja auf einem ATTiny25 ein SBI GIFR,PCIF nicht möglich ist. Das sollte aber bei einem Assembler Befehl nicht ohne dicke rote Warnung geschehen. Der Compiler/Assembler hat ja erkannt, daß da etwas nicht paßt und könnte eben auch eine Meldung erzeugen. Vielleicht wurde auch in höheren Versionen da schon etwas vorgesehen.

Bei LOADADR mit einem indirekt adressierten Array als Argument würde mich ein Hinweis auf das zusätzlich verwendete Register zufrieden stellen :)

Ich hatte bisher in nosave ISRn immer nur die Register gesichert, die ich auch selbst in der ISR verwendet habe. Trotz der möglichen Verbesserungen finde ich den einfachen Gebrauch von Assembler innerhalb von BASCOM Programmen genial.

Gruß
Searcher

[Searcher]

sbi gifr, pcif 'löschen Interrupt Flag

'### Mit Bascom assembliert und dann mit ReAVR von ja-tools zum Überprüfen
'### disassembliert zeigte, daß aus der SBI Zeile ohne Warnung Folgendes entstand
'### und dabei r23 verändert wurde.
'###
'### lds r23,(p3A+0x20) ; io register
'### ori r23,k20
'### sts (p3A+0x20),r23 ; io register
'###
'### OK, SBI kann nicht auf das GIFR im ATTiny25 zugreifen, da das Register außerhalb
'### des Adressbereiches von SBI liegt.
'###
'### In einer ISR, die keine Register sichert kann die Änderung von r23 OHNE Warnung
'### aber fatal werden. Bei zeitkritischen Routinen können außerdem die zusätzlichen
'### Takte des Ersatzcodes noch graue Haare wachsen lassen wenn man von dem Austausch
'### zunächst nichts mitbekommt - Programm läuft ja eigentlich.



Was mir gerade bewußt geworden ist. Diese Zeilen

lds r23,(p3A+0x20) ; io register
ori r23,k20
sts (p3A+0x20),r23 ; io register
die BASCOM statt dem "sbi gifr, pcif" eingesetzt hat, löschen nicht nur das PCI-Flag, sondern alle Interrupt Flags im GIFR. Übel! Das "ori" ist gut um in anderen Registern Bits zu setzen aber gar nicht gut um ausgewählte Interrupt Flags zu löschen.

Gruß
Searcher

[Searcher]

Da es zu Problemen kam, nahm ich das Programm mittels Disassembler unter die Lupe und fand heraus, daß BASCOM ohne Meldung Assemblerbefehle austauscht, anstatt eine Fehlermeldung oder zumindest eine Warnung zu erzeugen.
Ich hatte dieses Verhalten doch noch an mcs gemeldet, da ich beim Löschen eines Interrupt Flags dadurch echte Fehler bekam und habe auch Antwort bekommen.

Kurz: Das Verhalten ist kein Fehler, sondern ist so designed. Es gibt aber einen switch, mit dem man den Austausch der asm Befehle verhindern kann. Bei Verhindern des Austausches mit dem switch kommt es dann zu einer Fehlermeldung in meinem Beispiel. Tja, hätte ich die Doku doch vorher gründlicher, noch gründlicher gelesen :cool:

Der switch ist "$notransform on". Steht in der Doku zwar mit Doku-Fehlern, die aber von mcs noch behoben werden.

Der switch wird ab sofort bei mir in Verbindung mit asm intensiv genutzt werden!

Gruß
Searcher