totm nov 2023 Thread to discuss negative things in a very general way, just see where it goes y'know?

[Delay]

11 minutes ago, richfiles said:

They are transitioning from Intel x64 CPUs to in house Apple manufactured ARM CPUs.

Now they're truly "Think(-ing) Different(-ly)".

[richfiles]

Think Different, by putting the same serial number onto every single part, so nothing can be replaced or upgraded... 
I can't wait for the Louis Rossmann rant on how this is gonna affect future repairability...

[Delay]

18 minutes ago, richfiles said:

I can't wait for the Louis Rossmann rant on how this is gonna affect future repairability...

While the new models may be orders of magnitude more difficult to repair independently (or even impossible), older Macbooks don't vanish. Now, relying on old, outdated tech to stay afloat is not good either and bodes a slow, financially painful death, but at least that would - almost literally - buy him time.

Edited June 23, 2020 by Delay

[richfiles]

His job won't go anywhere... It just gets harder. He can't replace a CPU in iPhones already. What he can do is restore corroded boards, replace the more generic parts, and get a device to operate either at original capacity, or more often, just enough to power on and transfer otherwise unrecoverable data, like photos, contacts, etc. off the old damaged phone, and onto a new one. Data recovery is his primary revenue.

Now, regarding prolonging old tech... I did that. I don't wanna repeat that. I did it once, when Apple transitioned from Power PC CPUs to Intel CPUs.

2005 Announcement
2006 First gen low end Intel Macs are released (Apple updates Mac OS 10.4 with Rosetta, a dynamic binary translation emulator to run Power PC instructions on Intel silicon)
2007 Mac OS 10.5 Leopard is released (final OS supporting Power PC CPUs)
2008 Intel Macs stop sucking - I make the horrible choice of picking up a G5 on the cheap this year...
2009 Mac OS 10.6 Snow Leopard releases (drops support for booting on PPC hardware)
2010 The point when I felt using a G5 was unbearable... By this time, nearly all software support had ended.
2011 Mac OS 10.7 Lion releases (drops Rosetta, killing all PPC backwards compatibility on Intel hardware)
2011 PPC hardware is declared "vintage". Most support and parts availability is ended
2013 PPC hardware is declared "obsolete". ALL support and parts availability is ended

Notice it only takes 5 years to go from current machine to "put me out of my misery"? The transition will not be kind to those who linger on old hardware. I went though it once. It was not fun. Apple has mastered these transitions (this is their third), and they will absolutely leave you behind if you don't keep up.

[TheSaint]

8 hours ago, richfiles said:

Apple made the official announcement... They are transitioning from Intel x64 CPUs to in house Apple manufactured ARM CPUs.

This is the end of Hackintoshes.
This is the end of any support for the last decade and a half of legacy software, including games.
Gaming on Mac is going to be an even worse situation than it already is...Porting won't just be between two x64 platforms, but now x64 vs ARM.
This is the end of Mac repairability and upgradability... I mean, this was happening already, but this just doubles down on serialized components and lockouts.
Mac OS will be incorporating more elements of iOS... Eww... 

I guess I better get used to the awful trash that is Windows, or learn to Linux.

I'm a Windows user, personally, because I've been doing Windows for almost three decades professionally. That said, there are a lot of Linux desktop distros right now that are just as easy to use as Windows or MacOS. Mint and Elementary come immediately to mind, but I'm sure there are more.

[Geonovast]

ARK Survival Evolved had a huge update recently, a big celebration for their 5 year anniversary.

That was apparently completely untested.

It broke everything.

They've pushed out well over a dozen patches since thing, but it's still hilariously broken.  I was running a private server in my basement for myself a few friends.  Well, we can't play anymore.  It's been like a week and a half and it's still broken.

I get that any update will have issues, but I don't think they tested this one at all.  When it was released, I saw reports of most, if not all, of the official servers were broken.  Pushing out software to meet some arbitrary date rarely works well.  Just call up Microsoft and ask them how Windows ME went...


.... I wanna play ARK. 

[IncongruousGoat]

9 hours ago, richfiles said:

Apple made the official announcement... They are transitioning from Intel x64 CPUs to in house Apple manufactured ARM CPUs.

This is the end of Hackintoshes.
This is the end of any support for the last decade and a half of legacy software, including games.
Gaming on Mac is going to be an even worse situation than it already is...Porting won't just be between two x64 platforms, but now x64 vs ARM.
This is the end of Mac repairability and upgradability... I mean, this was happening already, but this just doubles down on serialized components and lockouts.
Mac OS will be incorporating more elements of iOS... Eww... 

I guess I better get used to the awful trash that is Windows, or learn to Linux.

Re. the legacy software thing: Not immediately. Like Apple did the last time they switched architectures, they're providing an emulation layer to allow running of old x64 apps on the new (ARM64) hardware. They're going to take it away eventually (like they did with the PPC->x86 transition), but at least it postpones the problem for a few years. For the apps that can be run under emulation, which won't be all of them.

EDIT: Oh, I see you were around for the PPC->x86 transition. Welp. Anyways, it'll be like that except maybe worse, since JIT compilation is really popular nowadays and is going to tank the performance of their emulator.

Edited June 23, 2020 by IncongruousGoat

[Delay]

We're doing cryptography in school, and we were introduced to the Enigma as an example of an encryption system (that ended up having a really stupid design flaw that made it vulnerable to all sorts of exploits, but that's not the point). Wouldn't it be great to build an Arduino-powered replica, where the PC keyboard turns on one of 26 LEDs? I wanna build that! For fun educational reasons! We're done with this year's subjects for the most part, in fact last lesson we really just discussed things that didn't even come close to informatics. "Do whatever you want", basically.

Right, so there are 26 letters in the alphabet, uppercase and lowercase doesn't matter since the codes were written down and transmitted in uppercase anyways. Each lamp needs to be able to turn on and off independent from any other and I only need to light up one at a time.
The standard Arduino has 14 digital pins, so I can't simply connect one lamp to each pin and call it a day. If I can't transmit the required amount of signals, I need some sort of code that I can send that can be interpreted as the LED to turn on. So far, so good. Find a way to encode >= 26 signals with as few pins as possible and I'm done!

So, here are my ideas for how to do that:
Demultiplexers are a thing. If I can somehow get my hands on a 5-line to 32-line demultiplexer I could set up the characters in binary and interpret them on the board, meaning I'd only need 5 pins!
Nevermind, 5 to 32's don't seem to exist. 3 to 8's do, though. But given 5x input + 32x output + Vcc + GND = 39 pins at best, I'm not surprised no one seems to make them. That chip would be huge.

Okay, so I thought of a system one can work with, at the expense of one extra pin: The first two encode which "row" of the keyboard could light up; there are only three (QW..., AS..., ZX...). The rest encode which LED in that row should light up. Now the chip usage is getting a little ridiculous and anyone with more experience or any at all would probably already point out ways to do it with less or even without just one: 2 BCD to decimal, one 3 to 8 (the bottom row only has 8 keys, so I can get away with that). The alternative would be 26 ANDs with just one demultiplexer - one AND for each row-LED-pair - but that would be even more ludicrous in my eyes.
While that may not at all be the best system that could be used, I'm fairly certain it could and would work if actually built. Plus it provides a nice exercise for data transmission with limited means - I know that there are Arduinos with over 50 pins, but this isn't KSP; MOAR PINS isn't a realistic option. For a start, that 50+ pin microcontroller is far more expensive than my Rube Goldberg chip abomination.

My school would be willing to order the necessary parts - I'm not totally convinced they're not just waiting for a reason like this one to buy a logic gate or two. They're doing the same thing for library books - wait until someone needs it.
But with only around two weeks left in the year and uncertain delivery times due to the pandemic, I guess that won't happen for some time.

tl;dr: Complaint: Electrical systems being overly complicated without a simpler solution in sight and everyone's favorite subject - COVID-19 - thwarting my plans no matter what.

[IncongruousGoat]

7 minutes ago, Delay said:

The standard Arduino has 14 digital pins, so I can't simply connect one lamp to each pin and call it a day.

The standard Arduino might not have enough pins, but the Arduino Mega has 54, which oughta be more than enough.

[Shpaget]

I'm just finishing an Arduino project that uses CD4021 shift registers for inputs (4 of them for 32 inputs total) and TPIC6B595 for outputs (12 of them for 96 outputs total).

You only need 6 pins to handle all of that (3 for inputs and 3 for outputs). Of course you can chain as many of either/both as you need.

