PewPew LCD

Learn Python programming with an affordable gaming handheld.

Similar projects worth following

Teaching programming is hard. And it's not made any easier by the fact that before you even start teaching, you have to first do the ungrateful job of an IT support worker and get your students through all the hoops of installing all the necessary software and libraries on their computers. And when you finish, the programs they have written only works on their own computers, unless they go through all the same (and possibly some additional) hoops.

The PewPew family of devices is one possible answer to this. They are designed with one main goal in mind – to remove as many obstacles between your students and the game they want to create, as possible. To achieve that goal, the device itself has Python running on it – a version of Python designed for microcontrollers, called CircuitPython – so all you have to do is edit the files on it, using any text editor, to write your programs. As soon as you save, the device restarts and runs your code. In addition, if you want to show your game to other people, or enjoy it on the bus, you can simply put it into your pocket.

This is one of many devices in the family – I started with #PewPew FeatherWing and as I tried it in different workshops, I refined the design with #PewPew Standalone, #PewPew M4, #PewPew Slim, #PewPew S2 and  #PewPew OLED. So far the standalone version has been the most successful, being simple and affordable, but later experimenting showed me that there is room for improvement.

This time I want to design a device that is even simpler and cheaper than any previous one, while at the same time being more convenient to use, and maybe helping us find a use for some of the old electronic spare parts that lie around.


datasheet for the display

