Are you happy with the controlSUITE directory structure?

Andreas all valid points,  I can answer the DPLib question, and i did think about this while writing the DPlib,

The 2P2Z and 3p3z sections, we do force them into a single DP section, however when we have multiple 2p2z and 3p3z i.e. greater than 6-7, which we have on our LED lighting Kits that use the Digital Power Library, this results in an erroneous behavior as not all the variables can be stored on the same data page pointer and any assumption of such would lead to a problem.  Please see the compiler guide where is states if the Data Page cannot fir all the variables being forced into the same section it would cross across data page boundaries.

Nevertheless i would agree if we have an instance based DP force and and an instance based section for the modules would work best in terms of cycle but may lead to memory usage increasing, however this method is not possible under the current DPlib framework. As always a trade off b/w memory and cycles :)

However if you are not using that many 2p2z or 3p3z you can remove the DP reload inside the macro's the reloads were done to keep it from breaking when your application uses too many 2p2z's :) and we have seen this happen

Regards

Manish Bhardwaj

Andreas,

Thank you for your feedback. 

andreas von kaenel said:

• why are the two header files PeripheralAdress_ASM.h and PeripheralHeaderIncludes.h in the "development_kits" folder and not in the "device_support" as all other header files are. If one would not touch the controlSUITE every time a new version comes out and copy the files to the desired places, it is necessary to check in the development_kits" dir into source control - which is nonsens.
• Why do you distribute two different versions of GlobalVariableDefs.c - one in "development_kits/source" and one in "device_support/f2802x/v12x/DSP2802x_headers"

Up until controlSUITE system projects and device support projects were all separately released.  We found this was adding duplication of work on our side and confusion on the customer side.  Part of the goal of controlSUITE is to present a unified release for all collateral.  To this end we have started to merge the work between the groups so the efforts are not duplicated.  For example the IQmath library used to be included in individual projects but within controlSUITE all projects can use the same library in its release directory.   This effort is still a work in progress and your feedback is valuable to us in pointing out areas where we can still improve. 

andreas von kaenel said:

The naming of the file DSP2802x_Examples.h seems strange to me what has this to do with examples?? for example: device_cal is a mandatory function for the processors and not related to any of the examples...

The original intent was to spike out what was required if a user only wanted to use the header files and did not want any of the sample code. 

I agree that in some cases the example code is very important and perhaps should be highlighted as not optional.   For device_cal() the boot ROM does perform this function so technically it doesn't have to be in the end application.  Still it is important for customers to understand this is needed especially during debug when the boot ROM may be skipped over.

andreas von kaenel said:

Why do you distinguish between "common" and "headers" in the device support directory - the headers directory contains source files anyway so these two folders could be merged, imho

If a user only wants to use the header files and none of the example code, then they only have to pickup the headers directory and can toss the rest.    The source files in the "headers" directory are required to map the bit field structures to memory.  

andreas von kaenel said:

Why don't you force the 2P2Z / 3P3Z Memory Sections to be in one single datapage? For the 2P2Z you could save 5 cycles/call by not reloading the DP everytime a new terminal pointer is accessed. That is not the world, but anyway.

Excellent point.  I will feed this back to the owners of the code.

Best Regards,

-Lori

Andreas,

To answer your questions on 1 and 2:
A fair amount of this stuff (in fact most of the ~SupportFiles directory under development_kits) is at least partially legacy and show what still needs to be consolidated in controlSUITE.
PeripheralAddress_ASM.h - is soon to be phased out and will eventually dissapear from controlSUITE
PeripheralHeaderIncludes.h - needed currently.  Over time, much of the information in this header will eventually move to xxxx_Device.h  in the "header" files device specific directory.  This is partially in the works.
GlobalVariableDefs.c in development_kits - Once PeripheralHeaderIncludes.h is no longer needed, projects will only use the one in the device support directory and the copy in development_kits will go away.


Thanks,
Brett

Hi Manish,

Thanks for the explanation - of course I did not consider this requirement (many 2P2Z / 3P3Z modules). However you said you are forcing the section being in the same datapage, where do you do this? I would expect a "block" directive in a cmd file or something similar but I didn't find anything, can you guide me ?

Best regards

Andreas

Lori, Brett,

Thanks for your explanation, I am seeing a bit clearer now... Brett - hopefully PeripheralAddress_ASM.h will not disapear without a replacement, since I am using these definitions quit a lot in my assembly

Best regards

Andreas

Thanks Guys

Best, Andreas