Not very much. There's an interview lead that is supposed to make sure no question overlaps happen. They will sometimes comment on the chosen question (e.g. asking an unrelated question to someone interviewing for a research position). In general I think this is pretty rare as it requires folks to care about their interview before it starts. :)
I'm curious about that too. Recently, I've seen many screencasts in the same style, and I hate them. The constant movement of the recorded area is quite distracting.
is Zephyr a good option in a project that aims to expose a UART device through BLE using an nrf52x chip? At a glance it seems pretty low level, capable and possibly overkill. If not, what's more suitable?
Hopefully that makes sense, I'm new to all of this.
Bluetooth is an absolute nightmare if you don't understand the majority of what's going on (which in and of itself takes... a lot of time). There's a bunch of logic going on and most of it is handled in callbacks that you will never see, except the dreaded timeout/failure to handle print at the end of the main loop. Zephyr will ease a lot of those painpoints, with the understanding that you're ignoring a lot of the machinery humming under your feet.
Things that stood out to me:
0. If this is your first embedded project / you're actually new to all of this, get ready to take a beating. "Abandon all hope, ble who enter here."
1. Do yourself a huge favor and get two* dev kits. Nordic provides walkthroughs on getting setup with two flavors of code (zephyr, or low-level drivers). Each has a tutorial for uart forwarding/handling. Expanding on that tutorial will take a lot of futzing around, or actually learning what the machinery is doing under the hood. Learning the stack did not come naturally / I found it very difficult. Why two? Two lets the bluetooth abstraction handle itself / you don't have to deal with it right away when you're getting started.
2. If / when you want to attach your bluetooth device to something more useful (e.g. a computer or mobile device), do yourself a second huge favor and develop using linux + a laptop. I tried to do development on windows + WSL and there were many, many hangups with the hardware handoffs from PyBlues to the local bluetooth drivers. Maybe it's gotten better, but I doubt it. My other alternatives were driving direct from Windows bluetooth libraries (behemoths that would take time to setup / understand), or develop for mobile (which also will take time to setup / understand). Neither was an enjoyable experience.
so in summary:
Is Zephyr overkill? - Absolutely. But the path is well trodden.
Not sure if I understand, but you currently have a device that has UART enabled, and you are trying to communicate with it via BLE? Thus, you want to add a BLE chip, i.e. the nrf52, and then relay the commands from BLE -> UART for the second chip?
Regardless, Zephyr is an RTOS which provides OS functionality like scheduling, interrupt handling, semaphores, etc.
It is most likely overkill for what you are attempting to do. You should instead look at the vendor provided SDK for the nrf52 chip and program it bare metal. The SDK is most likely just libraries/drivers and does not come with an RTOS.
Yes exactly. This device is a mini exercise bicycle, it has half a dozen buttons and LEDs with a UART enabled chip that orchestrates everything. I'd like to make it controllable via Bluetooth (e.g. on/off, set speed) and have it send stats like current speed, etc.
Would something like circuitpython not be easier to work with?
I would suggest using either an Arduino w/ BLE shield or a raspberry pi pico w. Both platforms have great SDKs and a lot of online support/community. Raspberry Pi pico supports circuitpython if that is the route you want to go (i.e. if you are more familiar with python). But most embedded software is written in C/C++.
By that logic no one should ever do something nice because it doesn’t register at the macro scale. That’s ridiculous and a very dark and distorted way to view the world
It's pretty hard to learn a new keyboard layout on a regular keyboard, let alone replace the typing experience with chords (multiply this by the number of languages you use). The real difficulty for me was putting in the time every day to practice, while maintaining a job. You have to be pretty dedicated to pull this off.