Adobe Portable Document Format - 783.72 kB - 05/24/2022 at 20:36


  • Talk to the Display

    deʃhipu2 days ago 0 comments

    While I wait for the PCBs to arrive (they are apparently already on their way, and should be here next week), let's talk a little bit about how the communication with the display actually happens. I already mentioned that it uses 9-bit SPI protocol, and that means that each time a byte is sent to the display, it's prefixed by an additional bit that tells it whether it should be treated as data or as a command. But what are those commands and in what format is that data precisely?

    We can learn all about that from the datasheet for the STE2007 chip (PDF) that is used in that display. For those who have already some experience with OLED displays, it's very similar to the popular SH1106 chip. In fact, in displayio we use the SH1106_ADDRESSING flag for it!

    Let's start with the commands. Table 18 of the datasheet details all of them, but we will only need to use a few. Right after powering on, the display is inactive — we need to send it some initialization commands to make it work. Those commands are as follows:

    E2 reset
    2F power on
    A4 display normal
    AF display on

    First, we do a software reset, just to make sure we get a clean slate. This is theoretically not necessary, but there could always be some glitches on the communication lines during power on, which could potentially send some random commands to the display, and it doesn't really cost us anything to be careful (we do a hardware reset with a pin anyways).

    The next command switches on the internal power for the liquid crystal. The chip contains all the necessary circuits to provide just the right voltage for this particular liquid crystal panel, but it's off by default (because there is also the option of providing that voltage from outside), so to get anything displayed, we need to switch it on first.

    Next, we switch the display into the "normal" mode, as opposed to "inverted", where all the pixels are negative, "all off", and "all on", which are used for testing. The normal mode is when a 1 in the chip's memory gets translated to a black pixel.

    Finally, we send a command that actually makes the driver chip start sending the pixel data to the liquid crystal panel — this is separate from the power on, since if we provided external power, we would still want to do the display on command without doing the power on command.

    After sending those four commands, the display will start showing the contents of the chip's memory — initially it's just random pixels.

    Next, we will need to send the data to be saved in that memory, and for this we need to understand how that data is arranged. We can visualize it roughly like this:

    Since the display is monochrome, each pixel is represented by a single bit of memory. So a byte represents a set of eight pixels. In this case, it's a vertical line of eight pixels, as you can see on the image above — each of the colored "ladders" is one such set of eight pixels, or one byte in memory.

    Furthermore, those bytes are arranged in what the datasheet calls "pages", and what we would probably call rows. Since the display is 96x68, we will have 9 rows of 96 bytes each (the last row is only partially visible). We select the row with the "page address set" command, which is actually 16 different commands, one for each page (there is a bit of redundancy there), from B0 to BF. The chip actually has more memory than fits the screen, and that can be used for vertical scrolling using the "start line address set" command 40-7F, but we are not using it in this case.

    Each time we send a byte of data, it's getting saved to the current page, and then the "cursor" is advanced by one horizontal position. This means we can simply just stream 96 bytes for a row. Then we need to switch to the next page, and stream the next 96 bytes. If we didn't need to update the whole width of the display, though, we can also move the cursor horizontally using the "column address set" commands — there are two sets, 10-17 for the top three bits of the address, and 00-0F for the lower 4 bits....

    Read more »

  • Why not Recycle Everything?

    deʃhipu05/17/2022 at 12:05 0 comments

    With both the screen and the battery being chosen with their impact on environment in mind, you are probably wondering what about the remaining components, especially the microcontroller?

    The quick answer to that is that the chip shortage has cleared any old micrcontrollers from the warehouses quite well already, so there isn't really much surplus we could draw on here.

    The more detailed answer is that the main and overriding goal of this project is to remove as many obstacles between you and the game you are going to write, as possible, and the older microcontrollers simply don't have the resources, in terms of memory and speed, to run a Python interpreter. They often don't even have native USB peripheral on them, which means you would have to muck about installing toolchains, compiling your programs, and using special dongles and programs to flash them onto the device. This is simply unacceptable.

    As for the other components, they are really generic, and you could easily use recycled ones if you are building this by hand. But for producing hundreds of the devices, the additional effort in hand-placing them and doing quality checks to make sure they work, with added risk that they might stop working at any time anyways, is simply not worth it.

    So we will have this mixture of old and new technology — ancient screen with a advanced microcontroller, traditional battery with a modern voltage regulator, generic switch with new capacitors.

    Oh, and I also looked into using paper PCBs, but it seems the technology is not quite there yet.

  • Version 2.1

    deʃhipu05/14/2022 at 09:53 0 comments

    Today I couldn't sleep, so I did what I do when I can't sleep: designed a PCB. As I previously mentioned, version 2.0 is very close to what I want, but there were some small details I wanted corrected. Those changes are not really enough to warrant a whole new version, and I'm not going to do a new certification for it.

    I removed the unused resistor footprint, and moved the capacitors away from pads, so that they don't get in the way. I centered the display, so it will now fit the outline properly. I moved around the traces for the touch pads, so that you are less likely to touch a trace and activate a touchpad when you didn't mean to. I removed the doodles to make it look a bit cleaner, and on the back I added a place to sign the device, to make it more personalized. I also covered the expansion connector pads with soldermask, so you are less likely to touch exposed solder with your fingers.

    I will order the PCBs from @Elecrow once again, and I will publish the design files once I have tested and verified that they work.

  • CircuitPython

    deʃhipu05/13/2022 at 18:44 0 comments

    The board definition and code is now merged into the CircuitPython project, and both the bootloader and the firmware can be downloaded from (or rather, the firmware will appear here as soon as there is a release). Thank you to the CircuitPython developers for reviewing and merging it so fast.

  • Dithering About

    deʃhipu05/13/2022 at 09:21 0 comments

    It's time to look a little bit closer at the software. The display has resolution of 96x68, and I need to display a grid of 8x8 pixels in four shades on it. A quick calculation tells me I can have blocks of 12x8.5 pixels. Of course that's wrong, because I can use half of a pixel, and that block would be very much not square. But I don't have to use the whole screen. With 8x8 blocks, I use 64x64 area in the middle — the blocks are square, but the empty area on the sides looks bad. By experimenting I settled on 10x8 blocks — this is stretched enough to only leave 8 unused pixels on each side, but not as bad as to make the blocks visibly flat.

    Next, I needed to figure out the best patterns for dithering those blocks. Of course the 100% and the 0% ones are easy, the ones in the middle though require some thought. Theoretically, they should be around 33% and 66% to give an uniform distribution, but there is no good way of arranging the pixels in the block without creating obvious patterns like that. Even if we make it 9x8 instead of 10x8, to be divisible by 3.

    So as you can see in the image above, I initially went with 25% and 75% dithering. They are pretty uniform, and one is just a negative of the other, so the look is very consistent. However, I still wasn't happy with how the dark grey looked almost like black. So finally I settled on 25% and 50%, to make the blocks easier to tell apart:

    I'm pretty happy with how that turned out.

    By the way, it was suggested I could try PWM-ing the pixels, to get my shades of grey without dithering, but since this is an SPI display, I don't really control every frame of the image, and keeping consistent timing would have been hard. It would also require constant updating, taking away microcontroller time from the user's program, and making it slower.

  • On Batteries

    deʃhipu05/12/2022 at 08:36 0 comments

    If we are talking about the environment, then let's talk about the only consumable part of this device: the battery (by "consumable" I mean it needs to be replaced once in a while, please don't eat batteries).

    The very first PewPew FeatherWing used a lithium-polymer rechargeable battery, simply because all Feathers use such batteries. I didn't think much about it back then, and I didn't have a clear use case in mind at the time, I just went with what was the default on the platform.

    Starting with PewPew Standalone, all devices use primary cell batteries — that is, non-rechargeable. Why? Surely rechargeable batteries must be much better for the environment, since you get to reuse them, and primary cells are just thrown away when they are spent? It's not that simple, and you have to consider how the device is used.

    PewPews are designed for workshops. That means that you are most likely going to receive your device on a workshop, use it intensively for a couple of hours, then take it home with you, maybe carry it around for a few days to show to your friends, and then put it in a drawer and forget about it for a couple of years. Hopefully, once in a while you will find it again, resurrect it and have some fun with it again, or give it away to the neighbor's kid to play, at which points the whole story repeats. You might also incorporate it as a control panel in some bigger project, at which point it will be probably powered from that project.

    In any case, if you think about the power profile of such use, it's exactly what kills rechargeable batteries. They are good for things you use all the time and keep charged, like smartphones or laptops (through they don't like to be topped up all the time), and lying for years without a charge in a drawer is really bad for them — to the point where they can burst in fire when you try to charge them afterwards. So you would have to replace them anyways, but replacing such — usually somewhat non-standard — batteries is not as easy as buying a pack of batteries in a nearby kiosk.

    With primary cells you don't care — they will get you through the initial intensive use, and when you find the device in your drawer years later, you will just clean whatever spilled from them and replace them with standard cells that are cheap and widely available.

    The second problem this solves is transportation. The workshops are likely to happen some distance from where the devices were first produced, and getting them there might involve shipping or flying. Both of those means of transportation have rules about lithium-polymer batteries, and if you want to take 20 of such batteries with you, there might be some problems with that. With primary cells this is not a problem — you ship them without the batteries (which also makes them lighter and the shipping costs lower), and buy the batteries when you get there. Easy. This way you are also reasonably sure the batteries are fresh and were stored properly.

    And third problem is recycling. You might think that primary batteries are bad for the environment, because when they run out you throw them in the trash. However, where I live that is illegal, and I firmly believe it should be illegal everywhere (and we are getting there, with laws slowly changing to cover that). Primary cells — mostly alkaline and coin cell batteries — are collected and recycled. And they really are getting recycled, unlike the lithium-polymer batteries, which are only collected, since recycling them is not economically viable.

    How come, you ask? Well, the alkaline and coin cell batteries have been around for a while, without much of a change to their construction or chemistry. Sure, the manufacturers are trying to improve the production process and raise the quality, but those designs are practically stable by now — there is very little changing, if at all. This means there was also time to develop efficient procedures for recycling the batteries, and recovering the valuable chemicals...

    Read more »

  • Published

    deʃhipu05/10/2022 at 12:14 0 comments

    With the second version being pretty much where I wanted it, I decided to go ahead, publish all the designs and code, and once I had done that, apply for the open source hardware certification.

    The PewPew LCD is now officially certified open source hardware, with number CH000013.

    I also submitted a pull request to include the board definition in CircuitPython, but before that, I had to apply for USB VID/PID numbers.

    Once that is merged, I will need to add the board to

  • Version Two

    deʃhipu05/10/2022 at 11:28 4 comments

    With an embarrassing failure that was the first PCB behind me, I went ahead and fixed the design somewhat:

    The flex connector for the display is now outside the display's outline, the microontroller had to be moved, the USB is now flipped to correct orientation. I ordered this time at @Elecrow because they had more choice of colors for the 0.6mm thick PCBs, and the quality seems to be better. A month later I had the first working prototype in my hand:

    I adapted the software I used previously on the #PewPew OLED – the displays are pretty similar in how they handle pixels. One problem I encountered is that while the driver chip has the commands to flip the display 180°, and the breakout module I used to test them worked fine, the cheap displays I got for the device ignore those commands – I'm guessing they don't actually use the same driver chip, but some cheaper alternative.

    Fortunately this wasn't a huge problem, because displayio can rotate the display in software, and my own driver code can easily just output the pages in reverse order.

    Mechanically there are a few small nits to pick in the design, but that is not going to change anything electrically. I discovered that I don't need the backlight resistor – you can see a solder blob in its place on the photo. The display itself is a little bit shifted to one side, about one millimeter – I will need to correct that. I will probably also change the way the traces go to the d-pad pads, so that it's harder to touch the traces instead of the pads. Finally, I'm thinking about adding some holes under the display to make it easier to glue it to the PCB. All of those are minor adjustments, though.

  • Environmental Cost of Displays

    deʃhipu05/10/2022 at 09:47 0 comments

    While reusing old displays wasn't initially the goal of this project, the goal of making it affordable lead straight in that direction, and then the Hackaday Prize came along with this category, so I thought why not submit it.

    But while no lone hacker is going to save the planet with our toys, we can at least help somewhat by raising the awareness of the environmental effects of the technology we are using. So I went and tried to do some research about how bad the displays actually are for the environment.

    On the surface of it, the impact seems negligible. It's mostly glass, silicon, some mild chemicals for the liquid crystals, some metals for the contacts, plastic for the case. But it turns out that most thin displays, whether they are LCDs, OLED, plasma, TFT, IPS or e-ink, share one thing with thin-film photovoltaic cells that makes them horrible for the planet: transparent electrodes. Of course you need transparent electrodes to bring electricity to all those pixels, if you want to also be able to see the pixels. Such electrodes are usually made of silicon, just like in chips, and to get the right shapes, they are etched in similar way that you etch copper on the PCBs. Except the best chemical for etching silicon is nitrogen trifluoride.

    What is nitrogen trifluoride? It seems pretty harmless. It's colorless, non-flammable gas with pretty low toxicity. Easy to handle, pretty safe. However, it's an extremely potent greenhouse gas. How potent? 17200 times more potent than carbon dioxide. That's 17 thousands. Oof! It stays in the atmosphere for an estimated 740 years. And its concentration in the air is growing steadily at about 11% increase per year, as of 2011.

    So yeah, let's see if we can reuse those displays we already have, and maybe rethink those solar panels a bit too.

  • First Hardware

    deʃhipu05/10/2022 at 09:09 0 comments

    In the mean time, the PCBs that I designed for this arrived from @JLCPCB and I could assemble the first prototype. I can only give you one advice here: don't design PCBs while sick and with fever. Everything went wrong.

    The display footprint had to be custom of course, and I designed it the same way it was done on the breakout I tested with – assuming the flex connector will be folded under the display and soldered there. Well, turns out the really cheap displays I got are a bit cheaper than the one on the breakout, and the flex connector only has metal contact on one side. The wrong side, of course. So I will need to redesign it to move the contacts outside of the display outline.

    Fine, so I will need to make a second version for the display connector, but what about the rest of the device? Well, the rest wasn't very good either. I simply couldn't get the chip to program. After several hours of struggles, and some smoke coming out of the voltage regulator, I finally realized that I had the USB connector mirrored. It probably happened when I moved it to the other side of the board. Sadly, I burned one of the SAMD21 chips I had, and that's painful considering we have chip shortage and the next opportunity to buy more will be in a year from now.

    At least the physical shape of the PCB is good. The battery connector works great, the expansion header retains a male pin header inserted into it just fine, the touch pads are in the right places and the USB socket fits the plug.

View all 13 project logs

Enjoy this project?



Dmitry wrote 05/18/2022 at 17:55 point

Well done, shows your high professional level

  Are you sure? yes | no

Tillo wrote 05/10/2022 at 05:20 point

I saw you went down the car industry route of cost optimization here.

  Are you sure? yes | no

deʃhipu wrote 05/10/2022 at 07:47 point

I really don't want this to be a toy for the rich kids, so some decisions had to be made.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates