Other Parts Discussed in Thread: REMOTI
Hi,
I am about to finish HAL for my new CC2530-based pcb and encountered one problem.
I developed my own custom DMA controller that dynamically allocates and releases DMA channels instead of having dmaCh0 and dmaCh1234 global variables. I used that all along in my code (I need to use DMA for RF, USART, AES, etc.) and the reason why I decided to have this dynamic dma channels allocation is that there is only 5 channels and I have more places where I want to use them. Of course I won't use them all at the time so dynamic allocation makes a lot of sense.
However...
When I wanted to enable SECURITY flag in linker configuration file I got this error:
Warning[w7]: Module hal_aes declared twice, once as program and once as library. Redeclared in file D:\Projekts\CC2530\proj\lib\Security.lib, ignoring library module.
Source for "hal_aes.c" was missing in ZStack source code but I found it in RemoTI source code and used it.
Then when I exclude hal_aes.c module from compilation I get:
Error[e46]: Undefined external "dmaCh1234" referred in hal_aes ( D:\Projekts\CC2530\proj\lib\Security.lib )
Is it safe to let linker overwrite hal_aes module in Security.lib using code from hal_aes.c? I tried to find what IAR linker could do in such situation but I failed. Is there any chance that next ZStack version would use globally declared pointers to functions in HAL instead of using dmaCh0 and dmaCh1234 variables on its own?
Why don't ZStack developers use globally declared pointers to functions in HAL layer that is supposed to be implemented by application developer but they include and compile AES stuff in Security.lib? In this example - how do I suppose to know which DMA channel is being used by Security.lib?
/ Lukasz
