Project Logs

Collapse

• Connectors

  deʃhipu • 09/23/2023 at 08:12 • 0 comments

  If I we can't have them solder the display on the PCB for us, and have to get it separately, maybe we can at least skip the soldering step by using an FPC connector. This way you just have to stick the display in the, insert it into the connector and you are done. The Nokia display has a 12-pin FPC ribbon, with 0.6mm pitch. Looking through LCSC, there are no 12-pin connectors in that pitch, but there is a 13-pin one. A bit of a weird number, but maybe we can shift the ribbon to one side and still use it. So I ordered it to see how it will work mechanically. Three weeks later it arrived, and I have to say I didn't expect this:

  A bit small, isn't it? You see, it does have 13 pins, but six of them are on the bottom, while seven are on the top side of the ribbon, alternating. That does explain why all those connectors have an odd number of pins.

  But that means we need either a 23 or 25 pin connector, depending on whether the contacts are on top or bottom. A search through LCSC reveals that the 25 pin connector has been discontinued, so that leaves us with the 23-pin one. No problem, we can manage that by threading the FPC ribbon through a hole in the PCB without bending, and having the connector on the other side.

  There is only one more problem left. That connector costs $0.50 a piece – it doesn't seem like that much until you realize it's half the price of the display. Ooof. I will keep exploring the possibilities.

• Never Be Clever for the Sake of Being Clever

  deʃhipu • 09/01/2023 at 18:27 • 0 comments

  A bunch of sleepless nights, and I have designed a version of PewPew with that ST7735 display from LCSC in EasyEDA, to see how that single-click assembly thing would work for it. I was very careful to use the parts from the basic parts list as much as possible, so as to not incur extra costs for loading new parts into the PnP machines. It looks like this:

  Of course all the parts are on the back, including the long row of parts that is the power supply, including the LDO regulator for handling the USB 5V, and a boost converter for the battery. Unfortunately I didn't take a screenshot of the finished board from the back, so here it is without the boost circuit.

  There is also plenty of space for documenting the pins and adding whatever PCB art I decide on, but for a prototype that is enough. So I clicked the magical one-click button, did all the additional clicks to generate the BOM and PNP files that for some reason the one-click button doesn't handle, and was presented for a quote for assembling 5 units: a little bit over $50. And that is without the SAMD21, which happens to have a "shortfall", and without the display, that doesn't even appear in the parts search, despite the fact that you can find it on LCSC without problems. Add to this the shipping costs and the missing parts (which happen to be the two most expensive ones), and you can easily expect $20 a piece. That's not what I expected, so I looked closely at the breakdown of fees, and turns out I'd have to pay extra $25 "setup fee" for the fact that the PCB is 0.6mm thick instead of the regular 1.6mm thickness. It would also have to be green, because all other colors in that thickness are ridiculously expensive.
  

  In hindsight, this isn't surprising. If they have to change the settings of the whole production line just to churn out those 5 boards, it's going to take time and work from their engineers. The good thing is that it's a one-time fee, so it would have much less of an impact on the final price if I ordered, say, 100 units. But I want people to be able to order just a dozen units for a workshop, so this is definitely sub-optimal.

  What can I do? What if I stopped trying to be clever with the battery holder and the USB socket, and used regular parts like everyone else, and regular thickness of the PCB? Those parts cost literal cents, after all. Let's see:

  I also simplified the board outline, while I was at it, in the vain hope that it would make the previews on the JLCPCB website work, but it didn't. I guess their engineers are busy with other things. In any case, this time it was just around $30 for 5 units, which sounds much more reasonable, until you remember that the boards are missing the two most expensive and hardest to solder parts, the MCU and the display. And this time the largest fee is the "extra components" fee, for using parts that aren't the basic parts list. Because while the USB socket and battery holder indeed only cost cents, they are not "basic parts", so you pay an additional fee (much higher than the price of the part) just for loading them into the PnP. I feel like I can't win this.

  So the plan right now is to focus on the other problem I have identified in the previous log, maybe get a new revision of the nokia display prototype into EasyEDA if I can't sleep again, and try to see if some fab would be interested to carry those boards in their shop. Because the only way to get them cheap is to make a lot of them at once. But that will have to wait until the SAMD21 is back in stock.

