- This topic has 9 replies, 3 voices, and was last updated 3 years, 6 months ago by
.
-
Posts
-
So its nice that there is now an atmel start option for visualGDB however now if I try and make any new project based on a atmel based MCU it requires i import an atmel start file it seems. The biggest problem with this is that it only allows for 1 atmel start SDK at a time so attempting to import a new one leads to overwriting the old one. Also the config files are part of the SDK so even if I wanted to use the same atmel SDK every time I would likely need different configurations which prevents reuse of the SDK. Is there another way of doing this?
Hi,
No problem. Indeed VisualGDB normally supports only one imported Atmel START SDK per device family (multiple SDKs for different devices can be imported at the same time).
We can show you how to override this by manually editing/moving the definition files, however it looks like your support period has recently expired.Please renew it here and we will be happy to provide detailed instructions.
I decided to play around with the BSPs and modified the tools you have at https://github.com/sysprogs/BSPTools to generate one that doesn’t reference the config files but copies them over instead allowing one to overwrite them easily. The same with all of the start files that are changing between different chips. I had difficulty getting VisualGDB to recognize the changes if I made a new folder so I also had to modify the script to produce a proper vgdbxbsp file as the atmel start generator only produces the xml.
Thanks for sharing this. This is exactly the reason why we release the sources for our BSP-related tools.
I am evaluating VisualGDB and have run into the same problem described above. Being able to support multiple Atmel Start BSPs with the same processor seems like pretty basic functionality. I shouldn’t have to purchase the product before I can verify that I can use it to support multiple boards with the same processor.
Many companies settle on a small number of processors and use them in many different designs. The I/O, drivers,and middleware are configured differently for each product.
I have been impressed with VisualGDB so far, but I really can’t decide to purchase it unless I am sure that it has this required functionality. Why not make the workaround instructions that you referenced above public? Or at least give them to me so that I can finish my evaluation.
No problem, we do not mind sharing the instructions. We simply prioritize requests for documentation based on the amount of affected users (we have recently published a lot of new documentation on common topics). As you have seconded the topic, we are happy to provide more details.
Once you import an Atmel START SDK into VisualGDB, it creates a BSP.XML file in the SDK directory that contains the information extracted from the SDK. Then, the BSP is registered with VisualGDB by creating a %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\<id>.bsplink file pointing to the SDK directory.
The easiest way to support multiple imported SDKs would be to manually edit the BSP.XML file, changing the following elements:
- BoardSupportPackage/PackageID – change to unique names in order to avoid collision between multiple versions
- BoardSupportPackage/PackageDescription – set to any arbitrary string to help you distinguish the packages
- BoardSupportPackage/SupportedMCUs/MCU/UserFriendlyName – add an arbitrary suffix, such as ” (Basic)” or ” (Full)”. The suffix will be shown in VisualGDB GUI when selecting the device in the device list and won’t affect anything else.
Once you have changed the file, reopen the Tools->VisualGDB->Manage VisualGDB Packages window to trigger a reload of all packages. After that, you will be able to import another Atmel START SDK from another directory, and VisualGDB will keep both instances, since they will have different package IDs.
crj11
I pushed the changes I made to https://github.com/whinis/BSPTools as well as a MCUList csv that contains all the MCUs it should technically work with as well as my custom BSP.
This includes changes I needed to make to have it generate a “generic” BSP and I make no claims this is the best way of doing itHow it works is you make an AtmelStart package with as many libraries as you can and extract it to a folder
Move the BSP.XML from BSPTools/SDKImporters/AtmelStartSDKImporter into that directory
Build the AtmelStartSDKImporter and debug it with the directory of your AtmelStart as its command line argument
It will generate a vgdbxbsp that you can import as a package. I have made it such that you can then make any new atmelstart package and just copy over the Config directory into your new project for everything to work.To Sysprog I recommend you update your AtmelStartSDK importer to make a similar package because the biggest issue is 99% of the code and the library stays the same however a few files change for every project and your current package includes them as part of the library. I recommend you use my BSP as a starting point but not the ending point because its a bit hackish and I was fumbling my way through it.
PS. I would distribute the package but im not sure thats allowed.
@whinis, thanks for sharing this. The changes look good, however they would limit the scope of the importer to a handful of preselected devices, and may reduce compatibility with future updates on the Atmel START side, so we would currently keep the existing more generic implementation.
That said, please consider trying the new Embedded CMake Project Subsystem (available in VisualGDB 5.5 RC1). It supports converting individual frameworks into stand-alone frameworks (i.e. included with the project), and also provides convenient GUI for reassembling a stand-alone BSP and a number of stand-alone frameworks back into a shared BSP. This should simplify the handling of complex setups a shared core and a set of minor per-project customizations.
Thanks support, my current big issue with the current Atmel START framework is that it includes the config and driver_init files in the framework preventing its use in anything except the atmel start project it was created with. Furthermore if you change that atmel start project or try another one it overwrites the previous one invalidating that project. This is why I attempted to change what I did, under your current system your only choice is to import the project and then convert it to a standalone which seems to defeat the purpose of a framework in the first place.
No problem. Indeed, unlike other SDK generators, the Atmel START generator exports the entire project as a single atomic component, so VisualGDB follows its structure and does not allow the selection of individual sub-components.
That said, you can mark individual files from the Atmel START SDK with the “excluded from build” flag and then copy them to the project directory and include them into the project manually. This will allow referencing the existing SDK, while keeping project-specific customizations.
- You must be logged in to reply to this topic.