SPI documentation

[A.Harrenberg]

Hi PoltoS,

a debugging tool would be helpfull...
I also had some trouble using the serial debugging as this also seems to have an impact on the freeze/reset of the sketch. I think that this really could be an issue with the stack.

I can try to change the variables to global and change some of the functions for the library, but that would require a much deeper analysis of the library and will make it very hard to update if the Arduino library is changing. But for the porting I am right now stuck with that "unknown error" that I can't track as there is no file/line number. I don't know if it is possible for you to increase the verbose level of uCxx compiler here to give out more information or if I can use another tool chain to find the cause of the error.

You mentioned that you will release an example for an RFID, what library are you using? Is the communication also via SPI or is it with based on I2C?

Regards,
Andreas.

[PoltoS]

If Seial.print makes freezes more often, it is due to stack overflow.

The example of our RFID is using serial. http://z-uno.z-wave.me/examples/125khz- ... door-lock/

[A.Harrenberg]

Hi PoltoS,

ok, then I will try to change the smaller library to use more gobal variables and try to understand where stack space is used during calls and will minimize stack allocation if possible. If that helps running the sketch for longer time it might make the first library work.

I will have a look at the serial RFID reader you used, I haven't noticed the example yet and the cheap set are usualy SPI or I2C and require programming of the used chip.

Is there any way to have the used stack reported from the low level sketch to the user sketch?

Regards,
Andreas.

[PoltoS]

Is there any way to have the used stack reported from the low level sketch to the user sketch?

You can actually see in sdcc. User sketch have about 40-60 bytes only.

What we want to do is to allocate some 5 bytes at the end and sent a notification (or sent a Config param) that will report error code to the gateway. Like stack limit reached.

[A.Harrenberg]

Hi,

do you mean the small statistics at the end of the compile? It is saying

Code: Select all

Sketch uses 9,903 bytes (30%) of program storage space. Maximum is 32,256 bytes.
Global variables use 238 bytes of dynamic memory.

Other than that I can onyl find a "main.mem" file where the 238 bytes also show up as external RAM. It also states that there are 143 bytes available on the stack, but that is the case for all sketches.

Code: Select all

Internal RAM layout:
      0 1 2 3 4 5 6 7 8 9 A B C D E F
0x00:|0|0|0|0|0|0|0|0| | | | | | | | |
0x10:| | | | | | | | | | | | | | | | |
0x20:|B|B|B|B|T| | | | | | | | | | | |
0x30:| | | | | | | | | | | | | | | | |
0x40:| | | | | | | | | | | | | | | | |
0x50:| | | | | | | | | | | | | | | | |
0x60:| | | | | | | | | | | | | | | | |
0x70:|a|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0x80:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0x90:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0xa0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0xb0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0xc0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0xd0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0xe0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0xf0:|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|S|
0-3:Reg Banks, T:Bit regs, a-z:Data, B:Bits, Q:Overlay, I:iData, S:Stack, A:Absolute

Stack starts at: 0x71 (sp set to 0x70) with 143 bytes available.

Other memory:
   Name             Start    End      Size     Max     
   ---------------- -------- -------- -------- --------
   PAGED EXT. RAM                         0      256   
   EXTERNAL RAM     0x3000   0x30ed     238    65536   
   ROM/EPROM/FLASH  0x0000   0xa6af    9903    65536   

Could you please clarify where exactly the I can find the information about the stack use?

Regards,
Andreas.

[p0lyg0n1]

working with the simple library for the RCF522

UGH
If you look to it's assembler listing you din't say that it's "simple".
look inside ZUNO_MFRC522_ucxx.rst
method "PICC_Select"

