Readit NewsI'm curious - how much up-front coordination is mandated? Plenty of the interview loops I've done agree in advance to the exact set of questions we'll ask during an onsite specifically to avoid problems like this (which of course causes other problems...)
Here's a dumb list of some of the automation I want to see:
- Automated speed and acceleration limits based on location. In cities, 20km/h. From 0 to 20 in 5 seconds. On highways, whatever makes sense. But, sorry, you can't go 200 km/h unless you're on a track, a train or a plane.
- Automated / smart traffic lights to end unnecessary stopping and waiting, while giving priority to emergency vehicles, transit, pedestrians, bicycles over individual cars
- Automated emergency vehicle notification to drivers, without increasingly loud,blaring sirens (esp. at night when the streets are empty and response times are 2x better than during the day in the first place)
- Mandatory collision mitigation and other safety assists; you shouldn't have to pay more money to get a safer vehicle (especially safer for others)
- ...but no autopilot allowed outside of specific places/times (eg. certain highway segments at certain times)
- Automated, guaranteed fines when speeding, running red lights or driving recklessly.
- APIs for cities/counties/regions to influence routing decisions made by maps applications: people are free to drive on small streets but the algorithm should not send them there. Before I started using it, waze, in particular, often steered me to complicated routes via small streets to save 90 seconds in a 15 minute trip. Cities should be able to align traffic engineering decisions at all levels.
- Automated engine shutoff and notifications to prevent idling and educate folks. I see people browsing for minutes before/after driving, with the engine on. People eating in their cars with the engine on, etc. In front of folks sitting at a cafe etc. Just ignominious stuff given the noise, heat and air pollution output (idling generates more toxic exhaust than driving).
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.
https://www.nordicsemi.com/Products/Development-hardware/nRF...
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.
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.
Would something like circuitpython not be easier to work with?
Hopefully that makes sense, I'm new to all of this.
There's a comparison to be made to choosing to stay in the matrix or unplug yourself from the illusion.