Compilererror .... very strange

1
2
Seite 2 von 2

miparo

PowerUser

Geschlecht:
Herkunft: Germany
Alter: 59
Beiträge: 1003
Dabei seit: 09 / 2007

Betreff:

Re: Compilererror .... very strange

· Gepostet: 21.03.2026 - 10:55 Uhr · #9

Moin,
naja irgenwas ist ja dubios hier:
Es sind mit einer Zeile weniger -14 bytes const Flash String plus etwas Call Overhead alles OK und nur 77kB Flash verbraucht !

Aktive ich dan die gDrawString(.... ) Zeile sollen 51kB weg sein ?

Im Prokekt Info sieht man ja , das ROMconst 65kB belegen, wenn die fixed bei $10000 anfangen, was ich vermute dann passen die paar User const nicht mehr rein ? Das wäre dann ein Compiler Kalkulationsfehler, der schon seit V5 besteht.

Evtl. StepAccValue,StepCount testen, ob sich die Tabelle verkleinert.

Rolf können wir leider nicht mehr fragen, was er sich dabei gedacht hat.

miparo

Der an diesem Beitrag angefügte Anhang ist entweder nur im eingeloggten Zustand sichtbar oder die Berechtigung Deiner Benutzergruppe ist nicht ausreichend.

Merlin

Administrator

Geschlecht:
Alter: 26
Beiträge: 1497
Dabei seit: 03 / 2005

Betreff:

Re: Compilererror .... very strange

· Gepostet: 22.03.2026 - 10:46 Uhr · #10

I may be able to offer some insight into what Rolf was thinking.

The Mega128 has 128K bytes of memory, The LPM instruction can only directly access 64K of memory and an additional register is used to access which of the two 'pages' of ROM is accessed. To load this additional register every time is clearly both time and space inefficient. Therefore (I imagine) Rolf took the decision that tables like this must not cross this 64K boundary. In addition (I imagine to help the situation) strings always reside in the second page.

That means that if a table crosses the 64K boundary, even by one byte, the entire table must be moved to the second page. This can be triggered by, for example, adding a single line of code.

That, I believe, is what you are seeing here.

This all, of course, just speculation.

miparo

PowerUser

Geschlecht:
Herkunft: Germany
Alter: 59
Beiträge: 1003
Dabei seit: 09 / 2007

Betreff:

Re: Compilererror .... very strange

· Gepostet: 22.03.2026 - 13:55 Uhr · #11

Hi Merlin,
Probably because ROM constants are always placed at the end of the flash memory, but here the massive 60 KB acceleration block comes first, leaving hardly any room for Harry's string constants, which is why the flash overflows even though there's still enough space in the lower 64 KB.

Solution: Make the table smaller by adjusting the step size, etc., and allocate your own strings toward the bottom.?

miparo

Merlin

Administrator

Geschlecht:
Alter: 26
Beiträge: 1497
Dabei seit: 03 / 2005

Betreff:

Re: Compilererror .... very strange

· Gepostet: 22.03.2026 - 17:20 Uhr · #12

Hi MiParo

As you noted all rom constants come at the end and in this case are all in second page for this device. I had thought that they were spread through the program but clearly I was wrong. Keeping all ROM constants one one page certainly makes sense from the compiler's perspective.

All of that means that you have at most 64K for rom constants.

Trying to allow these constants to be distributed across multiple 64K blocks would be a massive undertaking which, frankly, I am not prepared to do.

Harry

Moderator

Geschlecht:
Herkunft: zwischen Augsburg und Ulm
Alter: 61
Beiträge: 2170
Dabei seit: 03 / 2003

Betreff:

Re: Compilererror .... very strange

· Gepostet: 22.03.2026 - 20:45 Uhr · #13

Hello @ all,

Could someone explain to me what this huge constant table is for?

As I said, I'm working in user mode, so my only output signals are Step and Dir. Shouldn't a simple linear acceleration be calculable based on the propagation time? I've looked at this table, and there's not much information in it.

A simple frequency generation should be sufficient?

Regards
Harry

1
2
Seite 2 von 2

Compilererror .... very strange

Registrierte in diesem Topic