I suppose it all comes down to what kind of fun you want to have. It's been fun working out the dets of the analog approach on the other thread, but I've had almost enough of that kind of fun.
I started in analog, digital quickly eclipsed that, but I still see a lot of digital i/o "wasted" for things that resolve easily with an ai. It's all about the way we're "wired", I guess.
Yep, you'll see these types of assumptions throughout the examples and libraries, too; I get the language purity thing, I really do, but... I won't stick around here if we have to explain that level of brokenness to every new poster. When "true" becomes "zero", we're done.
I dont suppose there's a similar 'compact' approach for my remaining I/O pins, which use A0 to A3? Obviously 'Ax' or 'A(x)' doesn't work, but...?
My existing code below:
// Code to choose sound file; first 8 of 12
for (int i = 2; i <= 9; i++)
{
if (!digitalRead(i))
{
file = i - 1;
break;
}
}
// For the remaining 4 pins
if (!digitalRead(A0))
{
file = 9;
}
if (!digitalRead(A1))
{
file = 10;
}
if (!digitalRead(A2))
{
file = 11;
}
if (!digitalRead(A3))
{
file = 12;
}
Serial.print("file = ");
Serial.println(file);
Even if I hadn't already used the rotary switch approach and had seen your 4 pin alternative I don't think I'd have chosen it. I'm motivated mainly by seeing the project finished, but also because I don't envisage using more pins.
Yep, it's always nice to have a few left, and I'm down to just A4. But if the need did arise I reckon I'd first explore the "Toggle.h" library (from David Lloyd) that I used in my JukeBox project. That would let me choose multiple options from a single button on A4.
But I did briefly consider a 1 pin approach using a pot. I'd already chosen that method for another section, setting play duration of the chosen file. ('Duration' in the photo I posted up-thread.) So, for the File section, variety was a factor, as well as simplicity and using my existing (ancient) components.
BTW, straying OT, the Duration code is working, but I suspect a dirty track at the lower end of its 4K7 range. Successive readings at the same knob position vary more than I'd like, e.g the last few were: 8, 10, 49, 26, 43, 71. In practice this won't be an issue, as I expect to be setting it to at least 5 mins of its roughly 1 hour max, implying a reading of around 1023 x 5/60 = 85. But still...
Quibble. Hardcoding 12 is silly, when you can sizeof(inputPins[])/sizeof(inputPins[0]). It is foolproof. I used to make the assumption that I'd always remember to change the indexing length if I added/removed a pin. Until I didn't.
It's a 12W switch with 12 wires soldered to its 12 contacts going to 12 UNO pins and will play one of 12 MP3 files. The actual files might be changed on the micro SD, but nothing else.
The circuit will be transferred from the UNO to veroboard in a finished case and powered by batteries.
So I'm reasonably confident of that particular code's permanence
I'm sure. Not doubting you. However, the technique is valid, and knowing it exists and can keep you out of trouble has value beyond this application. However, I sense our fundamental approaches differ so markedly that I am wasting your time, and I shall move on.