Audio Visual STM32F429 Project

[Terence D]

Posted on September 09, 2017 at 01:57

Hi - I'm new to the STM development boards.  I've done A LOT with a TI TM4C123G (Tiva LaunchPad - ARM Cortex-M4F) which appears to be similar to the STM32F429 that I recently acquired.

I've just now (with not much effort) got the typical blinking light example working.  This is the STM32CubeF4 example under Projects/STM32F429I-Discovery/Examples/GPIO/GPIO_EXTI.  This example, as well as every other one I've looked at in the STM32CubeF4 Examples directory uses the STM32F4 HAL API (document of the HAL API

http://www.st.com/content/ccc/resource/technical/document/user_manual/2f/71/ba/b8/75/54/47/cf/DM00105879.pdf/files/DM00105879.pdf/jcr:content/translations/en.DM00105879.pdf

).  

In my first 'real' project I'm looking to use my STM32F429 to play some audio (through an I2S DAC I have) while also displaying some data on the LCD screen (possibly a histogram of the audio).  I'm assuming using the HAL API is the best approach here, correct?

Just want to make sure I'm going down the right path before diving in.  If anyone could confirm my assumption, I'd greatly appreciate it.  Thanks!

[T J]

Posted on September 09, 2017 at 03:34

Hi,

I am working with HAL on two different processor boards, '092  '767

there is some differences, but overall, once the boards are running, they seem very stable.

Hopefully Clive will chime in.

[T J]

Posted on September 09, 2017 at 06:45

Actually, end to end programing entails in-numerous platforms.

Pip Linux Angular, HTTP, UDP, Binary Coding ?, Server, Private and public keys, SSH algorithms, TCP/IP stack, Hardware faults Vs Software faults..etc. just to mention a few.

Then you can talk hardware and power supplies, LQFP is preferred, 7thou tracks are bulky but I think make for a much better circuit board, thermal relief, power spikes, RF noise.

What was the question ?  Hardware Abstraction Layer (HAL)

to use HAL drivers, offer you some limitations, but as you can see, it is becoming cross platform.

https://community.nxp.com/thread/380499

 

I expect that Clive would recommend the peripheral drivers.

your employer generally needs you to complete some part of the project.

you need to know all the platforms, to be sure of work.

[Terence D]

Posted on September 09, 2017 at 05:07

Nick - Thanks for the reply.  So it sounds like you're in favor of using HAL for typical development?  I ask because I just want to make sure I'm using more of a 'traditional path' with STM32 development and not something that is lesser known or frowned upon.

To frame the question another way: Say in the future, as a software engineer, I was interviewed by a potential employer to do STM32 work.  If my direct experience with the board entailed using the HAL API, might the potential employer see this as a positive or negative for any reason? 

[Terence D]

Posted on September 09, 2017 at 17:14

Thanks, Nick.  Good information.  Could you tell me where I might find documentation and info concerning these 'peripheral drivers' you speak of?

Also, I'm curious if people use ARM's CMSIS with the STM32 boards with any regularity? 

Additionally, one approach I initially did with the TI TM4C123G was to not use any API at all between my code and the hardware but instead directly manipulate processor/peripherals registers to make all the magic happen.

It helped me learn the board really well but it definitely increases development time and also hurts possibility for porting to other boards.  Guessing not many people use this approach with the STM32 for real projects?

[T J]

Posted on September 10, 2017 at 03:00

I am not an expert, I have been working on the same board set for over 12 months.  '091 CanBus  to the  '767 Ethernet to AWS  to  My HTTP server with Angular to your Browser.  it is very difficult.

I use the HAL initialization through CUBEMX.

I find the Cube very helpful.  I use UV5 and Visual Studio with Visual GDB.

If you carefully place your code in the right places, you can adjust your design/interrupts etc. inside the cube and overwrite your code set. It works quite well but sometimes you have to do a fiddle in the code.

So I don't think you can get truly processor independent code from Cube and HAL.

I use the Cube-HAL drivers for initialization then I just use inner the parts of HAL as I need. I guess I am working at the CMSIS level.

Did you look at MBED ?

the new MBED CLI or  MBED_OS5  is quite good, but very few have released a commercial product using it.

but MBED is quite good for being processor independent.

but not all processors are supported.

:(

Aside;

being processor independent in software is one step, but being processor in hardware, is that possible ?

Actually, with ST, most of the new series processors are pin for pin compatible, and the hardware peripherals are also aligned the same inside the processor.

eg. I made a PCB to suit the '417 , I checked it and the '767 has the same internal configurations and yes, it works on my PCB. I also checked the new processor coming, H753 @400 MHZ, it is also a drop in , pin for pin and internal peripheral pin matrix match.

I think that once the processor is available, it will be some significant time to get it going. but the board will stay the same.

it is difficult to generate a new CubeMX file for the new processor, you have to start with a blank state and set each pin again. it is not a simple process on my 208pin solution.

Either way it is work.

The reason that I wont use the best solution, being a Pi or Ti type high end solution, is the number of boards to finish the work.  I have one PCB with the power supply and Isolated CANBus transceiver and various LCD drivers / Ethernet / Pll Flash / QSPI flash/ SDCARD / 64MB SDRAM.

I dont use the '767 LCD system, it is too much overhead on the processor, that why it is limited to 800x600. My solution uses 2x RA8877 offering a native dual screen 18' 1366 x 768, without any CPU overhead. I can fit my PCB inside the LCD case.

[Terence D]

Posted on September 11, 2017 at 00:02

Wow, thanks, Nick - that's a lot of info.  Very cool that you're using Visual Studio with Visual GDB.  In my straight-up-software-engineering work I've been a Visual Studio user for decades and it's still by far my favorite IDE for C++ development.

Sounds like I should give Visual GDB another look as I've been bouncing from various IDE/compilers while learning embedded development and find that I routinely wish I could be using Visual Studio.

I've heard good things about MBED.  I've shied away from it so far because it just seems plain wrong to me that the IDE/compiler are in the cloud, but, as always, the times are a changin'  and I should probably give that another look as  well.

[T J · Accepted solution]

Posted on September 11, 2017 at 01:59

Just an update for you.

I had the Can-Bus running sweet on the '091 processor, for the last 6 months, without errors. ( 20KHz

:(

for 1KM range)

dropped the code onto the '767 board yesterday, only slight fiddling and it works.

So, Yes HAL is quite portable.

[T J]

Posted on September 11, 2017 at 01:18

I eventually got MBED to compile on UV5, painful, but it works.

Luckily is started with the STM32F0 series, and UV5 is free for that series.

My main work is not in MBED.

GDB only cost approx $140 only missing out on the Android tools.

[Terence D]

Posted on September 11, 2017 at 03:33

Super!  That is good to know.  Looks like I'll be progressing forward with the HAL.  Thanks again for all the info.