• What Remains to be Done

  deʃhipu • 08/28/2023 at 22:12 • 0 comments

  I had a bit of a break on this project, caused both by my lack of motivation, and by the chip shortage, meaning you couldn't get any SAMD21 chips (or anything that could easily replace them) anywhere. The shortage is apparently ending this September, and I have also recovered some strength, so I can think about the project again.

  The time that passed wasn't entirely wasted. I got to test the device in different conditions, with different computers, different programs and different batteries, and I have discovered at least two serious problems that require my attention, and that could lead to an increase of the price of the device.

  The first problem wasn't immediately apparent with the simple games I tested the device with, mostly because they check for button presses pretty often. But not all programs written for PewPew devices do that, and the less frequently they check for the presses, the worse the touch buttons on the device work. You see, originally the pew library would use the same interrupt it used to refresh the LED matrix to also check for button presses, so the checks were very frequent and were happening in the background. When it was ported to other devices, it used the keypad library to also keep checking the presses in the background at a high rate, and processed the resulting events when the game asked button presses. But there is currently no keypad library for touch pads in CircuitPython, or any other way of checking for touch in the background. So the pew library for this device only checks the pads for touches when the game asks it. And that means that if the game doesn't ask often enough, some touches will be missed. And that results in an unreliable and laggy feel of the games on this device. It simply is not pleasant to use it. We can't allow that.

  I can think of two ways of solving this problem. The first is to fix it in software and write a library similar to keypad, but for touch. This requires some datasheet diving to be done right, without slowing the code running in the foreground on the device. I'm not entirely sure I can do it, but I will try. I can think of two ways of doing it, the harder, with interrupts, and the easier, with the system tick. If I don't manage to write such a library, the only other solution I can think of is to add back physical buttons to the device. It would increase the price, yes, but it would also immediately solve the problem, as I could then again use the keypad library, and it would provide the users with tactile feedback, further increasing the pleasure from using the device. Plus, buttons are really not that expensive, even the nice ones.

  The second problem has to do with batteries. You see, the kind of coin batteries that this device uses are not the same all over the world. When I designed the prototype, I tested it with batteries I bought in Switzerland, and they had no problem driving the display and the microcontroller. However, when I went to a conference to UK, and bought some batteries there, they proved to be too weak to even start the device. I can only assume that regulations in different countries require different power from the same type of the battery, and naturally batteries destined to different markets differ in quality.

  Again, there are several ways I could solve this problem. I could switch back to two AAA cells, instead of a coin battery. I could require a thicker (and more expensive) variant of the coin battery I'm using, or even a bigger (and harder to obtain) one. I could remove the battery slot entirely and say that the device should be connected to USB for use – after all, that's how it would be used during the workshop, which is the main target for it. But a simple boost converter circuit would work too, and it would also make it run on the same battery longer, draining it more completely before failure. What's more important, it would feed the device a consistent voltage as long as the battery had enough juice left in it. And there are ready boost...

  Read more »

• The Challenge

  deʃhipu • 10/16/2022 at 15:24 • 0 comments

  This project was submitted to the 2022 Hackaday Prize, and it qualified to semifinals, so let me take some time and talk about the challenge that I am trying to tackle with it.

  Of course, the theme of the round was re-using existing parts, so that they serve a purpose instead of ending up in a landfill, and that is of course an important thing. In case of this project, the part being reused is the display, which used to be produced for a number of very popular phones, and which is still available as replacement part for them, even though those phones are not nearly as popular as they used to be. It's a dated technology, which has long been replaced with OLED screens, but which still has some indisputable advantages, such as very low power consumption, and is more than adequate for this particular use case. So yes, we are re-using a part that would otherwise just pollute our world. Good. I also made some other conscious decisions about what to use, such as settling on a battery type that is practically, in reality, recycled, or a USB connector that works with older hardware.

  But the main goal of this project is not related to protecting the environment, a worthy goal that it is, but rather it looks forward into the future a little bit further, to give a better chance of saving the world to those who come after us. Technical culture is a big thing. You either understand the tools that you use and control them, or they control you. With the tools around us getting more powerful and ubiquitous, and with them having increasing effect on our everyday lives, it's more important than ever to understand and control them. But it is also becoming increasingly harder to do that, as they become more complex, harder to inspect and repair, and more dependent on centralized services. If our successors are going to learn this, they need a stepping stone, something that is easier to understand and learn from, something they can own and control. I hope this project to be that. Or one of such things, anyways, for I hope there will be many more. 

  Obviously they also need teachers and the materials to learn from, but while I do some teaching myself, I'm not an organizer and there is little I can do about encouraging people to teach and write books. What I can do is to give them tools that will make the teaching easier and less challenging. I can design a device that is not only useful in the teaching, but also not tied to any large corporation or government, and not dependent on their sponsorship, like the Raspberry Pi or Micro:bit projects are. Something that is cheap and easy to get because it was designed to be cheap and easy to source, not because someone poured a ton of money into it to subsidize it, and can at any moment change their mind. Something that is truly open source, without any binary blobs or secret sauce, without a trademark or a patent, without strings attached.

  It's not ideal. While the screen is recycled and the battery is recyclable, the microcontroller itself is new, and affected by the global chip shortage at the moment. Using any other chip would make this project more complex and more expensive, and possibly also tie it to one of the organizations that could control it. It was a trade-off. Perhaps in the future there will be a chip that better fits the goals of this project – one that is more open, or that can be recycled from old hardware, while not adding a lot of complexity. But I currently don't see anything like this, and I believe that it's better to make something imperfect now, than to wait for perfection forever. We are not getting any younger.

  I also hope that in the future there will be many more PewPew-compatible devices. The pew library is already ported to pretty much any homebrew console that runs CircuitPython, and some platforms that run regular Python. As new devices are designed, PewPew can be ported to them as well. So maybe you will not need to produce new devices for a workshop anymore, because everyone...

  Read more »