If you need a hand, just say.

[captainspock]

Not as much negativity as I expected.

[TheSaint]

1 hour ago, captainspock said:

Not as much negativity as I expected.

We're actually a pretty positive bunch around here. We've been chastised by the mods on multiple occasions for not being negative enough in the Negative Things thread.

[captainspock]

I see! Kudos!

32 minutes ago, TheSaint said:

We're actually a pretty positive bunch around here. We've been chastised by the mods on multiple occasions for not being negative enough in the Negative Things thread.

 

[kerbiloid]

On 6/23/2020 at 10:25 AM, richfiles said:

Think Different

"... , we don't care."

2 hours ago, captainspock said:

Not as much negativity as I expected.

Accumulating.

54 minutes ago, TheSaint said:

We're actually a pretty positive bunch around here. We've been chastised by the mods on multiple occasions for not being negative enough in the Negative Things thread.

The negative pole attracts positive particles.

[razark]

My desktop died.

Lights turn on, fans spin, but no POST.

[richfiles]

On 6/24/2020 at 10:25 AM, Delay said:

We're doing cryptography in school, and we were introduced to the Enigma as an example of an encryption system (that ended up having a really stupid design flaw that made it vulnerable to all sorts of exploits, but that's not the point). Wouldn't it be great to build an Arduino-powered replica, where the PC keyboard turns on one of 26 LEDs? I wanna build that! For fun educational reasons! We're done with this year's subjects for the most part, in fact last lesson we really just discussed things that didn't even come close to informatics. "Do whatever you want", basically.

Spoiler

 

Right, so there are 26 letters in the alphabet, uppercase and lowercase doesn't matter since the codes were written down and transmitted in uppercase anyways. Each lamp needs to be able to turn on and off independent from any other and I only need to light up one at a time.
The standard Arduino has 14 digital pins, so I can't simply connect one lamp to each pin and call it a day. If I can't transmit the required amount of signals, I need some sort of code that I can send that can be interpreted as the LED to turn on. So far, so good. Find a way to encode >= 26 signals with as few pins as possible and I'm done!

So, here are my ideas for how to do that:

Demultiplexers are a thing. If I can somehow get my hands on a 5-line to 32-line demultiplexer I could set up the characters in binary and interpret them on the board, meaning I'd only need 5 pins!
Nevermind, 5 to 32's don't seem to exist. 3 to 8's do, though. But given 5x input + 32x output + Vcc + GND = 39 pins at best, I'm not surprised no one seems to make them. That chip would be huge.

Okay, so I thought of a system one can work with, at the expense of one extra pin: The first two encode which "row" of the keyboard could light up; there are only three (QW..., AS..., ZX...). The rest encode which LED in that row should light up. Now the chip usage is getting a little ridiculous and anyone with more experience or any at all would probably already point out ways to do it with less or even without just one: 2 BCD to decimal, one 3 to 8 (the bottom row only has 8 keys, so I can get away with that). The alternative would be 26 ANDs with just one demultiplexer - one AND for each row-LED-pair - but that would be even more ludicrous in my eyes.
While that may not at all be the best system that could be used, I'm fairly certain it could and would work if actually built. Plus it provides a nice exercise for data transmission with limited means - I know that there are Arduinos with over 50 pins, but this isn't KSP; MOAR PINS isn't a realistic option. For a start, that 50+ pin microcontroller is far more expensive than my Rube Goldberg chip abomination.

My school would be willing to order the necessary parts - I'm not totally convinced they're not just waiting for a reason like this one to buy a logic gate or two. They're doing the same thing for library books - wait until someone needs it.
But with only around two weeks left in the year and uncertain delivery times due to the pandemic, I guess that won't happen for some time.

tl;dr: Complaint: Electrical systems being overly complicated without a simpler solution in sight and everyone's favorite subject - COVID-19 - thwarting my plans no matter what.

So, I have a method that'll work for you using only LEDs, resistors, diodes, and keyswitches... And 12 pins. That's it.