Code: Select all

                                    2458 ;------------------------------------------------------------
                                   2459 ;Allocation info for local variables in function '__cxx__MFRC522__method__PICC_Select02prUid05'
                                   2460 ;------------------------------------------------------------
                                   2461 ;uid                       Allocated to stack - _bp -4
                                   2462 ;validBits                 Allocated to stack - _bp -5
                                   2463 ;v__this                   Allocated to registers r6 r7 
                                   2464 ;uidComplete               Allocated to stack - _bp +18
                                   2465 ;selectDone                Allocated to stack - _bp +19
                                   2466 ;useCascadeTag             Allocated to stack - _bp +20
                                   2467 ;cascadeLevel              Allocated to stack - _bp +21
                                   2468 ;result                    Allocated to registers r4 
                                   2469 ;count                     Allocated to stack - _bp +22
                                   2470 ;index                     Allocated to stack - _bp +23
                                   2471 ;uidIndex                  Allocated to stack - _bp +24
                                   2472 ;currentLevelKnownBits     Allocated to stack - _bp +25
                                   2473 ;bufferUsed                Allocated to registers r3 
                                   2474 ;rxAlign                   Allocated to stack - _bp +26
                                   2475 ;txLastBits                Allocated to stack - _bp +27
                                   2476 ;responseBuffer            Allocated to stack - _bp +28
                                   2477 ;responseLength            Allocated to stack - _bp +30
                                   2478 ;bytesToCopy               Allocated to stack - _bp +31
                                   2479 ;maxBytes                  Allocated to registers r4 
                                   2480 ;valueOfCollReg            Allocated to registers r5 
                                   2481 ;collisionPos              Allocated to registers r5 
                                   2482 ;sloc0                     Allocated to stack - _bp +14
                                   2483 ;sloc1                     Allocated to stack - _bp +16
                                   2484 ;sloc2                     Allocated to stack - _bp +26
                                   2485 ;sloc3                     Allocated to stack - _bp +27
                                   2486 ;sloc4                     Allocated to stack - _bp +13
                                   2487 ;sloc5                     Allocated to stack - _bp +3
                                   2488 ;sloc6                     Allocated to stack - _bp +5
                                   2489 ;sloc7                     Allocated to stack - _bp +7
                                   2490 ;sloc8                     Allocated to stack - _bp +9
                                   2491 ;sloc9                     Allocated to stack - _bp +11
                                   2492 ;sloc10                    Allocated to stack - _bp +1
                                   2493 ;buffer                    Allocated with name 

So, it used +32 - (-4) + 2(to be returned) = 38 bytes of stack!!!

You can reduce it using these techniques:
1. Use global vars instead of local.
2. Reduce number of passing parameters of you can.
Passing structure is only gives 2-3 bytes inside stack.
Passing long(32 bit) value as its pointer pointer is a good idea.
3.Use byte instead of int if you can (You store/calculate values < 0xFF). On 8bit ucontrollers byte vars is pretty good.
4.Use word instead of long if you can (You store/calculate values < 0xFFFF).
5.Chop you code in small subroutines. Don't do a lot of nested functions.
6.Try to reduce a number of nested functions.
7.Move all static-functions and another code that can be static outside the class.

We have only about 120-140 bytes of stack for our functions on 8051.
It's not simple for the first time, but It increases our programming skills =)
Some complex Arduino library like yours have to be ported step by step. Good luck.

[A.Harrenberg]

Hi p0lyg0n1,

So, it used +32 - (-4) + 2(to be returned) = 38 bytes of stack!!!

the example you showed here is from the larger, more complex library, but I haven't checked for the other one, could be similar.

So I have to look into the *.rst output and count the variables to see how much stack will be used? I will try to make some changes and see how the values (hopefully) decrease.

You can reduce it using these techniques:

I will try the things you mentioned here, but the problem is that I will most likely end up with a new library and not only a port of the Arduino library... Almost all functions are "publice" and might be used by the example sketches or other sketches for the MFRC522. At the moment I can't estimate if it is possible to keep the current interface, but I will find out

We have only about 120-140 bytes of stack for our functions on 8051.
It's not simple for the first time, but It increases our programming skills =)
Some complex Arduino library like yours have to be ported step by step. Good luck.

Yes, 120 byte is not sooo much, is it in total including the boot loader sketch or is it just for the user sketch? I fear it is the total number...
Using 38 bytes in a single sub-function is then a comparable high usage...

For the moment I think I go back to the smaller lib that already compiles (but crash the ZUNO) and will try to see what the stack usage is here and see if I can reduce that and get the sketch running.

As I get some other and somehow strange compiler errors which you don't have with the other library and user michap has the same expirience with another sketch, it seems that you are already using an updated version of the toolchain and we have to wait for an update. Or is there a difference between using WIndows/MAC/Linux? (I think you are using a MAC?)

Porting some code step by step is ok, but if the code does not compile and very generic error messages like "unknow error" pops up without a line number than it is a little bit frustrating.

Best regards and thanks for all your help and the tips,
Andreas.

[PoltoS]

Here is a quick sketch with SPI http://z-uno.z-wave.me/examples/74hc595-shift-register

[A.Harrenberg]

Hi,
nice example, will see if I have a 74hc595 somewhere to make a "knight rider" ,-)