Bi-directional Parallel ports

[richardst9]

Posted on May 06, 2016 at 16:14

Short question: What is the recommended way to implement a bi-directional data bus on STM32 using the HAL?

Longer version: Our code needs to interface to a LCD controller over a 8-bit bi-directional bus. To do this, we need to rapidly reconfigure the GPIO pins between input and output. We clearly do not want to have to call Init functions repeatedly within transactions. In the good old days of the Standard Peripheral Libraries, it was okay to augment these family-specific libraries with functions that wrote directly to the registers and, in this way, provide a fast way to reconfigure the ports. But, in this new age of ''The HAL'', that is not appropriate, unless we either implement the function for all STM32 variants or go against the ethic of hardware abstraction. What is the recommended way to extend the Hardware Abstraction libraries to provide the essential functions that are missing? Thanks, Richard

[Tesla DeLorean]

Posted on May 06, 2016 at 16:48

Honestly ask yourself how many STM32 chips you expect to have to port this to.

The HAL still allows you to access the registers directly, and in many cases has macros that achieve just that. I'd just flip the mode from in to out directly, and put it in one spot so it is trivial to port if and when required.

[richardst9]

Posted on May 06, 2016 at 17:18

Thanks for the response.

>Honestly ask yourself how many STM32 chips you expect to have to port this to. Yes that is the point. Very few. >flip the mode from in to out directly Yes. In the past, we added functions to sit alongside the appropriate Standard Peripheral Libraries which performed the mode change directly to the registers. But my understanding of the philosophy of the HAL is that it is meant to be used to abstract the hardware and therefore it is inappropriate to write application code that is specific to any STM32 family. Otherwise, its not really a Hardware Abstraction Layer. In time, I would hope that the HAL will cover this and the other missing functions. But in the meantime, developers need to find ways to address the omissions. I assume others wanting to write portable code must have encountered similar issues.

[richardst9]

Posted on May 06, 2016 at 19:07

>In time, I would hope that the HAL will cover this and the other missing functions.

Unless I'm missing something, it seems that the HAL support is far worse than I initially thought. I cannot find any HAL support for writing to or reading from GPIO ports other than one bit at a time. That isn't much use to developers wanting to interface to multi-bit hardware in an efficient way. I struggle to understand why the developers of the HAL would not have provided these functions. Maybe I'm missing something. There are some powerful STM32 features (such as BSRR registers to help with setting groups of pins) but these do not seem to be available via the HAL. I certainly see the appeal to middleware writers of an interface that is common across all families (despite the fact that 8 years of codebase development based on the Standard Peripheral Libraries was rendered worthless). It just would have been so much better if the HAL was more complete. Maybe it will be one day - where would be the best place to post requests for the developers of the HAL? It's certainly better if they incorporate these functions into the HAL so that some of the powerful features of the STM32 are available to developers who want to write code that is portable across STM32 families.

[Tesla DeLorean]

Posted on May 06, 2016 at 19:48

The HAL adds a thick layer of

http://www.merriam-webster.com/dictionary/clag

to everything it touches, I'll keep the SPL and port that.

[richardst9]

Posted on May 06, 2016 at 20:23

I have to admit to a great deal of support for your view. Not just clag, but lack of important functionality.

This places developers in a difficult position. A massive amount of effort has been invested in a codebases that can be easily deployed to many different STM32 variants, but because these codebases are based on various SPLs, they are unlikely to be supported by ST resources longterm. If developers want to take advantage of the increasing amount of available Middleware, it seems likely that they are going to have to bite the bullet at some point and adopt the HAL libraries. [I'm yet to see any documentation on how best to migrate from SPL to HAL. I suspect that it would have been a lot easier if only ST could have built the HAL on the SPL rather than starting again from scratch, then much less valuable and proven work would have had to be discarded.] But the nature of the HAL (as discussed) is such that it is more difficult to augment than the SPLs. That would be ok if the HAL provided the necessary functionality. But its becoming increasingly clear that it doesn't. So even developers new to STM32 might find that the SPL are better to work with than the HAL even though ST seem to be pushing Cube strongly. I'm still interested to hear from developers who have chosen to migrate from SPL to HAL and how they addressed these issues. Or is everyone waiting until the HAL is in better shape before attempting this? [I'm learning to copy and paste to Notepad before pressing the OK  button. This web tool seems very flakey.]