|
I wanted to turn on an LED on a STM32 devkit.
To do so I needed to turn some GPIO off and on.
It turns out, this isn't so straightforward.
I did not want to tie myself to a particular framework, so I decided to target the CMSIS headers which are available everywhere (I think?), even surprisingly under Arduino.
That means going to the hardware registers directly though.
Between being sidetracked by paying work and doing the research and code for this I've been at this all day.
I've got a class that almost lets me set the various properties of a GPIO pin and turn it off and on.
bool cmsis::gpio_pin_t::output() const {
const int shl = 1<<index;
uint32_t odr = READ_REG(gpio_ports[(size_t)port].reg_base->ODR);
return !!(odr & shl);
}
void cmsis::gpio_pin_t::output_type(pin_output_type_t value) {
const unsigned shl = 1<<index;
MODIFY_REG(gpio_ports[(size_t)port].reg_base->OTYPER, shl, (shl * uint32_t(value)));
}
pin_output_type_t cmsis::gpio_pin_t::output_type() const {
const int shl = 1<<index;
return (pin_output_type_t)(READ_BIT(gpio_ports[(size_t)port].reg_base->OTYPER, shl) >> POSITION_VAL(shl));
}
void cmsis::gpio_pin_t::speed(pin_speed value) {
const unsigned shl = 1<<index;
MODIFY_REG(gpio_ports[(size_t)port].reg_base->OSPEEDR, (GPIO_OSPEEDER_OSPEEDR0 << (POSITION_VAL(shl) * 2U)),
(uint32_t(value) << (POSITION_VAL(shl) * 2U)));
}
pin_speed_t cmsis::gpio_pin_t::speed() const {
const int shl = 1<<index;
return (pin_speed_t)(READ_BIT(gpio_ports[(size_t)port].reg_base->OSPEEDR,
(GPIO_OSPEEDER_OSPEEDR0 << (POSITION_VAL(shl) * 2U))) >> (POSITION_VAL(shl) * 2U));
}
gpio_port_t cmsis::gpio_ports[] = {
{(GPIO_TypeDef *)GPIOA_BASE},
{(GPIO_TypeDef *)GPIOB_BASE}
#if defined GPIOC_BASE
,{(GPIO_TypeDef *)GPIOC_BASE}
#endif
#if defined GPIOD_BASE
,{(GPIO_TypeDef *)GPIOD_BASE}
In arduino it's just stuff like
pinMode(pin,OUTPUT);
digitalWrite(pin,HIGH);
There's a whole mess of behind the scenes there. And I ran face first into it.
I'm several hundred lines of C++ in and I've got it almost working. Just need to enable the clock for the pin group even though I'm not entirely sure what that is, just how to do it. 
Here goes everything.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
I think Mr Boring ( Mike Hankey link ) covered how to do that
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Yeah. But I got this.
*cracks knuckles*
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
|
This reminds me of the old days of programming Borland C++, where I had to read the changes on the parallell port via the register. I do not miss it... 
|
|
|
|
|
Message Closed
modified 18-Jul-23 7:44am.
|
|
|
|
|
And I need some of what you are smoking to understand that ... 
On second thought, no, I don't. I'd rather remain with at least a dozen brain cells functional. So when you come down, ask again using actual English sentences.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I think he just got over-excited and desperately needed to tell someone. 
|
|
|
|
|
This smells vaguely of pink meat product. I'm wondering what's in the second message he posted in his private profile forum.
|
|
|
|
|
Eureka moment!
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
wrote: Dear immortals, I need some wow gold inspiration to create.
I know all of these words.
I just can't make sense of the order you put them in.
|
|
|
|
|
Just hit an interesting thought and would like veterans' perspective. I support a product that has over 20+ years of accumulated history. As I was writing some comments to explain why or what some code was doing, I've found that the #1 person who read my comments was me. Do comments even matter any more, or am I flattering myself?
Filed under hmmmm
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I comment for myself, because I know I'll be coming back and wondering why I did things the way I did.
Always good for a laugh. 
Give me coffee to change the things I can and wine for those I can not!
PartsBin an Electronics Part Organizer - An updated version available! JaxCoder.com
Latest Article: Simon Says, A Child's Game
|
|
|
|
|
 I agree. I do it for me first.
That controls the level detail so that I don't have to re-edit my comments constantly.
If someone else has to read it, it helps them too!
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
past maze3 and future maze3 conspire to sabotage me and give me more work
|
|
|
|
|
Decade+ old code and my beautiful friend and I still go through stuff we wrote back then and ask ourselves "What the ![Elephant | [mastadon]](https://www.codeproject.com/script/Forums/Images/elephant.gif) was I thinking?" That's not a slam on what the code was doing. I mean, it works perfectly fine, but how we did it back then compared to how either of us would do it today.
The comments help, but they can't save us from ourselves as we learn more and more.
|
|
|
|
|
Indeed. Sometimes the dawning of realisation can be a lot quicker. More than once I've written a comment (for my future self) and having spent an hour writing code, suddenly "hear myself" explaining it in the comment and think "That's a *&@$$@% stupid way to do this". Then I spend the next 5 minutes massively simplifying it to the point where it's so blindingly obvious that it doesn't need a comment at all.
Sometimes I just realise that a variable name seemed great when I first defined it, but after using it there's probably something better.
Commenting can be like pair code review - but with your future self instead of someone next to you.
|
|
|
|
|
I write very few comments, but I do when I feel an explanation of why one technique was chosen over another.
I also recall a situation in which I had some complex code which worked and I tried to simplify it -- and it didn't work. Some time later I had again tried to simplify it (in the same way) with the same result, and I kicked myself -- then I wrote a comment reminding myself what happens when I try that.
|
|
|
|
|
I rarely add comments anymore. Our shop demands self documenting code, as much as possible.
Every now and then I/we will add some comments for something obscure, or workflow/process related, etc. but that is rare these days.
|
|
|
|
|
We have code in our current product that was written in 2000, and the commenting has always been up to the individual. We do have a naming standard, but it's pretty relaxed (with the exception of Hungarian notation: use that, and we'll nuke your cubicle from orbit just to be sure). Our only commenting standard is for entries in our change history which are automatically extracted and collated into an HTML document by our automated build process.
My personal practice is based on something Dan Saks, former Secretary of the ISO C/C++ Standards Committee, once said: "If it can be said in code, say it in code. Otherwise say it in a comment." This means choosing expressive, meaningful names and organizing things in ways that reflect the process you're implementing. All of this is very squishy and more art than science.
All this is well and good until you throw someone new into the mix. We hired a new guy, a couple of years experience and very sharp. He had trouble with my code   , not so much reading any particular piece of it, but getting the big picture.
He's helping us transition from SourceSafe to git source control. In the same vein he's advocating for other changes to our process, including automated code documentation. He suggested doxygen, which looked great until we discovered the doxygen application was weak. Doxygen approaches the code base as if all of it belongs to a single executable. Our product is a Windows application and several services, along with several DLL's. We found DoxyPress[^], a fork of doxygen that seems to remove doxygen's limitations. We're treating the automated documentation as a roadmap, a guide to navigating the code base. We'll see how good a job we do.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: Hungarian notation: use that, and we'll nuke your cubicle
|
|
|
|
|
I like Hungarian notation. When you have a single Windows Form with several hundred components on it across many layers of tab sheets and panels, knowing if you are looking at a button, label, or textbox component by its name in the code really saves you time. I do this in my C# code too, which has a lot less components per form.
I view variable names as a cognitive map. Start with the big picture and then get more precise. So which component is it? Then which area does it live in? Then what does it do? txtLoanAmount is very clear what I'm dealing with. If I just saw LoanAmount, is it a label or a textbox or the value stored in memory to be used by the textbox? Let me see that tooltip - oh there goes a second or 2 waiting for it to pop.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
Yes; everthing has it's place. I name all my UI controls starting with "Ux..". I see some code where all their properties, variables, column names and controls are all names using lower case letters and expecting the compiler to sort it all out.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Gary R. Wheeler wrote: We found DoxyPress[^], a fork of doxygen
Thank you for the reference. On the face of it, seems to be what I've been looking for. I have a love-hate relationship with Doxygen: love that it generates the docs, hate how buggy and limited it is.
Mircea
|
|
|
|
|
Maybe I'm an outlier in this, but I have absolutely no tolerance for markup noise in comments, like Doxygen. They should read like properly written plain text, often in sentences. No one working on the code can be bothered to run it through some mofo tool to look at the results. It matters not whether they're looking at an interface or implementation. It's useful to have higher-level documents that provide an overview of the system, but those are not alongside the code and should be written in Markup, Word, or whatever.
|
|
|
|
|
I am perfectly in agreement with you.
Greg Utas wrote: I have absolutely no tolerance for markup noise in comments, like Doxygen
I have the impression that this is becoming more and more the standard practice - it may be a different system from Doxygen, but the principles are the same.
Let me extend it to lint comments. A few years ago, I cleaned up a code base that was soaked with lint comments to suppress specific lint warnings, yet a complete system build returned more that 23,000 lint errors and warnings. The developers were so used to seeing hundreds of them even for small unit compilations that they overlooked the warnings. Every now and then they made 'cleanups', which amounted to adding even more lint comments to reduce the number of warnings in the unit that was their responsibility.
I set out to define a lintfile that would globally suppress the warnings we defined as ignorable, and for the remaining ones, modify the code so lint kept quiet. (We also redefined a number of warnings as errors, failing the build.) The source code became a lot more readable with all those lint comments out of it!
I earlier worked with a company using/writing open source code: The coding rules required that a .c file contains a single function only. Common practice was to write very small functions, with bodies typically in the range of 5 to 20 lines. The problem was to see the code, you had to page down to the third screenful: Every file had to include an extensive copyleft / license statement. This caused the code base to have 80% comment lines.
I very much like the statement made by Gary R. Wheeler, above: "If it can be said in code, say it in code. Otherwise say it in a comment." Whether it is intended for a documentation system (such as Doxygen) or just because company standard requires it, I see lots of function header comments that copies the function name, argument list a comment, with type/class and all. In most cases, the 'explanation' is nothing more than expanding a quite self-documenting name to a sequence of words, like 'int numberOfApples -- integer number of apples'. Or a fuction named 'CalculateTheTotalBill' providing an explanation 'This function calculates the total bill'. If you don't have anyting to say, don't say it!
I would like to add to Wheeler's statement: "The primary purpose of the code is to show WHAT is done. The primary purpose of a comment is to explain WHY it is done."
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
