Arduino anyone?

[daleyd]

No! Encapsulate code in well named functions and classes (a bit more advanced for arduino stuff).
Good code should not have any comments.

I have to write stuff that’s used by other users, maintenance techs, people who have to use it to debug faults that aren’t software engineers and might only have a very basic knowledge of the software - if I did this then they wouldn’t come back and use our services again.

What you say may be relevant in a software environment where everyone is an “expert”, but certainly not applicable in many cases. And I’d say not in something like an arduino where people are getting to grips with coding maybe for the very first time.

 

[Kram]

I have to write stuff that’s used by other users, maintenance techs, people who have to use it to debug faults that aren’t software engineers and might only have a very basic knowledge of the software - if I did this then they wouldn’t come back and use our services again.

What you say may be relevant in a software environment where everyone is an “expert”, but certainly not applicable in many cases. And I’d say not in something like an arduino where people are getting to grips with coding maybe for the very first time.

Disagree there. Functions and naming are always better. I'd agree if we were talking about interfacing, classes, IOC and dependancy injection..
As a mimimum anyone interested in code should use a decent IDE that allows jumping into a function. The arduino one was garbage if I remember correctly.

It would really help beginners to avoid god functions that try to do far too much with bad comments that rarely get updated.

 

[Chippie]

What @ajlelectronics has said, plus:

Do you know how bad the contact bounce is for the up / down set buttons you're using? 100 ms delay at the end of each loop should be more than adequate, but it would be good to confirm it with a scope. Do you have one?

If I've understood it right, all the phantom button presses occur when the set point crosses the actual temperature, which (presumably) causes the relay to switch? The switching noise from that could well be coupling into the button wiring. Does it still do it if you disconnect the heater?

I'll come clean,

not using a switch at the moment didnt have any to mount on my breadboard...so using a flying lead to pull down the relevant input pins...

yes interested in debouncing plz.

 

[Red'n'Black]

No! Encapsulate code in well named functions and classes (a bit more advanced for arduino stuff).
Good code should not have any comments.

Beg to differ. If you're talking about this type of boilerplate stuff

InitialiseDoohickey(); // Initialise the doohickey

then yes that's fairly pointless. But with embedded code you're often trying to control some temperamental IC with various undocumented bugs and putting something like this

a = ReadDataFromBastardChip();
a = ReadDataFromBastardChip(); // Discard first read after reset, contains garbage

will save some poor sod from having to re-invent the wheel later down the line.

 

[Tinbasherdan]

I have had good success from chat gpt, if you are specific with what you want it to do it’s generally close, you do have to go through a few iterations but it does fix problems pretty easy

 

[ajlelectronics]

a = ReadDataFromBastardChip(); // Discard first read after reset, contains garbage

will save some poor sod from having to re-invent the wheel later down the line.

Absolutely.

 

[Kram]

If I want to know how a function functions, I should read it.

int ReadDataFromBastardChip(){
If (IsFirstReadAfterChipReset() )
DiscardGarbage()
Return ReadChip()
}

 

[MetalMonkey]

yes interested in debouncing plz.

When a switch closes, because of the springy nature of the contacts and the latching mechanism the contacts can often make and break (i.e. bounce) several times very very quickly (in a fraction of a second).
This isn't a problem most of the time because it happens so quickly it makes no practical difference - but when you are using switches as inputs to a microcontroller (as in this case) which reads those changes very quickly, it effectively appears to the processor as if the button is being pressed multiple times in quick succession and it will dutifully increase or decrease whatever you have told it to multiple times as a result.

Hence why the delay is suggested so it only reads the change of input state once after everything has settled down. Obviously you can't have too long of a delay otherwise it will interfere with the somebody pressing the button.

No! Encapsulate code in well named functions and classes (a bit more advanced for arduino stuff).
Good code should not have any comments.

I kinda half agree and half disagree to be fair - yes in a perfect world with nice clean code the comments don't add anything other than clutter, especially if they are essentially duplicating the code e.g. void initialise() // Initialises
However, when code gets umm, "organic" , especially when maintained by different teams/companies and people without necessarily a programming background - comments can add a lot of benefit and save a lot of time when troubleshooting.
Providing more information about what the function does or some key point, especially when scripting where various other system processes might be linked to it in less than obvious ways can help a lot with maintenance and doesn't really detract from the readability.
For those who are not experienced or hobbyists, comments can also help if you come back to something after a few years to help you understand what you did and why.

 

