Oddbean new post about | logout
 I am designing and planning to home-build my next phone. I think its the only way... 
 I'm listening?!? 
 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?
 
 12mm x 60mm x 110mm. Claimed 10 Ah, but I'll be happy with half.

Overkill, probable mistake, and dominates the form factor decisions, but I do miss my Nokia 3210's battery life :p 
 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 don't, I'm afraid! Data / software background, but I'm learning :) 
 Grrr, thank you! I'll keep looking. Something about fast dual core mcu with lots of memory is really appealing. I've never done multi core firmware before, which is why I purchased them! 
 @bitpunk.fm do you have any experience here? 
 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!  
 Maybe Ghidra too?? Haven't played with that in a while either.  
 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.