• PewPew Around the World

  deʃhipu • 10/13/2022 at 19:06 • 0 comments

  PewPew is not just the device. It's being used around the world. People make PewPew-compatible devices, such as Christian Walther's PicoPew, they write new games for it, and even publish them online, such as Łukasz and Stanley Langa's DDRez, and most importantly, they run workshops with them, such as the most recent Cheuk Ting Ho's workshop at PyCon Ghana.

  I hope that now with this even cheaper and improved device it will become even more useful for all kinds of educators, from self-taught amateurs, through volunteers, to professional teachers. Of course the most important thing for this to happen is documentation, so that's what most focus will now be on going forward. The hardware seems good enough for now, and the software can use some small improvements still, but is basically usable, but you can never have enough documentation.

• Swiss Python Summit 2022

  deʃhipu • 09/29/2022 at 22:39 • 0 comments

  I was speaking about the PewPew devices, among other things, at this year's Swiss Python Summit, and there is now recording of my talk available. I tried to do some live coding with the #Stage, a Tile and Sprite Engine, but ran out of time very quickly. Oh well, I should have done it with PewPew, it would be much quicker.

• EuroPython 2022

  deʃhipu • 07/19/2022 at 20:30 • 2 comments

  Last week I was in Dublin at the EuroPython conference, and we did a number of PewPew-related activities. There was a whole-day workshop with the #PewPew Standalone devices we had left over from 2019 — I think it mostly went well, except for some Mac users who only had USB-C ports on their computers, and no adapters. I think I will need to get some adapters or C-to-micro cables for the future workshops.

  A few more people played with the PewPews through the conference at the "maker fest" tables, and I also showed off the new PewPew LCD, which seems to be very well received. Then I gave a talk about making games with CircuitPython in general, and about all those handheld game consoles running CircuitPython — the talk wasn't very popular, but I hope that I got the people who came to see it interested in this.

  Finally, after the conference, during the sprints, we worked on some more PewPew games, and I also showed a few people how to contribute to CircuitPython itself. It was great fun.

  At the end of the conference, the organizers decided to give out all the left-over PewPew devices, so we will have a couple hundred more users afterwards! Huge thanks to the EuroPython organizers for making it all possible!

