update #5 - 9-13-23
me working on this over the summer was a total fantasy. college applications are happening so there was no rest this
this project has been kind of dead, so i'm going to stop lying to myself and officially put it on hold for now. there is
i need to learn to make it a relaxing 10-minutes-at-a-time kind of project, which makes it unrealistic to work on during
the busiest time of my life so far.
in other news, the link on sckzor's smd reflow plate is now a dead link because it blew up in his basement. RIP to the
iron and cheap thermocouple glued onto it.
one day i'll finish this and it will be cool, but that day will not be for a while.
ok so exams are happening so of course to procrastinate i ended up getting a lot done on this project. i am in
the process of designing the pcb for printing and hopefully it will be done by the time school gets out,
letting me order it start of summer break. after that, assembly is straightforward and all changes are
i promise eventually i will finish this project
so i have finally gotten my shit together in terms of designing this pcb. i need to fully flesh out the
schematic of the entire box so i can determine my pcb's dimensions, but my electrical schematic isn't hard to
put together and after that the actual pcb design should fall into place fairly simply (i have no idea
if that is true or not). after that i order the parts, get the pcb printed and then put them together. i have
a heat gun hot enough to melt solder paste and so while i will not have a pretty solder reflow heat curve it
should do the job according to at least one guy's answer to an amazon question about solder paste. i was going
to completely copy my friend (sckzor's smd reflow plate) but i
figured that this will probably work just fine and worst case i find an old iron in a thrift store and
frankenstein it with a few thermocouples and an arduino so i can make a nice little reflow temperature curve.
anyways, this project isn't dead. hopefully it is done soon, although school might swoop down from the sky,
pluck my ambitions from my hands and carry them off to the land of mordor never to be seen again.
i have not done a ton on this in a while because other projects and school took precedence for a variety of
reasons. i have been doing a little research on how i'll need to wire up the ZIF connectors and i am actually
of soldering those. i am dogshit at soldering and do not own solder paste. maybe i can 3d print a stencil
my lack of forethought brought me to a sticky situation. i have 7 displays; i have killed 3 of my breakout
boards on accident (due to my own stupid error of breaking off the connector pads) and when i finally 3D
printed an enclosure for everything i discovered that a snowball had a better chance in hell than i did
fitting those 5 breakout boards anywhere smaller than a 6cm cube, which is horrible to look at and i do not
want this project to be visually inappealing. also, i don't want to have 3 dormant screens. the solution i
have come to to solve this problem is to design my own driver board for all 7 displays. this could horribly
backfire on me due to my complete lack of knowledge on designing PCBs, but you gotta start somewhere. this is
it for me. doing research on the process of printing those things, i was shocked at how dirt cheap you can get
them, but unfortunately shipping anything to canada has the effect of at least quadrupling the impact on your
wallet, so a $3 board ends up totalling at $25 when accounting for shipping.
regarding the software, it should be pretty simple. i have one little algorithmic problem to work out (which
is made difficult because arduinos don't have a built-in hardware clock (understandably)) so i do not have a
reliable way, as far as i know, to figure out the execution time of each run of the main loop. i want variable
framerates on each screen which relies on me being able to calculate the time between the last render and the
current to appropriately delay it. the whole reason i want variable framerates is this: with the 32kb of
memory on the nano, 2kb goes to dynamic memory, while the other 30kb goes to program memory. one frame takes
up 896 bytes. however, this number is just for one frame on one screen, meaning that the actual memory
footprint of a single frame is 6272 bytes. this leaves me with less than 5 frames... with zero program. the
program is a few kilobytes as well. realistically i can get 4 frames total which is kind of disappointing.
however, if i could make the back screen render a smaller frame set at a lower speed, it could use less memory
by virtue of having a smaller frame cycle while having an effect of distance, perhaps, compared to the closer
screens. this could also be flipped based on how many different graphics one screen needs to display. i know i
could just use the existing frame cycle and have it display less graphics, but i'd love to have the
flexibility of having different framerates to give more granular control over the system. the code for this
should add up to less than 200 bytes i hope, having minimal impact on the already slim number of frames
allowed by the hardware. updates will follow!
so this is a project i've been chipping away at for a few months now (11/21/22). back in june i invested 90%
of my project money into some transparent displays from crystalfontz
and am stacking them and controlling them individually to make layered images. this project is a lot of
firsts, really my first hardware project ever (besides toying around with 3 volt dc motors in elementary and
middle school). i've figured out a lot, but have a lot to learn.
since i have zero experience in designing circuits, i bought breakout boards to go with each of the screens.
this is a decision i regret but as i am an aware victim of the sunk-cost fallacy and refuse to design one and
throw out the boards. it would be a waste anyways. to save space in my planned 3d printed enclosure, i removed
the pins from the board to solder straight to the metal points, and killed 2 of the relevant pins on 2 of the
boards. i will probably revisit this project and print my own board. however, in the mean time i will make do
with only 6 screens.
i've also learned how to 3d model and print for this project, undoubtedly important skills to have for future
projects, including the wheelchair revamp. it's pretty fun, actually, but i think that fun might wear off
the software will be fun, but i haven't worked on it very much yet besides for the test rigs. it shouldn't be
too crazy, but i'm slightly worried about memory on my board (bootleg arduino nano) in regards to storing
bitmap graphics. i did not build the system with a storage expansion in mind, but it should be fine. probably
will have to forego my idea of having a little button to swap between preset graphics, unless i just want to
have a few very very small loops - i believe this board has 32KB of flash memory, some of which is consumed by
the bootloader... 1KB of which should be taken up by just one frame, which limits me to maybe 10 frames
depending on how compact i can write my code. unbelievable that people landed on the moon with just over twice
this amount of memory, and i may struggle to store a few frames of bitmap graphics in it. we will see.
however it ends up it will be a fun challenge as i have never had to work around hardware restrictions before.
lots of firsts this project!
speaking of the bootleg nano, it's an elegoo brand replica, and when finding the chip drivers i
discovered that the download page on their official website... points to a google drive folder. i find that
incredible, i guess there just aren't enough of people downloading the ATmega328P and CH340 chip drivers for
google to care. i thought that was pretty funny.
i'll update this page with ongoing progress!