SPL reinstatement

[megahercas6]

Posted on July 23, 2015 at 15:49

Since it is hard to reach right people via email, and where are few people from STM software development group, i decided to write here.

How many people need to sign a petition for STM or something like that  to create SPL libraries for new STM32F7 and STM32L4 micro controllers ? STMCubeMx in theory should be a great tool, but with SPL many of us could make complex task work in mater of minutes, and right now at least for me, it is just unexplainable, how i can't do simple task, with no reasons why ( maybe it's new IAR ARM compiler at fault?) simply by changing order of TIM_Config() for simple PWM could mess up my EXTI config for completely different pin group, this is just crazy. Not to mention random crashes and so on. I spend this week trying to port F4 code, and so far, only led function is working. Also, by copying examples from stmbubef7 it does hang in assert_failed loop, while i know that i can get over 200MHz legally, same goes for many many functions. also, HAL uses Systic for delay function with no easy way out. but what if my program is so DSP loaded, that interrupt at wrong place could make my program glitchy ? ( i am running DCMI with camera at  56Mhz + using DMA to stream data to computer at 10Mbps + running PID loops on processor itself. i can't get systic interrupts, because processor will be overloaded and miss lines of images, and stuff like that. So the question is, how many people should ask for STM to produce SPl libraries for F7 series ? Because at this point, i was using only STM32 parts for mid to high complexity projects, but due to HAl libraries, i am thinking to switch to other parts, and i read same thing from others. I i can't make simple program work in a week, while with STM32F4 could do same think in few hours, you know what i am thinking... #liquefaction

[Chris1]

Posted on July 23, 2015 at 16:53 Having SPL supporting the STM32L4 devices would be very useful for my team. We are working on porting a large project from an F103 to L4, adapting from SPL to Cube HAL is a difficult and frustrating task.  And the complexity as well as the added overhead of the HAL functions is a significant concern.

[Tesla DeLorean]

Posted on July 23, 2015 at 17:06

Since it is hard to reach right people via email, and where are few people from STM software development group, i decided to write here.

Honestly I've pushed this pretty deep into the STM32/SW groups. It's going to have to collapse under it's own weight at this point, and enough big customers decamping to something else, or holding their feet to the fire.

[John F.]

Posted on July 24, 2015 at 08:55

''customers decamping to something else''

Do you have any suggestions what ''something else'' might be please? I've worked my way from STM32F1 to F4 series using the Standard Peripheral Library. clive1's SPL based code examples in this forum have been a model of clarity and precision - thankyou. HAL seems to be a model of something else entirely.

[Tesla DeLorean]

Posted on July 24, 2015 at 10:25

I'm afforded a lot of leeway here, but I think that's something I'd prefer to discuss off-board.

In the general sense, my point is that with the SPL you have a somewhat captive market, I've used ST's libraries since the STR7/9 days, and a lot of other devices for that matter, if you introduce a change that requires a total refactoring of the code base, and management has to buy into that kind of resource expenditure, the choice of chip becomes a lot more fluid. 

[John F.]

Posted on July 24, 2015 at 10:52

OK - thanks. I've considered other manufacturer's parts but the range and mix of peripherals on the STM32F parts still attracts me. HAL doesn't. I was concerned that the Keil MDK STM32F4xx_DFP now seems to include an STM32F4xx_HAL_Driver folder making it look like HAL contaminates the Keil middleware. I'm confused by that.

Love the tag - ''liquifaction'' ... hilarious!

[megahercas6]

Posted on July 24, 2015 at 12:08

''clive1's SPL based code examples in this forum have been a model of clarity and precision - thankyou. HAL seems to be a model of something else entirely.''

I am also been using Clive examples for various applications, but all my ''code snippets'' will not work right now ( yes, it will need to be adjusted for F7 if any) It can't hurt !

http://email.ipetitions.com/wf/click?upn=HQSeJf071GT50ThirMdIvFx87cjjZmNRVwY4kfMr8ztlwAxWIkEHbzl4056TTX4-2FY5FOXcMQyGimOHuiRQMX-2Fw-3D-3D_KAmdgcuKv9Dp8Z6FLTOQvNiOliw8OYA2XKX5QTbIjRocUKWENtLvRP3SPmjuf-2FY-2FKYzc2owJiaqH0mfQLNh4mjEQYdPwzF7dhLxTidcQ-2Bcoq6KmQG263AkbMR9i0iwhxykI1yUstLMezopy70V7X-2FB9g7b...

[briancavanagh91]

Posted on November 04, 2015 at 17:30

I like the fact that SPL and HAL are both written in C.

SPL code is a bit easier to modify, and is less clumsy than the HAL code.But I would rather use mbed libraries any day, assuming a good implementation could be written.

[jpeacock]

Posted on November 04, 2015 at 19:22

''If you can't get through a problem then go around it,'' a lesson from my grandfather, a bootlegger (someone who manufactures and sells hard liquor illegally) who often had to find innovative ways to ''go around'' problems with laws.

The best SPL solution may be to simply go around ST and produce new SPL libraries as community open source projects.  The F4 SPL makes a good starting point.   Jack Peacock

[John F.]

Posted on November 05, 2015 at 09:59

Hi Jack,

I raised this earlier in the thread but would like your opinion. Keil supply middleware. For example to support an SD Card with FAT file system ...

but

  if I use the latest Keil uVision 5.17 I can't get that without also getting a whole heap of HAL thrown in that I just don't want. In uVision 4 I could add SD card support without needing to use their RTOS and without any overhead and without HAL trying to fix things up behind my back. How do I work around that - while maintaining the option of keeping the IDE and compiler etc. up to date? Is there any ''clean'' middleware with drivers that just lets me set up the IO and then gets on with it?