Hello,
This might be a silly question, but how does one go about creating a BSP (Board Support Package)?
I searched through the Documenation (https://dspconcepts.com/support) and there doesn't seem to be any specific references to BSP files. I know there are code examples in the downloads section (https://dspconcepts.com/downloads), but I'm interested in a good definition, format description, and capabilities. A wiki style documentation might help so we can all fill in the blanks.
My specific question is how to write a BSP for the NUCLEO-F767ZI along with some other development boards (ADC, DAC Evaluation Boards). I know there is no specific BSP written for this board (see https://dspconcepts.com/forums/audio-weaver-general/89-faq-which-develop...). But I would assume that because the Nucleo doesn't have any peripherals to connect to. So we will need to define the connected ICs.
So then where should someone start? I know that the download for the STM32F746 Discovery (Cortex M7) BSP includes: BSP reference source code, pre-built boot-image for board, ST AWE Core libraries, build projects for Keil, IAR, and GCC toolchains. So is this just C++ code and where does it run on the stack? Bare Metal? The reason for me asking is so I know where to start when hiring a developer to write this code for me so I can start using the tool with my intended hardware.
I hope writing a BSP for a NUCLEO-F767ZI is straight forward! This tool looks promising for my project. Thanks for your help.
Jay
9:48am
There is a sample BSP for the STM32F746 Discovery board which would be a good starting reference. All code is written in C and is "bare-metal".
12:09pm
Hi Chris, thanks for the info. I kinda concluded that after some additional research.
I have two other questions pertaining to my project...
Can a developer use the aw core without running audio weaver on a computer? Ie once programmed, can the device run stand alone? Can the stand alone device be controlled by another application via USB other than aw? Is there an SDK for that? Documentation? Does aw allow stand alone USB Audio outside of AW?
Im trying to find out how much is involved once the concept is proven using the dev tools to make it a finished working product.
Thanks.
Jay
12:50pm
The short answer is yes to all your questions about running standalone. As for the SDK and documentation another member of the team should post a reply for you on that since I do not presently have that information at hand.
2:03pm
Hi JayShoe,
As Chris mentioned, the short answer to all your questions is yes. To understand the AWE Core and how to integrate it into your hardware, please see our how-to-write-a-BSP documentation 'AWE Core - Integration Guide', available at www.dspconcepts.com/support. This document describes the theory of operation of the AWE Core, as well as details of how to set up your hardware to run stand-alone and receive control commands through other interfaces.
This integration guide and our ST Discover Board reference BSPs (www.dspconcepts.com/downloads) should provide a good launching point for you.
Good luck
-Axel
10:15am
Hello,
Thank you for your information. It has been very helpful.
On the https://dspconcepts.com/st page, there is a graphic showing the feature set of Audio Weaver ST edition.
I notice "Attach to running targets" is a feature that is NOT selected in the ST version. There is no link that further defines what is meant by this.
Does this mean that I need to purchase the STANDARD edition in order to run in Standalone mode?
Thanks for your help.
Jay
1:05pm
Hi Jay,
The 'Attach to running targets' feature is a feature used for tuning a layout running on a stand-alone target.
You can run stand-alone using the ST edition of Designer and the provided stm32fxxx BSPs.
Good luck!
-Axel
9:13am
This question was asked here:
https://dspconcepts.com/forums/audio-weaver-designer/215-can-i-still-tun...
This post has provided some clarity for my project. Since we don't want the Audio Weaver Designer running on the PC, our device will be running in stand alone mode. And therefore we will need a license for sure in order to "tune the running target" (aka change volumes).
9:22am
Just to be clear, the "Tuning" interface is distinct from the "Control" interface. The "Theory of Operation" section of the AWE Core Integration Guide explains this fairly concisely. In short, HMI elements (volume knobs, mute buttons, LED indicators, etc) interact with the active Layout using one API, while the communications link from Designer "plugs in to" a different API.
The "Attach to Running Target" feature is most often used to 'debug' a Layout that's been loaded in a stand-alone target.
5:16pm
Matt,
Excellent! Your advice has allowed me to reach a checkpoint!!! "Tuning" is not the same as "Control"! I now re-read the AWE Integration Guide from top to bottom and I fully understand. Yes, we can start this project with the "ST Edition"! All essential features will be possible and we can release an upgraded version at a later date (with a purchased license).
Possible Target MCUs by Development Board:
So the Nucleo-F767ZI might not be the best pick due to the fact that it's different than the existing BSP. The developer is right, it's a smart idea to keep close to existing BSP hardware as possible. Therefore, I think we'll prototype on the Nucleo-F746ZG instead.
Question 1: Is the Nucleo-F746ZG a good starting point?
He wanted me to ask you this. Do you believe that the Nucleo-F746ZG is capable of running Audio Weaver? Does it have all the specs you require to run the application? Do you think there any benefits to the Nucleo-F767ZI (216 Mhz vs 200 Mhz, 512 SRAM vs 320 SRAM) and if we were to upgrade would it be much more complicated than just using the Nucleo-F746ZG?
Question 2: Is the STM32 Workbench a good IDE for this project?
The sample BSP only mentions Keil, IAR, and GCC but not System Workbench for STM32. But inside of the Build files there is a reference to the STM32 Workbench. Is the FREE System Workbench for STM32 all we need to get up and running with this? Or do we need Keil, IAR, or GCC?
Thanks again!
Jay
5:52pm
Hey guys, sorry about all of my posts and questions. We are excited to try and use Audio Weaver in our projects but we are struggling to find a clear path to prototyping. What we are realizing is that integrating AWE into our product is much more complicated than most realize (or is it?).
I'm not sure if you are interested in marketing to the "MAKER" market - for if you are not then that's why I'm struggling so much. But if you are interested in having users toy with Audio Weaver in custom, small scale, DIY style products then it seems like you might want to provide a few more tools (and possibly licensing models).
It has come to a point where we realize that out of all the BSP's listed, none of them will help us build our project from it without first porting the BSP to the Nucleo. The Discovery boards don't have the I/O to connect an external codec of our choice (unless I missed something - I could not find external I2S or SAI pins) - so while it serves as a good testing module for the product, it doesn't seem to serve as a "starting point" until it's first ported to the Nucleo.
I'm not a coder - but I'm in tight communication with a few developers and nobody seems to believe that porting the BSP from the Discovery to the Nucleo is going to be either easy or 100% possible. So before we can start to develop our custom application, we need to first proove that we can port to the Nucelo.
I thought of maybe using the PI integrations you are going to release soon. But neither of the PI's have USB OTG functionality. Therefore we can not run them as a device connected to a host. Our particular project requires both USB Audio and USB HID from the host. By the way the PI ZERO does have a USB OTG slave mode so that would also be a possibility for us if you were to explore that model. ( I also want to point out that I'm not sure what your licensing model will be for the PI users...)
I suppose I am reaching out to find out whether or not I can put in a request for DSP Concepts to write a BSP for the Nucleo directly. Of course the Nucleo doesn't have any interesting codecs to run the audio through. But it does have a 12 bit digital to analog converter that can be used as a simple proof of concept. By doing this, we then have an actual starting point for my project (me and other "makers"). We would then have the base model to build our custom external codecs on top of - without having to worry about the underlying core code (for the most part). If we had a Nucleo BSP - we would focus on writing the initialization code for our external ADC and DAC parts (connected "maker style") and focus on the actual AWE->Codec integration. Whereas at this point we are fearful of the actual port itself.
The other question I have is whether the Audio Weaver product is planned for integration into CubeMX. This would also be a much faster launching point for people trying to integrate AWE into a custom project.
Much respect for you guys - you've really got me dreaming. I appreciate your time. Thanks.
Jay
6:45am
We support GCC through System Workbench STM32. Our board support packages for the ST Discovery line include a Build folder with the SW4STM32 files .cproject and .project. To use these files you create a new workspace and import this folder as an existing project.
Audio Weaver is designed in a modular fashion. The intent is to have generic AWE processing blocks that you integrate into your specific target platform. Our sample BSPs for the ST Discovery line leverage sample code provided by ST to setup pins, communication protocols, CODECs, etc. You are expected to setup all this peripheral hardware and then integrate AWE to perform the signal processing. Once you have these various pieces of firmware working you will generally need to modify Platform.c and AudioDriver.c. Platform.c will need to be updated to acquire your platforms cycle count and to interface with the specific tuning communication on your target. AudioDriver needs to interface to the CODEC DMA interrupt complete handlers and also be modified to work with different number of channels and DMA block size. You might use CubeMX to create the initial firmware. Then create your CODEC setup code and create DMA complete interrupt handlers. Once all this is working add the AudioWeaver C files to your project and modify Platform.c and AudioDriver.c and you should be good to go.
11:17am
I know this is an older post, but thought I would jump in here. From Chris's post, you might think that porting an existing BSP to another board was trivial. I have started the process for the STM32723E-DISCO and from what I can tell it is not straight-forward. The changes that you make to Platform.c and AudioDriver.c will propagate considerably lower on the stack. It might be nice to have an example of a port to another STM32 board. The integrators guide seems to be considerably higher level than those interested in porting the existing BSP. Or maybe I am missing something?