[Red'n'Black]

If I want to know how a function functions, I should read it.

int ReadDataFromBastardChip(){
If (IsFirstReadAfterChipReset() )
DiscardGarbage()
Return ReadChip()
}

Yes I see that style a lot from the sw guys at work, let's just say it's a long way outside my comfort zone. Ditto object-oriented, I've tried and failed several times to get my head around that stuff.

 

[sako243]

Good code should not have any comments.

Sorry but that is completely ridiculous. Why have them if they're not needed?

Good comments should explain why something is being done not how it is being done (that's what the code explains).

 

[sako243]

If the setpoint is 10, winding it up the reading goes straight to 22, then 23-24-25 etc....if I leave it at say 27 and wind it back down it goes 27-26 to 22 then jumps to 10....

The code above only checks that the button state is down. Your loop is checking this every 100ms so if you hold the button down then chances are you'll be going up or down at a rate of 10 per second.

Loop 1 then button is up, nothing happens, loop 2 then button is down so decrement set point, loop 3 (100ms later) button is down still so counts down again.

Either you need to slow down the reading of the button or you should be looking for edges (I.e. Was the last state of the button high, now it's low therefore we have pressed it). If it was low and then low again next time around the loop then you're holding the button down.

I can provide more robust code if you wish but not going to type it on my phone.

 

[bump]

No! Encapsulate code in well named functions and classes (a bit more advanced for arduino stuff).
Good code should not have any comments.

Massive disagreement here, and you are using code I've written if you are a UK citizen.

Ideally it shouldn't need any, however understanding the intent can be incredibly important when you can't reference back to pull requests and test data.

 

[Kram]

Massive disagreement here, and you are using code I've written if you are a UK citizen.

Oh I hope not! Given the state of national IT failures you might want to keep that quiet

 

[bump]

Oh I hope not! Given the state of national IT failures you might want to keep that quiet

I didn't work for any of the usual scumbags in the picture. I was with the Martha Lane-Fox solution to that.

 

[m_c]

I used to be really bad for not commenting code, but I have improved.

Naming functions well removes a lot of need for commenting as the name should tell you what it does, but I'm trying to make a point of adding comments to describe what any functions actually do internally and if there is any particular reason why it does something in a certain way.
That way if I revisit it in x months/years time, I don't have to spend as much time trying to remember/relearn how it actually works, or why it does something in a certain way.

 

[Misterg]

If (IsFirstReadAfterChipReset() )
DiscardGarbage()

But WHY?

I suspect we will have to agree to disagree on this.

 

[northwest]

Martha Lane-Fox

A fascinating woman and someone worthy of her place in the House of Lords.

 

[sako243]

@Chippie you should also add some physical debouncing to the circuit. Given its just a button press a 100nF capacitor to ground on the input pin would suffice. If you do this then I doubt you'd need to do any software debouncing at all.

The problem with having no physical debouncing is that if you decided in the future to change the button presses to be handled in interrupts then you may end in a situation where the processor locks up because all it's time is taken in servicing the interrupt. Software implementation should not be a replacement for good physical design. Software debouncing usually came about because the hardware was fixed and could not be changed in deployment and I feel that people now use it as a replacement when it's not. Electronic debouncing can do much more than prevent spurious events (such as protecting the input pin).

 

[Chippie]

Hmmm…what happened here?

@Chippie you should also add some physical debouncing to the circuit. Given its just a button press a 100nF capacitor to ground on the input pin would suffice. If you do this then I doubt you'd need to do any software debouncing at all.

Agreed, not sure what the value of the internal pull ups is, but I guess if I add an RC filter on the input of 10k and 100n, that should suffice? And disable The int pull ups?

 

[sako243]

It's usually better to have external pulls on outputs because the behaviour of the pins on the micro may be undefined at boot. Inputs it doesn't matter as much because you're only going to worry about them after you've initialised all the peripherals.

RC filter will introduce a series R but that will also limit current into the pin. 10k is far too high for a series R, a hundred ohms or less will suffice to limit current to protect the pin. You don't necessarily need to disable the internal pull ups but they're kind of redundancy / superfluous if you have external ones.