Thank you for the advice! However, Even I stripped the delay.h to the smallest possible, I still got a SRAM full error.
Here is my source code: https://gist.github.com/Kashouryo/fcf1a8a6995ab7934b9abf936646f6ad
||ASlink-Warning-RAM value 134 too large (128B max)|
Ok, I see the problem now.
The _delay_us(us) macro is meant to be used with constants that are used to calculate the correct number of delay cycles at build time, not variables that would require the calculation at run-time.
So, use this:
_delay_us(100);
... instead of this:
uint8_t testVal = 100;
_delay_us(testVal);
If you really need something that is more variable at run-time you will have to come up with a different solution.
It looks like you are running at 1MHz, so each cycle is already 1uS. So, technically you could skip all the 'calculation' and just call the delay loop directly. But, there is overhead in calling the delay function as well as the delay loop (7 cycles overhead, 3 cycles per loop) that would still have to be taken into account.
For short delays, you don't really need the abstraction that the delay function provides, you could just directly do something like the following (inline assembly), but you still have to take into account the overhead (3 cycles overhead (2+1), 3 cycles per loop).
uint8_t testVal = 32; // 2 cycles - value = ((100uS -3) /3)
__asm
00001$: // 3 cycles per loop
dzsn _testVal // 1 cycle + 1 cycle for final skip
goto 00001$ // 2 cycles
__endasm;
You might be able to put some/most of this in a macro and/or possibly SDCC would already generate optimal loop code by just using a while (--testVal); loop or something similar.
Do you have a more complete example of what you are trying to accomplish?
Home
Help
Search
Login
Register
