Print problem with different bascom versions, ATXMega256A3BU

andrge · Joined: 26 Oct 2011 Posts: 30 Location: Kaufbeuren

Hello,

I have a big project (~168k) with a ATXMage256A3BU. With Basom version 2.0.8.1 all works very well.
With all new versions I have the following problem:
-> from the main I jump into a sub routine
-> from this sub I jump again into a sub routine. Here a print command is executed for about 10 integer and word variables in one line. With version 2.0.8.1 everything ok. The variable values are printed correctly.
With all newer versions the variable values are not printed correctly, but some byte values. However, the variable values are correctly present. I can see it because the values are processed further and used in other functions.
It is exactly the same code. I only changed the Bascom version. The behavior is reproducible. I have the impression that it is a problem of the push and pop function. Can it be that the newer versions have less memory reserved here? The problem only exists when many variables are output in one line per pint command.

I have tested version 2.0.8.2, 2.0.8.3 and 2.0.8.4. The same result for all of them.

Can help further here? Possibly this is a topic for Mark?

Best regards

Andreas

(BASCOM-AVR version : 2.0.8.4 )

Evert :-) · Joined: 18 Feb 2005 Posts: 2156

The first that's cumming up in my mind is that your stack is too low.
Can you share us your settings and preferable some code to test.

andrge · Joined: 26 Oct 2011 Posts: 30 Location: Kaufbeuren

Hello Evert

unfortunately I can only upload parts of the code here. The project has 24 includes! Will provide everything what goes.
I am not sure if parts of the code show the problem. Possibly it is the result of all the variables in sum.

Here the settings
$regfile = "xm256a3budef.dat"
$crystal = 32000000
$hwstack = 100
$swstack = 200
$framesize = 400

Best regards

Andres

i.dobson · Posted: Tue Nov 02, 2021 6:35 pm Post subject:

Hi,

If you think the problem is stacks, maybe try increasing them and see if the error changes or goes away.

If you really want to understand whats going on the stacks have a look at "stackcheck.lib" and the stackcheck.bas sample code.

Regards
Ian Dobson

MWS · Joined: 22 Aug 2009 Posts: 2262

albertsm · Joined: 09 Apr 2004 Posts: 5922 Location: Holland

you need to check if you actual tested with 2084. (check the rpt file).
in older versions one version existed for num>str conversion.
with Xmega that no longer worked because you can not point to a register with X,Y,Z.
A workaround was made by mapping registers to SRAM.

With Xtiny there was the same problem. So a different approach was used : a pointer to framespace was used. that worked fine until a customer used str() inside a print like : print str(number)
It led to a situation where the same framespace was used. the solution is to use print number since print will automatic convert numbers to strings anyway. using str() with print is not advised or required.
anyway, to fix that problem an offset was added to the framespace. the only downside is that this requires the user to use more framespace.
but that is it. that is how 2084 handles it.

for 2085 the code was optimized so it would not use the framespace. but it will use the special _xmegareg / _xtinyreg space.