• Better Game Selection Menu

  deʃhipu • 06/29/2022 at 19:45 • 0 comments

  The original #PewPew FeatherWing and #PewPew Standalone only have 8x8 LED displays, so the menu for selecting games amounted to the name of the currently chosen game scrolling on that display horizontally, while up and down buttons would switch to the previous or next game on the list, with a nifty animation. I initially used the same program as the menu for the PewPew LCD, but there is a huge problem with it: that LCD screen is not made for fast scrolling:

  All you get is a smudge, because the pixels don't change fast enough to support this animation. But not a problem, after all with all those pixels we can have a proper menu, similar to that on the #PewPew M4 — with multiple items displayed, and an arrow to choose one of them.

  I've been meaning to write that menu program for a while now, but my day job and life in general kept getting in the way. Today I finally decided to just sit down and do it, and I'm pretty happy with the result so far:

  There are several tricks in here. I used the terminalio library of CircuitPython to use the same text terminal as the REPL uses, but I re-created the TileGrid and the root group to make it all two times bigger — the tiny font is good for printing the errors, because the whole traceback fits on the screen, but it was really too small to comfortably select a game title. For now I'm just using text ">>" for the arrow, but since I re-created the root group, there is nothing stopping me from adding a sprite of a pointing hand in there. I also still need to add scrolling, for the case when there are more than six items to choose from, and perhaps some kind of display for the battery voltage would be nice? In any case, I have the basics functional, so that's a start.

  Oh, and the code is not complex at all:

  import os
  import pew
  import supervisor
  import board
  import displayio
  import terminalio
  
  
  def wait_keys():
      try:
          while True:
              keys = pew.keys()
              if keys:
                  break
          for i in range(5):
              if not pew.keys():
                  break
              pew.tick(0.0625)
          else:
              keys = pew.keys()
      except pew.GameOver:
          keys = 0
      return keys
  
  
  def menu(terminal, items):
      terminal.write("\x1b[2J")
      for item in items[:6]:
          terminal.write("  %s\r\n" % item[:10])
      selected = 0
      total = min(6, len(items)) - 1
      while True:
          terminal.write("\x1b[%d;1H>>" % (selected + 1))
          pew.tick(0.125)
          keys = wait_keys()
          terminal.write("\x1b[%d;1H  " % (selected + 1))
          if keys & pew.K_UP and selected > 0:
              selected -= 1
          if keys & pew.K_DOWN and selected < total:
              selected += 1
          if keys & pew.K_O:
              terminal.write("\x1b[2J")
              return items[selected]
  
  pew.init()
  grid = board.DISPLAY.root_group[0]
  grid = displayio.TileGrid(grid.bitmap, pixel_shader=grid.pixel_shader,
      tile_width = grid.tile_width, tile_height=grid.tile_height,
      width = 12, height = 6)
  screen = displayio.Group()
  screen.scale = 2
  screen.append(grid)
  board.DISPLAY.show(screen)
  terminal = terminalio.Terminal(grid, terminalio.FONT)
  files = [name[:-3] for name in os.listdir()
           if name.endswith('.py') and name != 'main.py']
  game = menu(terminal, files)
  supervisor.set_next_code_file("%s.py" % game, reload_on_success=True)
  supervisor.reload()

• A Workshop

  deʃhipu • 06/19/2022 at 10:01 • 0 comments

  There have been no updates for a while, but that doesn't mean the project is done. There is still a lot of documentation and other materials to be written and I really need a better program for the game selection menu. But it's not as easy work as physically building something, so it takes longer. I'm hoping to do some of it as part of preparations for workshops.

  I'm going to be running a workshop this year at Europython in Dublin, using the PewPew badges from 2019 (sadly, chip shortage doesn't allow us to use newer versions, but luckily there were some badges left over in storage, so we can use that). Apart from the workshop, there are also going to be tables for makers available throughout the conference, and I'm sure I will be spending a lot of time there, so if you are around and interested in PewPew, drop in.

  There are also going to be sprints at the end, and I hope we can get some CircuitPython development done on them.

• Power Switch

  deʃhipu • 06/01/2022 at 22:19 • 0 comments

  Today I had a bit of a discussion about the design of this device, and I realized that I have written here about removing various components to slim down the design and lower the costs, but I never really wrote about why I didn't remove the power switch, even though I could do it, with some compromises.

  But first let me explain what the power switch actually does here. On most normal electronic devices, the power switch would be labeled "on" and "off", but in here, just like on the #PewPew M4, the labels say "bat" and "usb". What does it mean? This is because it's not really a switch that switches the power on or off, it's a switch that switches between two power sources: the battery and the USB socket. Of course, when the device is not connected to the computer, switching it to "usb" effectively switches the device off. When it's connected, you can't really switch it off, because switching it to "bat" will just make it run on battery power (even though it's still connected to the computer, it will use up the battery then).
  

  This a bit quaint setup actually lets me avoid a lot of complexity. Normally, a device that can be powered both from battery and from USB has to, at the very least, protect those two power sources from each other — either using some low-voltage-drop diodes, a "perfect diode" circuit, or some kind of power management chip. This of course adds to the complexity,  and in case of the simple diodes, wastes some of the energy from the battery. A simple mechanical switch can easily make sure that the two power sources never touch.

  But what about removing the power switch? It could be done if I decided to also drop one of the two possible power sources. In fact, I did just that in the #PewPew Slim, which can only be powered from USB, since being a business card, it's too thin for a battery.

  I could also go the other way, and remove the USB power option. This would not only let me remove the power switch, but also the 3.3V LDO that converts the 5V from USB to a voltage the device needs. The early versions of #PewPew Standalone were like that, even though they had the switch for cutting the battery, they didn't work with USB power.  Later I added the LDO, because testing on living humans during actual workshops proved that it's really needed for this particular use case. But if it wasn't, I could drop the switch too, and since CircuitPython has now deep sleep support, and you can wake up SAMD21 from deep sleep on a touch event, I could make it simply wake up when any of the touchpads are pressed, and go to deep sleep (also disabling the display) if they are not pressed for some time.

  In the end the switch turns out to be an optimization that lets me use both power sources without needing additional components for power management.

View all 26 project logs