Author Topic: BSRR in STM32F4xx.h  (Read 3059 times)

0 Members and 1 Guest are viewing this topic.

Offline MT

  • Super Contributor
  • ***
  • Posts: 1290
  • Country: cn
Re: BSRR in STM32F4xx.h
« Reply #25 on: April 10, 2019, 02:08:54 am »
Because you are arrogant as well? :P
French are arrogant, just look at the baguette! By birth they think philosophy is their invention! :P
« Last Edit: April 11, 2019, 12:57:44 am by MT »
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3307
  • Country: us
Re: BSRR in STM32F4xx.h
« Reply #26 on: April 10, 2019, 02:13:54 am »
Quote
Why shall i be punished to spend hours on debug ST arrogant crap?
  • Because it's the sort of Crap that once you figure it out, isn't that bad.
  • Because other vendors aren't much better (Atmel's SAMD has the PORT and PORTGROUP backwards, and is woefully inconsistent when it come to which peripherals are "arrays" of a stucture (PORT), and which are individually defined but numbers (Timers, Sercom...)
  • Because it's the hardware features that matter.
  • Because they're what you boss told you you were using.
 
The following users thanked this post: Siwastaja, newbrain

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 3039
  • Country: fi
Re: BSRR in STM32F4xx.h
« Reply #27 on: April 10, 2019, 11:50:54 am »
Exactly. To get work done, you sometimes need to drop pedantism (or arrogance, whatever, but that's an... arrogant choice of words), be practical, and choose the most suitable solution, despite the flaws. STM32 tends to offer a large portfolio of MCUs with a flexible set of HW peripherals at a good price.

As you work with them, the difficult annoying things get easier and easier to deal with. This is called experience.

I sometimes fix header files if they are clearly wrong; I think it's practically better. Because the header versions are incompatible anyway, if you want to have a robust project, you can't just let others open the code with whatever library versions they might have; the easiest way around is to make copies of the headers and include them in your project - in which case it isn't a problem to treat them like you do with any code: this is, fix errors, to make the application code easier to write and read.

IIRC these header files don't contain proper formal #defined revision numbers anyway, so you can't automatically enforce compatibility.

Don't worry, the headers between families, products and versions are all inconsistent, no one knows "by heart" how they work, so you are not going to make anyone's life harder by fixing things inside your project; only easier.

It's still quicker to use the headers, even if you had to modify a few #defines, instead of doing your own from scratch.
« Last Edit: April 10, 2019, 11:53:37 am by Siwastaja »
 

Offline MT

  • Super Contributor
  • ***
  • Posts: 1290
  • Country: cn
Re: BSRR in STM32F4xx.h
« Reply #28 on: April 10, 2019, 11:55:53 pm »
Because it's the sort of Crap that once you figure it out, isn't that bad.
The user of the device are not supposed to have to figure it out because the crap should not exist to begin with.
Quote
Because other vendors aren't much better
Most likely, but thats not an valid excuse, just sloppy work from vendor.
Quote
(Atmel's SAMD has the PORT and PORTGROUP backwards, and is woefully inconsistent when it come to which
peripherals are "arrays" of a stucture (PORT), and which are individually defined but numbers (Timers, Sercom...)
There you go, welcome to sloppy vendor craftsmanship.
Quote
Because it's the hardware features that matter.
Dont seam to for lots of people, they gladly take a simpler device if it suits the project.
Quote
Because they're what you boss told you you were using.
The bosses i have had often had no clue at all what to use for a particular project.

Strange that you excuses deliberate implementation of CRAP in documents and files! But mileage varies i suppose.
 :-//

Exactly. To get work done,
Since your post is directed to me via westfw post , thats what i describe, got the work done.
Quote
you sometimes need to drop pedantism (or arrogance, whatever, but that's an... arrogant choice of words),
Ok, yet previously you spent a whole page on describing your pedantry and arrogance over ST documentations e.g illogical mess! :palm:
Thats kinda portraying your self as hypocrite! But then please chose whatever device that suits your project , the docs and files are all crap anyway according to westfw so why then all the pedantic windbaging Siwastaja?

Quote
be practical, and choose the most suitable solution, despite the flaws. STM32 tends to offer a large portfolio of  MCUs with a flexible set of HW peripherals at a good price.
You'r hilarious, why all this chose this chose nonsense got to do with faulty written files from vendors? besides being quite dumb in context to what i said in my first post.

Since when is fixing a SVD file so that peripheral start working as barely described in device datasheet it should become
pedantry and arrogance as you say it is?

Quote
As you work with them, the difficult annoying things get easier and easier to deal with. This is called experience.

Yet again, you previously wrote a full page complaining about ST docs , not much of experience collecting there rather constant pedantic windbaging over nothing as per your say.
Quote
I sometimes fix header files if they are clearly wrong; I think it's practically better. Because the header versions are incompatible anyway, if you want to have a robust project, you can't just let others open the code with whatever library versions they might have; the easiest way around is to make copies of the headers and include them in your project - in which case it isn't a problem to treat them like you do with any code: this is, fix errors, to make the application code easier to write and read.

Im not even debating that, irrelevant to whats i said, but anyway again ,when you fix faulty written vendor files its labeled fixing and collecting experience when i and other do the same thing its labeled pedantry and arrogance. Thats nice of you!

Quote
IIRC these header files don't contain proper formal #defined revision numbers anyway, so you can't automatically enforce compatibility.
Noone asked nor mentioned it yet you still use vendors def files for sure not writing them all by your self clearly. So which rev of a SVD, def, etc file do you use for your next project? Rev1 yet Rev4 with later date is there, both contains faults but on different positions. Thats quality of vendor craftsmanship you call i presume?

Quote
Don't worry, the headers between families, products and versions are all inconsistent, no one knows "by heart" how they work, so you are not going to make anyone's life harder by fixing things inside your project; only easier.
It's still quicker to use the headers, even if you had to modify a few #defines, instead of doing your own from scratch.

Thats some uber heavy excuse lifting for the device maker your doing there , so by your way of reasoning device manufacturers shouldn't bother write any define, startup, register definition etc files at all, just dump it on device user, i.e why bother , so then why do they bother writing faulty files then? For fun to waste users dev times?

« Last Edit: April 11, 2019, 01:16:30 am by MT »
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3307
  • Country: us
Re: BSRR in STM32F4xx.h
« Reply #29 on: April 11, 2019, 01:29:18 am »
Quote
Because...
Oops, I left out one:
  • Because that why you get paid the big bucks...
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 3039
  • Country: fi
Re: BSRR in STM32F4xx.h
« Reply #30 on: April 11, 2019, 07:37:27 am »
Ok, yet previously you spent a whole page on describing your pedantry and arrogance over ST documentations e.g illogical mess! :palm:
Thats kinda portraying your self as hypocrite!

I don't feel that describing a problem, then deciding to balance between living with it, or proposing solutions (such as fixing the damn thing) is hypocrisy; quite the opposite. It's good to understand what you are dealing with.

Otherwise than that, I have very hard time trying to understand your post, so let's leave it at that.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf