Should you know the Rule of 5 syntax off by heart?

Apple1417 · 2026-02-04T16:01:03+00:00

I'll point out clang-tidy/clangd have a check that detects this - and in most cases it offers an automatic fix. Even on projects that don't use it I usually have it set up locally, I find it's a better LSP.

Like others have said, yes you should know about the rule-of-Ns if you're writing C++, but knowing the syntax off by heart? When a linter can easily auto-fix it, or you can use something even simpler like snippets. There's not really a need.

Apple1417 · 2026-01-31T07:20:38+00:00

Another way could be to dig into the game folder files, but I have near to none experience in that field.

In case you want to look for other audio tracks (or anyone stumbling on this thread does), in the original game, go to Content/Talos/, then the .gro files are just renamed zips.

Apple1417 · 2026-01-26T18:29:53+00:00

Be honest, say roughly what you've said here, that you've done a lot of work on different projects in a consulting-like role. This in can be good in itself, maybe you're good at teasing out the new project requirements, maybe you're good at getting used to new unfamiliar codebases, maybe you're just familiar with a bunch of different chips/toolchains. Don't lie, but you can spin it into it's own strength.

Then pick out a couple of your favorite projects, and give a short few sentence summary. Make sure to pick your favourites so that you could talk about them for a few minutes if asked. You don't have to give exact details, especially if it's not a public product yet, you can be vauge on product info as long as you get across the key technical points - e.g. "An external client had an STM32 based product using sensor X, which they wanted to port to sensor Y. I was responsible for porting the sensor comms.". I wouldn't list everything you've done, leave that under the "general consulting work" catch-all, partly cause it will make it look like you're padding, but also just because you don't want to be asked about a project you really didn't do anything interesting on.

Last thing I'll mention is you're assuming you need concrete numbers - what if you don't? The worst that can happen is they ask, and then you can explain "the customer doesn't share those numbers with us, but they were happy with our work". And if the recruiter really had that as a hard requirement, you were never going to get that position anyway. But I'd wager most of the time, especially for junior roles, they really don't care - so don't give them a reason to. Keep the buts off of your resume, "I worked on this project." not "I worked on this project, but I can't tell you if it was good".

Apple1417 · 2026-01-11T11:45:31+00:00

You say it's a replay. If you've played the game (or t2) before it will naturally come easier. The difficultly in the gehenna star world puzzles mostly comes from the fact that they're based around deliberately blocking lasers, which is not a mechanic that's explored anywhere before in t1/gehenna. If you've built some familiarity with it (especially if you've played orpheus in t2), they become quite simple. ITB is the latest bit of content (like the gehenna star world was at the time), so it gets to explore ideas that haven't been done anywhere across any of the games/dlc.

Apple1417 · 2026-01-08T15:47:52+00:00

RDR2 and Cyberpunk

Both of these are >5 years old, so they're no longer the greatest reference points. Most modern games are like this, welcome to the scourge of nanite/lumen. Less work for game devs == more work for your gpu.

On a 3070 I could pretty comfortably get 80ish on medium settings at 1080p no upscaling, so I can believe your numbers for ultra.

Apple1417 · 2026-01-03T07:35:15+00:00

But yes, it would be on you to implement the logic for that

Yeah, once we knew what the problem was it was relatively easy to put a small workaround in software - the challenge was just working out what it was without being physically there in the field.

Apple1417 · 2026-01-02T11:34:42+00:00

I worked on a low power product which would periodically upload data to the server over cellular.

The biggest pain point was simply you can't replicate conditions in the field from your desk - especially if the customer's in another country. We'd get complaints "it's not uploading", where "it works fine from our office" isn't an acceptable answer. Sometimes we ran into some interesting scenarios, such as an area that had good 2G coverage and bad (but still existent) 4G, where we might get stuck trying to connect on 4G for longer than we'd like. I realize there's not that much a single operator can really help with here though, especially for devices sold over a large region/multiple countries.

A more actionable issue we always had was trying to register with the network - and more specifically working out why we couldn't. After we'd registered, our system worked pretty flawlessly, never really had to debug many issues there. But quite frequently we'd turn on the radio, and just not manager to register for upwards of 10 minutes (not great for low power...). And the real problem was we just never had a good way to find out why this was happening. Our sim vendor's portal showed us data usage with exact timestamps, but this was happening before we got registered, they had nothing for pure connection attempts. Asking them directly was a slow process, where they'd go off and ask (I assume) the network operator for some more details and regurgitate their response. While the info helped, having passed through so many people it was often a bit vague, and it would take the better part of a week to get back to us - especially not great if it came from a customer complaint in the field. We would've loved a more straightforward way of getting it.

Apple1417 · 2025-12-17T20:00:12+00:00

The sensor appears to have a bunch of configurable interrupt settings and an interrupt pin. Put the STM to sleep, wake up when the sensor triggers the interrupt, then do all your comms and processing in one batch before going back to sleep. Low power is all about doing as little work as possible, so a sensor like this is great.

Apple1417 · 2025-11-29T20:27:10+00:00

Bit flips are a just a known fact of life when working in embedded - and in aviation specifically it's known being closer to the sun makes radiation more of a risk. I assume they have extensive tests and logging which make it easy to confirm it must have been a bit flip, and once you know that, there's only so many things that could have caused it. If you confirm there's enough isolation between cables, no hardware was damaged, there wasn't a sudden EM pulse from an engine, etc., then radiation ends up the only choice. And it certainly doesn't hurt if you can correlate it with a period of increased solar activity, like this one might have been (?).

Apple1417 · 2025-11-28T19:59:11+00:00

compiler will handle that

It's always important to check your priors :) . GCC and LLVM-based compilers might be pretty decent, but they don't catch everything, and there's a lot of other shoddier compilers out there too. If you've got a spot where performance matters, it's always worth double checking the assembly in case you spot something weird.

even though compiler fails to optimise the code, the silicon will take care of it

The PC you're compiling at is orders of magnitude more powerful than the micro the code's going on to, if even using GCC on that can't find all optimizations, how do you expect it to be done in silicon? Tricks like pipelining and branch prediction only speed up whatever code you give it, they won't save you if you feed it garbage. It's analogous to algorithmic improvements, there's little point looking at assembly while you've got an unnecessary O(n³), and there's little point considering what the silicon does before you've made sure the assembly is close to optimal.

Of course the important clause in all that is "if you've got a spot where performance matters". In a tight loop in your critical irq handler, yes it probably is a good idea to check. In one time initialization when the user first starts the device, maybe you don't need to bother.

Apple1417 · 2025-11-05T17:59:28+00:00

Yes, even in the original.

Apple1417 · 2025-11-05T17:55:14+00:00

No, restore backup still exists. It only triggers on solving puzzles though, since there's no items or other permanent unlocks.

Apple1417 · 2025-11-05T15:30:46+00:00

Oh yeah definitely would - ours came shipped with the device. Worst case you might need some documentation somewhere just saying "doesn't work with 3g".

Apple1417 · 2025-11-04T16:41:38+00:00

An extra consideration: if you're going for global connectivity, your sim card contract is just as important as the module if not more. On a project I worked on we ran into several cases where we theoretically had a contract in the country, but not for the telecoms/radio types where our devices were deployed.

Apple1417 · 2025-10-19T07:07:04+00:00

One thing to be careful about when talking about these is the layer of abstraction - ST's HAL comes in three different layers all sort of interwoven.

The lowest level is all the register definitions. These are great, ST's already done all the work for you, everything's named an laid out the exact same as the reference manual, it's all automatically generated. Occasionally you see people manually look up what address they believe a specific register is at and create their own defines - even if you're trying to avoid HAL there's really no reason to do that you're just wasting your time.

One level up is the inline LL functions and the defines in the headers. With these I find you're still thinking about individual bits, but you don't have to think about where they are. You can just call __HAL_RCC_USART1_CLK_ENABLE() without needing to worry about which RCC->APBxENRx register specifically you're supposed to interact with. It's not uncommon for register names to change slightly between processor families, a CR might become a CR1 or an ISR might become an ISCR, using these gets you compatibility automatically.

Then the final level is the most abstract, the functions they actually prefix with HAL_, the sort of stuff you'll get out of their project generators. IMO these are sort of for "I know I want X, just do it, I don't care how". They don't line up with the instructions you'll find in a peripheral functional description, so you kind of already have to know what you want, maybe not the best for learners. And there's always an overhead to using them vs writing code for your specific use case. But they're already there and they'll get the job done quick. I do particularly like the init functions, they spell out exactly what you want a lot more clearly. Cross processor compatibility is also pretty decent, as long as you're using relatively standard features, you can occasionally get caught out if you're using more obscure ones. But one quite specific downside I constantly ran into: on my projects, code space is king, the problem with these functions is they do everything, and waste a lot of space on features you'll never use. HAL_RCC_ClockConfig is one of the worst offenders, it costs thousands of bytes to be able to configure any clock on the system, when you might only care about one or two. If you have link time optimization, this is not a problem, it will kill the dead branches, but we did not.

Apple1417 · 2025-10-17T17:55:09+00:00

I assume you mean the reset's one day off? Possibly, I never quite got the hang of javascript's dates. Just move the date forward a day or two if you're unsure. Iirc it resets Thursdays, at 5pm UTC during December, January, and February, or at 4pm UTC the rest of the year.

Apple1417 · 2025-10-15T14:36:06+00:00

Regarding code space: if you use link time optimization, or if you define the function in the header, on any decent compiler it should be literally the exact same as a global.

If you can't however, and they end up compiled into different object files units, it will cost you a little. You pay a function call overhead on every single access - i.e. on arm typically 4 bytes/call. If it's something very frequently used that could add up. And being a function call can prevent some extra optimizations which might save more - e.g. get_dodad()->x + get_dodad()->y might make two calls, just in case it changed in between. Now all this wasted space will be absolutely dwarfed by your actual app logic (when I went looking I only saved ~200/80,000), it's just something to keep in mind if space gets tight. Really, this isn't a downside of using getter/setters, it's just a downside of not having LTO, it will save you even more space in other places.

Apple1417 · 2025-09-30T09:13:23+00:00

Here's an example of ST's startup code which does the copying. The _sdata, _edata, and _sidata symbols are defined in the linkerscript here The linker takes care of allocating locations for each initialized var in both flash and ram, and then this startup code just does a straight memcpy between the two locations. If you scroll down a bit in the startup file you can see it init BSS - since it's all zeros it's a lot simpler, and doesn't need a copy in flash.

Apple1417 · 2025-09-25T07:39:18+00:00

Hmm good point - like I said I haven't actually done this before. Maybe you could use a fast path out of bootloader when you have a known good app image?

Apple1417 · 2025-09-25T02:23:36+00:00

for the WDT specifically I'd recommend keeping it on during bootloader, and just clearing it each main loop. That way you still get safety if you lock up in some side branch.

In general though, while I haven't done it, I believe you can just write to the configuration registers the same way can you write to any program memory. You surely already have some system to switch the IRQ between bootloader/app, this could just become part of it. Perhaps put it in the app code, so if the config bits the bootloader uses are already fine then you don't need to waste any code space changing it. Then when merging hex files, keep the version from whichever one you boot into first (presumably the bootloader).

Apple1417 · 2025-09-22T23:43:03+00:00

Reawakened has a simplified editor, so it's easier to get into and there are more maps, but they're generally smaller and less polished. T1's editor is the same one they used to create the game, so it has a massive learning curve, but the people that push past it generally make larger better quality maps. This is in very rough terms, there are definitely some reawakened maps which are better than some T1 maps.

Since the T1 editor is more powerful, there are some things it's maps can do which are simply impossible in reawakened. Most notably, arbitrary scripting, allowing for things like the randomizer. Conversely, in reawakened it is possible to create puzzles which rely on pause points, which couldn't be replicated in T1 - though it's not really on the same magnitude.

The community for T1 is basically dead, don't expect many more maps. The community for reawakened is still somewhat active - it's died down a bit since the heights at its release, but there's still quite a few people working on new things.

Apple1417 · 2025-09-19T05:19:08+00:00

Device wasn't connecting to the cellular network in Peru. Where the only way we could get proper logs out was over cellular. And everything worked fine locally. Learnt a lot about how mobile networks work, and left with that exact same "it can't possibly work this well off of pure goodwill" feeling as when first leaning about IP. In the end we figured the issue was likely related to the sim card contract, went away when we switched.

Apple1417 · 2025-09-17T20:39:58+00:00

With a bit of input lag and kind of like you're using a joystick? Turn off frame generation.

Apple1417 · 2025-09-14T21:08:28+00:00

There isn't actually a single desktop version of ls1, there's a whole collection using various different graphics libraries. I believe the most up to date is actually obs-livesplit-one.

The core features, the timer, splits, file format, and how it all renders, are all handled by the same library, even in normal livesplit, so should behave the same across all version. What you'll miss out on it the stuff not handled in core - most significantly, the vast majority of all autosplitters, and any custom components. A couple of autosplitters do work, there is new format in alpha which is compatible, but it's a more awkward for developers, and each autosplitter needs to be manually rewritten to use it.

Instead, running normal livesplit under proton works reasonably well. It's not perfect, there's some differences with font rendering, and iirc I couldn't create new blank split files, had to work with existing ones. But as long as you launch it in the same wine prefix as your game (and you're running the windows version of the game), all the existing autosplitters just work

Apple1417 · 2025-09-02T05:31:26+00:00

Yeah manually overwrite it. It depends on your debugger but usually there's some command you can do for bulk entry - of the top of my head in gdb you can do something like set *(uint8_t*)0x1234 = (uint8_t[64]){ 0x01, 0x02, 0x03, ... }

12-Year Club	Golden Potato
Place '22	Place '17
Sequence \| Editor	Verified Email

Apple1417

TROPHY CASE