Skip to main content
Copy edited. Removed historical information (e.g. ref. <http://meta.stackexchange.com/a/230693>, <http://meta.stackexchange.com/a/127655>, and <http://meta.stackoverflow.com/q/266164>).
Source Link

VeryIt is very difficult for you NOT to use CMSIS thisthese days.

SPL is being discontinued for future development.

HAL / Cube is the future if you want to stay with ST's libraries.

You have other non-ST solutions, however.

Edit:

People often talk about how buggy the stST libraries are and my experience with those claims suggest they are more of a user problem than a code problem. At least with thee "very buggy"SPLbuggy" SPL. The known problem there is the i2cI²C code for some chips, most often unknown to many people, or known as a hardware problem.

Another example was in the unofficial release of SPL 3.5.

Most of user problemproblems with SPL haveehave been due to inability to understand how the code works and link theelinking the code to the hardware.

I used OEM libraries often and have found them to be generally of very high quality, certainly better than most code produced by "experts".

So I would suggest that you plunge into it and see if it works for you. Overhead is fairly minimumminimal. And if you structure your code right switching back to your own code from the library is easy.

Very difficult for you NOT to use CMSIS this days.

SPL is being discontinued for future development.

HAL / Cube is the future if you want to stay with ST's libraries.

You have other non-ST solutions, however.

Edit:

People often talk about how buggy the st libraries are and my experience with those claims suggest they are more of a user problem than a code problem. At least with thee "very buggy"SPL. The known problem there is the i2c code for some chips, most often unknown to many people, or known as a hardware problem.

Another example was in the unofficial release of SPL 3.5.

Most of user problem with SPL havee been due to inability to understand how the code works and link thee code to the hardware.

I used OEM libraries often and have found them to be generally of very high quality, certainly better than most code produced by "experts".

So I would suggest that you plunge into it and see if it works for you. Overhead is fairly minimum. And if you structure your code right switching back to your own code from the library is easy.

It is very difficult for you NOT to use CMSIS these days.

SPL is being discontinued for future development.

HAL / Cube is the future if you want to stay with ST's libraries.

You have other non-ST solutions, however.

People often talk about how buggy the ST libraries are and my experience with those claims suggest they are more of a user problem than a code problem. At least with thee "very buggy" SPL. The known problem there is the I²C code for some chips, most often unknown to many people, or known as a hardware problem.

Another example was in the unofficial release of SPL 3.5.

Most of user problems with SPL have been due to inability to understand how the code works and linking the code to the hardware.

I used OEM libraries often and have found them to be generally of very high quality, certainly better than most code produced by "experts".

So I would suggest that you plunge into it and see if it works for you. Overhead is fairly minimal. And if you structure your code right switching back to your own code from the library is easy.

added 858 characters in body
Source Link
dannyf
  • 4.4k
  • 1
  • 8
  • 9

Very difficult for you NOT to use CMSIS this days.

SPL is being discontinued for future development.

HAL / Cube is the future if you want to stay with ST's libraries.

You have other non-ST solutions, however.

Edit:

People often talk about how buggy the st libraries are and my experience with those claims suggest they are more of a user problem than a code problem. At least with thee "very buggy"SPL. The known problem there is the i2c code for some chips, most often unknown to many people, or known as a hardware problem.

Another example was in the unofficial release of SPL 3.5.

Most of user problem with SPL havee been due to inability to understand how the code works and link thee code to the hardware.

I used OEM libraries often and have found them to be generally of very high quality, certainly better than most code produced by "experts".

So I would suggest that you plunge into it and see if it works for you. Overhead is fairly minimum. And if you structure your code right switching back to your own code from the library is easy.

Very difficult for you NOT to use CMSIS this days.

SPL is being discontinued for future development.

HAL / Cube is the future if you want to stay with ST's libraries.

You have other non-ST solutions, however.

Very difficult for you NOT to use CMSIS this days.

SPL is being discontinued for future development.

HAL / Cube is the future if you want to stay with ST's libraries.

You have other non-ST solutions, however.

Edit:

People often talk about how buggy the st libraries are and my experience with those claims suggest they are more of a user problem than a code problem. At least with thee "very buggy"SPL. The known problem there is the i2c code for some chips, most often unknown to many people, or known as a hardware problem.

Another example was in the unofficial release of SPL 3.5.

Most of user problem with SPL havee been due to inability to understand how the code works and link thee code to the hardware.

I used OEM libraries often and have found them to be generally of very high quality, certainly better than most code produced by "experts".

So I would suggest that you plunge into it and see if it works for you. Overhead is fairly minimum. And if you structure your code right switching back to your own code from the library is easy.

Source Link
dannyf
  • 4.4k
  • 1
  • 8
  • 9

Very difficult for you NOT to use CMSIS this days.

SPL is being discontinued for future development.

HAL / Cube is the future if you want to stay with ST's libraries.

You have other non-ST solutions, however.