View previous topic :: View next topic |
Author |
Message |
andrge
Joined: 26 Oct 2011 Posts: 30 Location: Kaufbeuren
|
Posted: Mon Nov 01, 2021 5:20 pm Post subject: Print problem with different bascom versions, ATXMega256A3BU |
|
|
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 ) |
|
Back to top |
|
|
Evert :-)
Joined: 18 Feb 2005 Posts: 2156
|
Posted: Mon Nov 01, 2021 7:24 pm Post subject: |
|
|
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. _________________ www.evertdekker.com Bascom code vault |
|
Back to top |
|
|
andrge
Joined: 26 Oct 2011 Posts: 30 Location: Kaufbeuren
|
Posted: Mon Nov 01, 2021 8:07 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
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 _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Wed Nov 03, 2021 2:17 pm Post subject: Re: Print problem with different bascom versions, ATXMega256 |
|
|
andrge wrote: | -> from the main I jump into a sub routine
-> from this sub I jump again into a sub routine. |
Does "jump" actually means "gosub"?
Correct syntax is to call a subroutine, a label is jumped to, a sub is called.
If you do recursions somewhere in your code, intentionally or not, the hw-stack is easily used up.
You should have plenty of SRam left (check the report), if you increase hw-stack to 500 and the problem does not appear or only later, it is a hint for a stack-hole.
Another test would be to preload said vars immediately at program-start and then also immediately call mentioned sub-routines.
If it prints correctly then, you have a hint for loosing stack memory in a hole.
If it does not print correctly, then the hex-files from these different compiler versions can be disassembled and looked up for the difference in question. |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Mon Nov 08, 2021 2:50 pm Post subject: |
|
|
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. _________________ Mark |
|
Back to top |
|
|
|