Wire the LEDs like this. you can control up to 30 LEDs using only 6 wires. The technique is called Charlieplexing. The default state of an LED control wire is actually for it to be set as an input, which leaves it in a high impedance state (current can't easily flow through it). You then set the two pins that intersect a given LED pair to either high and low, or low and high, to address the positive or negative polarity LED at that selected junction. 


Nerd stuff hidden, cause it HUUUUGE!

Spoiler

 

Now here's the trick...the 8 remaining wires are not enough for a keyboard matrix, but remember that the LED control pins are in the default state of being inputs.

If you use the 6 pins for controlling the LEDs, when set as inputs, you can also detect when a switch is pressed. With proper coding, you should never short out the pins, even if a key is held down while they are set as outputs. The software should periodically switch all the LED pins to inputs, read if any have inputs that correspond to a keypress row's output, then the two I/O lines that represent the LED junction should then be set high and low, to light the correct LED. It should scan between lighting the correct LED, and pulsing the row digital outs + reading the LED pins when set as inputs. There should be a small resistor between the LEDs and the I/O pins, to limit current, but the key switches should bypass the resistors, and connect directly to the Arduino pins. After scanning for a keypress, it should alternate between setting the row digital I/O to inputs (to create a high impedance), and set the two intersecting LED junctions to the correct output polarities.

In theory, if you set rows to be inputs, they should be high impedance, so I THINK there should never be a shorting state, with clean coding!

With 6 columns to scan, and 8 rows you could have as many as 48 keys, which is FAR more than you actually need. you could use 5 rows, and read 6 columns, and still be able to encode 30 keys, with 2 digital I/O left over for whatever you like... One I/O pin needs to be reserved for a pull down resistor... Hmm... Unless the Arduino can set that internally. It might be possible to omit that, in that case.

So, the flow of the software would be like this:

0: When first starting up, initialize by setting A0-A5 and D0-D5 all to inputs ~(you can use whatever pins you want)
1: Define KEY, LEDoutput, LEDhigh, and LEDlow variables, and store 0 into all of them. ~Define any other variables needed for the cryptography process
2: Define the LEDhighLookupTable and store the correct values in it.
3: Define the LEDlowLookupTable and store the correct values in it. ~Define any other lookup tables needed for the cryptography process

4: Change D5 to Digital out, set 0 ~Start of the main program loop, and activates the pull down circuit. This creates a weak 0 signal on A0-A5, or set pulldown internally, if Arduino can do this.

5: Change D0 to Digital out, set 1. Read A0-A5. If a value of 1 is returned, store the input that was high+1 into KEY variable. Change D0 to Input
6: Change D1 to Digital out, set 1. Read A0-A5. If a value of 1 is returned, store the input that was high+7 into KEY variable. Change D1 to Input
7: Change D2 to Digital out, set 1. Read A0-A5. If a value of 1 is returned, store the input that was high+13 into KEY variable. Change D2 to Input
8: Change D3 to Digital out, set 1. Read A0-A5. If a value of 1 is returned, store the input that was high+19 into KEY variable. Change D3 to Input
9: Change D4 to Digital out, set 1. Read A0-A5. If a value of 1 is returned, store the input that was high+25 into KEY variable. Change D4 to Input
~KEY variable is set to 0 at startup, but if A0 goes high when Row D0 is active, 1 is stored in that variable (0+1). If A3 goes high with D2, then 16 is stored into KEY variable (3+13).
10: Change D5 to Input ~This shuts off the pulldown resistor circuit, and ends the key switch scan.

*** whatever crypto happens, it probably will fit in right here. Read the KEY variable, do your magic, and store the result into LEDoutput 

13: If KEY = 0, jump to step 17
14: Read LEDoutput and use the stored value to read the correct position in LEDhighLookupTable, and store it in LEDhigh.
13: Read LEDoutput and use the stored value to read the correct position in LEDlowLookupTable, and store it in LEDlow.
14: Read LEDhigh and change the corresponding single I/O pin (one of A0-A5) to a digital out, and set it to 1
15: Read LEDlow and change the corresponding single I/O pin (one of A0-A5) to a digital out, and set it to 0
16: Optionally waste a few cycles here, if the lit LED is too dim
17: Change A0-A5 to inputs

18: Jump back to the start of the loop, at step 4.

*** This sequence should give you a basic functional program to light an LED based on what key is pressed. You can change the lookup tables to represent different LED outputs for the key inputs. I don't recall exactly how complex the enigma machines were. but you could probably represent the different (was it drums?) with sequential lookup tables, and just have the output of one serve as the input to the next, till the final one outputs to the two lookup tables to select what wire goes high, and what wire goes low to select a specific LED.

If I read the LEDs from left to right, top row to bottom row, then the lookup tables for using pins 0-5 would be as follows:

LED	HIGH	LOW
1	0	5
2	5	0
3	0	4
4	4	0
5	0	3
6	3	0
7	0	2
8	2	0
9	0	1
10	1	0
11	1	5
12	5	1
13	1	4
14	4	1
15	1	3
16	3	1
17	1	2
18	2	1
19	2	5
20	5	2
21	2	4
22	4	2
23	2	3
24	3	2
25	3	5
26	5	3

There are still 4 LEDs left unused for this configuration. If you wanted to use them for whatever reason, the table would continue as follows.

LED	HIGH	LOW
27	3	4
28	4	3
29	4	5
30	5	4

I'm not actually any good at coding... So that kinda sucks... I feel like I could do a lot if I knew how. I really need to learn.
Regarding KEY input 0, you just want to watch have the LED routine skip the step of setting anything high or low, so nothing happens, and just jump tot eh end of that routine, to make sure all LED pins are still set to inputs.

 

 

Edited June 26, 2020 by richfiles

[Delay]

57 minutes ago, richfiles said:

So, I have a method that'll work for you using only LEDs, resistors, and keyswitches... And 14 pins.

Yeah, I thought so. I've already stumbled across Charlieplexing while lazily looking whether someone else has already done the work for me. I quickly dismissed it, however, for one I (now embarrassingly) didn't understand how it worked, having no experience in electric systems and having had to look up what impedance even is. It's actually a really simple setup, now that I'm sure I understand it.

One other thing I don't get is Vcc itself. On a multimeter, I get a negative voltage reading when comparing Vcc to GND and I don't understand how that is even possible. Vcc is the power supply and has a lower potential than ground?

Anyways; by "Keyboard", I meant the PC's keyboard, the Arduino would constantly be connected to it. I've never done that before, but I think that can be done via the serial port? I actually have to look into that more, but the main problem for now is the LED array.

[richfiles]

Oh... LOL... I figured you wanted some self contained box with 26 keys and 26 LEDs that was entirely self contained. I mean, if it's gonna be hooked to a PC, and get inputs from it's keyboard, I don't see why you'd need an Arduino at all... It could just be fully software, displaying on screen. If you mean to use a PC keyboard attached to the Arduino, then it only takes 2 serial wires, and I do belive there are libraries to handle that.

If you go with a PS2 Keyboard, attached via serial, directly to the Arduino, then that leaves you 12 wires to control the LEDs. a simple multiplexed grid of 9x3 will let you control 27 LEDs, plenty to show your 26 letters.

Ground is your "neutral" or negative voltage. If you attach the negative (typically black) lead of your multimeter to ground, and the positive (typically red) lead to the VCC, you should read a positive voltage. VCC just represents the positive power supply. There can be other designators, but VCC is most common, and is often used generically to represent the positive supply. If your multimeter leads are flipped backwards (red to ground, black to Vcc), then you will get a negative reading, since the flow through the wires will have been reversed. Just think of a circuit as a map. You battery or power supply is home. ground is where your electrons leave, and they have to travel a round trip, returning "home" by way of VCC. If you break the path, electron flow will stop.

Edited June 25, 2020 by richfiles

[Delay]

11 minutes ago, richfiles said:

I figured you wanted some self contained box with 26 keys and 26 LEDs that was entirely self contained.

That's why I said this is entirely for fun and serves no practical purpose other than having an excuse to work with a microcontroller. Though I guess there is the possibility that I'll make an "actual" replica just for myself at some other time, then I would need 26 keys as well.

[TheSaint]

3 hours ago, razark said:

My desktop died.

Lights turn on, fans spin, but no POST.

Back about four years ago now (according to my Newegg purchasing history) I noticed that the vents on my desktop had accumulated a ton of dust. I pulled the case out from under the end table, opened it up, and it was filthy. So I decided to take it out into the garage and blow it out. Fired up the air compressor, blew it out real good, nice and clean. Brought it back in, hooked it back up. Nothing. Fans and lights but blank screen, no POST beeps, nothing. Totally bricked. No idea what happened. Maybe some kind of conductive debris blew into the wrong place, shorted something out, no idea. But, it was five years old at that point, so I figured it was easier to upgrade than spend a ton of time troubleshooting five-year-old hardware, so I went out and bought a new upgrade kit: new processor, motherboard, graphics card, memory, and a power supply since the old one didn't meet the specs for the new graphics card.

The amusing part was that my wife was really cranky about the whole thing. I have to admit, from her perspective, it did seem a bit conspiratorial: Husband takes old computer out to garage to "blow out the dust", brings computer back in, suddenly computer won't boot and husband needs to buy new computer.

Come to think of it, it's been over four years now, and the computer is looking a bit dusty....

[DunaManiac]

A few months ago I was walking in my neighborhood with my friend, she stopped to have a phone call and my dog, who is really attatched to her, sat down on the grass for some reason. Some old man who was watching us I guess must have thought my dog pooped, and so when I started to leave, he started to cuss me out for not cleaning it up, even though my dog clearly had not. I went on home and I didn't see that man again, although I still hesitate to walk by his house.

[richfiles]

58 minutes ago, Delay said:

That's why I said this is entirely for fun and serves no practical purpose other than having an excuse to work with a microcontroller. Though I guess there is the possibility that I'll make an "actual" replica just for myself at some other time, then I would need 26 keys as well.

I updated my original message with my best approximation of what a self contained program loop would entail, and what it takes to drive the charlieplexed display. If you use a pair of lookup tables, driving the display actually ends up being super simple.

Say you wanna light up LED number 15.
Look up the 15th number in the high state Lookup table, and the 15th number in low state lookup table.
You get the results 1 from the high lookup table and 3 from the low lookup table.
So then you change A1 to digital out and set it to 1, and change A3 to digital out and set it to 0.
After wasting a couple cycles, so the LEDs have enough time lit, you set A0-A5 all back to Inputs.

Provided the code works properly, it lets you scan 26 keys (up to 30 max), and control 26 LEDs (up to 30 max), using only 12 I/O pins.

[Shpaget]

In this case where there is a maximum of only one input key pressed at any given time, you can also use one analog input pin to monitor multiple buttons, each hooked up to a slightly different voltage divider. If you pick the resistors so that each button gives you half a volt different readout you can easily get 10 buttons on one pin and still have quite a big margin for noise.

That being said, I'd still go for shift registers for outputs. Mixing inputs and outputs on the same pins requires careful sequencing, since a misstep will cause a dead short if any A pin and D pin (richfiles schematic) are set to output simultaneously and one HIGH while the other is LOW and a button is pushed.

Controlling shift registers is dead simple using the shifter library.

shifter.setPin (LookupTable [i], HIGH); //sets the pin HIGH to turn on an output
shifter.write(); // sends the new states to the registers, only now the changes take effect

Lookup table is to adjust for physical location of pins on the IC package and ease of PCB trace routing.

[richfiles]

True that shift registers are more failsafe, but given the constraints (2 weeks of school + COVID shipping delays + plus unfamiliarity with hardware), it's a case of what parts are on hand. In this case, a software solution solves the problem. You can also use a resistor between the Arduino and the switches to current limit them, to protect in the case of software error. As long as the combined resistances allow the voltage to rise above the rising logic high threshold voltage, it should be good. Likewise, using analog in, it can just detect >x.

In the case of using extra protections, 6 more resistors are added between pins A0-5, and the keyboard wires, so each wire has a resistor on either side. That protects both the LEDs and the Arduino.

[Delay]

15 minutes ago, Shpaget said:

That being said, I'd still go for shift registers for outputs. Mixing inputs and outputs on the same pins requires careful sequencing, since a misstep will cause a dead short if any A pin and D pin (richfiles schematic) are set to output simultaneously and one HIGH while the other is LOW and a button is pushed.

The way I understood it, from the programming side, is that first the inputs are read, then the LED is turned on, and then the process is repeated. This would cause the LED to flicker, but just like Charlieplexing with multiple LEDs on "at the same time", it's too fast to notice. So the naive way I see it, there should never be a conflict because input and output never happen simultaneously. Heck, if I'm worried about pinmodes I can sacrifice the cycles and make a function/macro dedicated just to setting all pinmodes to input.

Perfect, now I feel like the odd one out for only understanding half of what you guys are talking about.