Oddbean

I honestly haven't owned a non Google device since the HTC Incredible in 2010 and Moto X in 2012. It's been Google Nexus and Google Pixel since. They are the most open and most developer friendly devices.

Yeah seems to be the consensus. I am honestly looking for alternatives. Every time I bring up the argument it goes, (like a dozen times on nostr) Them: yeah you don't have to buy a Pixel, there are other options Me: Sweet, literally name ANY other smartphone that is purchasable in the US, made within the past 5 years, works with US carriers, and can ACTUALLY be flashed. Not theoretically, like actually you've done it, or seen someone with your own eyes do it. Them: Oh, dunno the pixel is what I use and it works great. Me: *facepalm*, literally my argument! I just don't like that I have NO other option than to give Google money in software or hardware at some point. I just want the option to be different, don't like being told what to do XD

I need to keep the heat production down, way down, for the Australian summer. My Pixel powers off if I leave it on the passenger seat while I drive with aircon on, and its only late Spring. So that's a design constraint you probably won't have. There are a bunch of dubious diy smartphones built around the RPi Zero, but the heat production is unacceptable for me, even though I could fix the hideous form factor. So far I'm looking at hardware: Cellular module (anything SIM7000-compatible should do) e-Ink screen (4.3") Mechanical i2c keyboard LoRa module Huge lipo pouch cell (slow boat waiting on for two months now) 1S BMS Raspberry Pi Pico W Remote server (or shell account) to run heavy apps For the software, I've been collecting libraries. Going to run Micropython and go bare metal for the native apps (sms, calls, email, terminal client, image viewer, TCP-IP and Reticulum) and run as much as possible on the server. Will see!

That's quite interesting, I'll be following along! If you make it OSS I'd love to contribute. I have prosumer PCB design, LoRa, and FSK firmware and driver code experience :) I spent a ton of time on power management for AVR's and the radios too. We had pretty strict constraints and LoRa radios can pull a ton of power. e-ink will be interesting, simple i suppose. How big is the lipo?

I have an off topic question. Funny enough I have like a dozen pic boards but haven't had a chance to play with them. I was reviewing the debug assembly for noscrypt and realized how much I missed writing firmware. Question: do you have experience with a full or "commercial grade" simulation tool for the pico? I don't think they have debugging hardware, iirc it's software only. I've never heard complaints, but hobbyists aren't usually aware of commercial debugging equipment and software suites that people like Microchip and TI offer for their MCUs. I want to be able to see state for every instruction. Microchip has a generic simulation tool for each MCU series, so it's not perfect but it's so nice and fast to build with.

I think Simulation is an anathema in the hobbyist world. The question is do you want to simulate the arm cortex, the micropython environment, or those PIOs? In short, no, I'm not aware of anything like what microchip offers for the Pico .

HAHAHA unfortunate :/ I want write C/assembly and step through it. I want to see CPU, Memory, I/O, DMA and all that fun stuff while stepping through the code. It's just so much easier than hardware debuggers and then learning the debugging hardware/instructions and errata. I mean it has to be done, but when writing like OS's and stuff that's a massive pain to debug and test correctly. Now I'm curious how professional firmware and automated tests work :/

Well, qemu can do this. Qemu and gdb will let get pretty close. But, I'm sure you are aware of qemu. The issue is for hardware integration you have to write the qemu drivers. Now, in HDL you can do this exactly. You can simulate every clock cycle exactly as you say. Vivado can do this. It can do this quite well for a microblaze or small riscv. But it would be intense for anything more complex.

Vivado brings back pure nightmares XD Man I haven't used it since senior year, then my edu license expired and I was like yeah I'm good. I very lightly dabbled with the Lattice tools and realized they had far better UX > Well, qemu can do this. Qemu and gdb will let get pretty close. But, I'm sure you are aware of qemu. Have heard, but never done!

Ghidra is good for reverse engineering, not so much forward. Oh ok, yeah I think you'd like qemu and gdb. For supported microcontroller (popular ones) even the hardware is modeled nicely. Assembly writing and debugging is not a problem. The issue is, if you chip is supported in qemu.