• Why I'm no longer using the "universal screen" system

    Johnny Stene03/16/2021 at 02:24 0 comments

    Originally, I wanted the phone to be as modifiable as possible. As part of this, I wanted to have a system where the screen could be replaced with any type whatsoever. I had set up a system where you could have two completely different types of screen, and you'd be able to swap them while maintaining 100% compatibility without needing to recompile firmware. Unfortunately, the benefits just don't justify the cost of having this system. It slows down the display by quite a bit, and it adds unnecessary complexity to the phone, which makes it harder to repair and makes repairs cost more ($30 screen replacements vs $10, things like that) so I've just decided to scrap it.

    TL;DR: Old system of interfacing with screens was slow and expensive. Getting rid of it.

  • [TECHNICAL] Repairability, and Security

    Johnny Stene03/06/2021 at 04:00 0 comments

    I've been working on the later stages of the design, and have been trying to make the phone as repairable as possible. First, the major components are all modular - the screen, battery, CPU, and cellular modem are all on separate daughterboards that connect to the board with the keypad. This makes it so that repairs can be done in a matter of minutes with no soldering whatsoever. This also helps improve longevity because it lets you upgrade the phone down the line if you feel it no longer suits your needs. This doesn't mean much if it's hard to take apart, so I'm trying to find a design that's super straightforward to disassemble and reassemble.

    Also, I've been thinking of a tamper-evident boot process that's as painless for the user as possible, while making sure none of the data on the phone can be accessed if someone installs a malicious firmware. Essentially, the user can pick a picture to be displayed on boot. It is added to the firmware image, and can't be read back from the phone. If the image is different from one boot to the next, then the user knows something has been tampered with. I'm not sure if this will be helpful at all, or if I should try to make something a bit better, but that's something I'll have to think about before the final product is done.

  • Lessons I've learned from the first round of devkits

    Johnny Stene03/06/2021 at 03:48 0 comments

    I finally got everything I need for my first few devkits. I've learned a few things from making these, that will hopefully make the final product much better.


    1. Have a way of flashing the stock firmware onto the chips

    This seems like a no-brainer, but unfortunately I made the stupid mistake of not including an ICSP header for writing the bootloader to the CPU, so that has to be done with some thin wire on these ones. Oops.

    2. The easiest method may also be the cheapest

    The buttons I used LOOKED like they'd be the cheapest option to go with (they had a minimum amount of 1) but were WAY too much money in hindsight. I took a look at the buttons the software I'm using, and they would have saved me a dollar per devkit. Doesn't seem like a whole lot, but when I'm trying to build (and turn a profit on) a $75 device, every penny counts.

    3. Breaking things down into smaller pieces is actually really good advice

    I wasn't thinking a whole lot about what a phone really *needs* when I built these devkits. They can't charge batteries, they don't have actual cellular (but that one wasn't my fault!) and overall, they're basically what I already had, but in a nicer package. If I had sat down and thought about what every single part of a phone was for, I think I would've ended up with a better set of devkits.

  • [UPDATE] Custom PCBs designed!

    Johnny Stene02/15/2021 at 22:40 0 comments

    I've finished designing the first revision of the PCBs for the development units. This version doesn't have a cellular modem (since the DAC/ADC I'll be using isn't available as an EasyEDA library yet) but it does have a place to add one.

    Of course, the files are available at https://github.com/jhonnystene/PhonePCBs.



  • [UPDATE] More custom dev tools!

    Johnny Stene01/29/2021 at 22:06 0 comments

    One issue I'm having with designing the user interface is that testing it on-device and using a standard photo editor take too long. My solution: Another custom tool!

    This one's called UIDesigner, and does exactly what it says on the tin - creates minimalistic user interfaces in seconds.

    Currently, it's quite limited. You can't "snap" objects in place, so you just have to guess. You can't save your work unless you take a screenshot. On Linux, this isn't a huge issue since our screenshot tools are actually good, unlike SOME operating systems. Luckily for users of those, I'll be adding a proper export feature soon. It can also only do text, which is *almost* everything you need. I'm also going to be adding in lines, for designing menus.

    It's very easy to use. Click which text size you want, type in what you want it to say, and click where it goes. Made a mistake? Click the X in the lower left and then click the text object you want to delete.

    Of course, this is also FOSS - you can download it here.

  • (UPDATE) A custom tool for designing fonts

    Johnny Stene01/24/2021 at 21:03 0 comments

    I was having a bit of trouble with the process of actually making fonts. I have to draw them out (which, as an artistically challenged person, is already pretty hard) and then manually, bit by bit, translate them into the format that arcticOS uses. So, I spent a couple of hours writing FontDesigner - a new development tool specifically for designing fonts that work with arcticOS.

    It's admittedly pretty basic, and doesn't look very good. Luckily, a dev tool doesn't have to look good! It's pretty simple to use. In the top left hand corner, you have the current character in the font you're working on. Next to that is a button to save the font in the FontDesigner format, and a button to export it into the arcticOS format. Below that are two drawing spaces - one for the larger, 32x32 font, and one for the smaller, 16x16 font. The red ring around them should ideally be left blank as that's where the spacing between the letters is. You can hit the left and right arrow keys to move through the various characters in the font.

    It's written in Python, and is completely free and open source! You can download it on GitHub (here) and you'll need to download Python 3.7 and Pygame (how you do this depends on your OS, but it isn't difficult) before you can run it.

  • (UPDATE) Another big chunk rewritten + custom fonts!

    Johnny Stene01/18/2021 at 01:11 0 comments

    I decided that instead of a "generalist" OS and kernel, I want arcticOS to be specific to mobile devices. As such, I rewrote most of the UI code. I also got custom fonts working! The clock font is pretty hefty though, at 7 bytes per character - I'll shrink it soon(TM).

  • (UPDATE) A proper prototype!

    Johnny Stene01/10/2021 at 03:56 0 comments

    I finally have a proper prototype running the same (mostly) hardware that the final phone will be running on! The prototype doesn't have a cellular modem thanks to the lack of properly priced SIM7600 breakout boards, but the devkit will have a modem. This version does have a screen, a keypad, and both CPUs - one for processing and one for interfacing with the display. Sorry I had to post a video, Hackaday just throws errors when I try to upload pictures.

  • (TECHNICAL) The all-new multitasking watchdog!

    Johnny Stene01/09/2021 at 05:58 0 comments

    As part of the rewrite, I'm working on some improvements to the multitasking system in arcticOS. There are two main "threads" - the main thread runs the bulk of the code, and the second thread runs smaller sub-processes. The issue is that these sub-processes can't be interrupted - the only context switching is switching between the main and secondary threads. This means that you need to wait for all of them to finish running before the main thread can continue running. But what if a sub-process takes too long? That's where the new watchdog comes into play.

    If a task takes too long, the new watchdog will wait for it to finish, and then save the position in the process list. Then, it will skip the remaining sub-processes and drop back into the main thread to let it continue executing. The next time the second thread runs, the watchdog will skip to the task after the one that was causing the block, so the rest of the sub-processes can finish running. This lets the main thread get more CPU time in the event of slow processes in the secondary thread, therefore increasing system speed.


  • (UPDATE) Rewriting arcticOS

    Johnny Stene01/09/2021 at 01:39 0 comments

    I am in the middle of rewriting arcticOS. I'm doing this mostly because the existing code is a complete mess. The new code will have a few benefits, like better file organization and more modularity.