AND!XOR DC25 Badge

We're going bigger, better, more Bender.

Similar projects worth following
What: Bigger, better, more Bender
Why: Because you all liked our badge so much last year


  • Rigado BMD-300 SoC
  • Nordic NRF52, ARM Cortex M4F
  • Blast Processing
  • 512kb flash, 64kb ram
  • BLE 4.2
  • Integrated Antenna
  • 128x128 1.44” color LCD
  • 19 FPS video over 8 Mhz SPI bus (and maybe m0ar?)
  • Middle-Out Compression
  • 15X WS2812B LEDs AKA “Neopixel”
  • Tilt and Ambient light sensors
  • 30% better power management (so far 30mA draw during Bling mode)
  • Micro SD Card

Note: Prototype displayed has test points and soldered headers. The final version will not have test points or JTAG headers, but the footprint will exist. Also the actual components are subject to change by final production, equivalent functionality, but we may find improvements which require a swap (e.g. in our KS video we show APA102C Dotstar LEDs, and we decided to go with the NeoPixels instead).


WHO:: We are 5 dudes from California with backgrounds in HW and SW engineering. We enjoy building and hacking things for fun.

WHAT:: We built a hackable, open badge for use at DEFCON 25 in Las Vegas and any other conferences in the future. The badge also serves as a dev board for hardware developers of any experience level from novice to expert sorcerer.

WHY:: The purpose is to put some really awesome hardware around the necks of a bunch of hackers and see what they come up with. We hope to encourage others to make use of the badge and come back with their own flavor in years to come, AND to promote embedded development across the community.

HOW:: Pure internet science. We've developed algorithms which calculate the spin rate of cat quarks for generating our ssh keys at a rate of (P+9)/((# of blackberry users)^2), where P is the probability that a cat will leave a house when a door is opened for them.

WHERE:: Caesars Palace, Las Vegas

WHEN:: July 27th - July30th, 2017

EXTRAS:: We are spending our free time and money outside of our busy work schedules to develop this from 3 separate locations across California. So we are definitely open and encourage feedback, suggestions, and features to be added onto the badge. If you complain that there are not enough blinky's happening then you are welcome to build your own. Feel free to Leave your comments below if you have questions, concerns, comments, philosophical statements, haiku's, or send us a tweet...that works too.

Twitter:: Check out AND!XOR, our official twitter account on twitter for daily and often hourly updates of the badge process.

  • 1 × Rigado BMD-300 SOC based on Nordic nRF52 architecture
  • 1 × CrystalFontz LCD CFAF128128B-0145T
  • 1 × Buck Regulator PAM2301CAAB330
  • 1 × 4.7uH Inductor (REG) MLZ2012N4R7LT000
  • 26 × 100nF Caps (1xLCD, 2xSD, 6xdebounce) MF-CAP-0402-0.1uF

View all 14 components

  • Hack All The B00z3, Drink All The Things

    Hyr0n06/11/2017 at 06:38 0 comments

    So when the world presents you with an internet of useless hack them. I mean, we bring burner phones to DC anyway, so why put apps on those phones when your badge can do the work for you? Actually, this IoT booze is pretty damn cool. Medea Vodka has a bottle which is decorated with circuitry and an IoT Bluetooth controlled flexible PCB LED Matrix. You typically download their app and it allows you to scroll messages on the bottle. The Medea phone app allows you to connect to anyone's bottle, but you are only supposed to connect to and scroll messages to bottles you own. Great party item. In fact, you should buy one and bring it with you to Vegas. ;)

    We got some by just calling our local BevMo and special ordered it for just $32 (free shipping). Medea has a store locator too, but again, we've been successful going through BevMo and even seeing it at CostCo. The vodka isn't bad either, make some hacker mules or screwdrivers. We attribute our sudden lack of progress at times to having bottles of vodka all around the workshop.

    Integrating with these bottles was actually quite easy. At first we were capturing traffic with an Ubertooth and a Bluefruit BLE Sniffer, combing through the PCAPs in Wireshark to see how the thing talks. As it turns out, it didn't even require that. It uses an unencrypted iBeacon. Simply load up the hand dandy nRF Connect App and you can view all of the bluetooth characteristics and attributes.

    Turns out it has super sophisticated 4 factor authentication built in (the secret 4th factor of authentication, something you drink)....okay you just tell it you have a MEDEA Service UUID and you're in. So we authenticated with the device as the interface was designed.

    MEDEA_SERVICE_UUID{0xfb,0x34,0x9b,0x5f,0x80,0x00,0x00,0x80,0x00,0x10,0x00,0x00,0x00,0x00,0x00,0x00} /** Little endian **/

    Our code will have the details in it, but in general, if you ever find yourself developing an IoT device, authenticating purely based on the value of service UUID is a little like this:

    In fairness, this is transmitted in the clear and anyone can see it. And we only use it for bottles of Medea Vodka we own, which is why our function on the badge clearly lists which device you are connecting to and you dont make the mistake of connecting to someone else's bottle...(write down your MAC) More importantly, we are telling you to GO OUT AND BUY MEDEA VODKA CUZ THE BOTTLE IS F#*ING COOL AND THE BOOZ3 ACTUALLY TASTES GOOD. Now if you dont want to lug a bottle of booze around with you at a the CON (not sure why), here's a side project for the mechanical engineer in you: First get some elbow grease, a butter knife, garden pruners, and some clamps...

    • Pry off the scrolling plastic enclosure from the bottle with the butter knife (It's barely attached and should pop right off).
    • Next tighten the clamps on the top and bottom of the scroller, very VERY slowly until the plastic cracks. If you cant make it work this way, apply some elbow grease bending it in the middle if you are so brave. It should crack the plastic open.
    • Finally take some garden pruners and snip along where the...
    Read more »

  • An update on SW

    Zapp05/05/2017 at 15:09 0 comments

    Software development is in full swing with as much of our free time as possible going to coding. Last week we wrapped up v0.6 software which was focused on new features. In v0.6 we closed 105 issues, far more than any previous build on this badge. Starting May 1st we migrated our git and issue tracker, it worked surprisingly well.

    Focus now is on v0.7 which is intended to polish existing features and fix bugs. We have 92 issues as of today in the tracker and that will grow. This is the build that we will demo at Layer One in Los Angeles May 27th and 28th. Come to our talk, see a demo, and drink a beer with us.

  • Secret Component & Feature: SD Card & BYOB

    Hyr0n04/27/2017 at 04:29 2 comments

    So our first technical detail update in a while, but here it is: Micro SD-Card and Bring Your Own Bling (BYOB).

    We're starting off a bit EZ on the feature release and a lot of it stems from this one component. So for todays update, lets focus on why SD card and the whimsical magic that is BYOB.

    Chalk it up as lessons learned from DC24 to start with. Last year we leveraged NAND which is really easy to work with from a programming perspective, but a complete PITA when it comes to updating resources (configuration, images, etc) because you have to recompile the firmware and flashing in a really annoying way (Just ask Yaakov). Plus we had so many neckbeards ask us at DC24 how they could put their own images on the badge right then, and we had no "easy" answer without custom rolling a dev environment. So to be good software engineers as well as hacker friendly (not typically a good thing, but this is for DC hacking goodness) we made much of our software purely functional, reads specific resources, and parses it via an interpreter function. If you read our CHIP8 update, you would have noticed that each game comes with a config file, thats so when it loads, metadata is appropriately parsed and the menus get filled out.

    Security Side Bar: This is for making a "hackable" badge. Keep in mind with real life projects, parsers are the absolute devil for code injection.

    BLING works in a similar way. We have a specific folder in which we store the bling files and we added a "custom" bling mode where you can select any raw file on the Micro SD Card, pair it with a pre-made blinky light pattern, and there you go! So if you are just unsatisfied with the 100 preloaded bling modes we will provide, BYOB! Now you cant just drop an animated GIF (pronounced "jiff" or GTFO) because we use RAW format. Without getting super technical (you can f-ing google it there are well written programming articles on this topic), RAW is easier to work with than GIF in terms of overhead, which is great for embedded programming. If we just loaded plain GIFs we would have to put the entire image in memory to play it (which we are extremely limited on). Rather, using RAW format (RAW 16-bit 565 Big Endian uncompressed), we can stream the bits over SPI and straight to the screen. End result: more efficient, better FPS, less overhead, m0@r l337. @Zapp gets IPA tokens for this win. If you have criticisms, make your own embedded system con badge that has a full color screen and can display animations with only 64k of memory where each frame requires 33k of RAM...yeah we're THAT kind of efficient.

    So that means to BYOB, you need to convert your files ahead of time. Here's how...

    1) Find an animated GIF

    2) Crop the GIF to a 1:1 Ratio

    Our screen is a square and will convert the final animation to 128x128. Just make sure your crop is relatively "square" or the image will look skewed. There are many websites that will do this, we just use one at GIFGIFs

    3) Convert the file to RAW

    FFMpeg is your friend. Use it. Because we are going to give you the command line instructions to get this job done. There are GUI programs which do this as well, but...we are hackers. We use Linux. Deal with it. The INPUT.gif is the name of your file, the OUTPUT.RAW is what ffmpeg will save the conversion as. Make sure the filname is 8.3 length (e.g. no more than 8 charachters . RAW)

    ffmpeg -i INPUT.gif -r 22 -f rawvideo -s 128x128 -pix_fmt rgb565be OUTPUT.RAW
    Below is an example output. You'll see a lot of info from FFMPEG, dont worry thats normal.

    4) Mount the SD Card in to your computer and copy the newly created RAW file in to /SDCard/BLING/


    5) Safely unmount the SD Card, put back in the badge, turn on the badge and go to...

    Bling Menu -> Custom Bling

    You will find the RAW file you just added alphabetically. Choose it and dance the night away! (forgive the video quality)

    That's about it. We have some other features we'll release as the 'con gets closer. Enjoy!

  • We're rolling

    Zapp04/15/2017 at 03:57 0 comments

    It's been awhile since our last post, if you've been following us on Twitter you'll know that this week our Kickstarter campaign finished (thank you everyone!) and we placed our final order for hardware.

    We've done 4 rounds of prototyping up to this point under the code name "MAN BEAR PIG". The MBP4 was our final prototype and validated the design. To keep the turnaround time minimal we had a Chinese company produce the PCBs with next day shipping. We reflowed one PCB and everything worked so it's go time.

    A last second issue popped up while placing the final order. Our switching buck regulators were suddenly out of stock. There are plenty of fixed buck regulators out there that meet our specs, but none in at TSOT-25 footprint with matching pin outs. For some reason the pins are non-standard on our regulator. We were either stuck with a 16 week lead time (if it's not discontinued) or a re-design of the power supply. To avoid a MBP5, we bought out all stock from Digikey and Mouser and will consign those to the fab. As of this evening we have tracking information for both packages, catastrophe avoided!

  • CHIP8 & SCHIP Game Emulation

    Hyr0n02/12/2017 at 04:25 1 comment

    So reveal Numero Uno just got released for the badge: Game System Emulation. There was good thought behind this too. As much as we love making games, its a different kind of challenge. That's logic and procedural coding, which is fun. But hacking hardware, learning, sticking your hand right up there and grabbing it by the OPCODEs and making some obsolete processor your bitch? Yeah, that's what its all about.

    But this served a variety of purposes.

    One: Should we spend hours on hours coding, debugging, debugging, debugging, debugging, compiling, running, debugging 5-6 games? Or put that effort into creating emulators for systems which have a strong community backing and rich retro history? The latter obviously. Then you get to play all the awesome homebrew public domain games out there.

    Another important reason, the theme of DEFCON 25. Its retro and throwback to early hacking years. Don't believe me? What better games to include than 8-bit blocky, time sensitive, thumb smashing ROMs that give us so many pleasant member berries. Check out the DC25 retro awesome artwork thus far to put you in the mood:

    And most importantly, the reason we chose the emulator we did, was for you hackers out there. Stackoverflow did a study in February about what coding languages are most looked up on weekdays and weekends. During the week, its the bleh... Sharepoint, VBA, stuff. But on the weekend...Assembly! Woot! So you DO love hardware.

    This is where it gets good. No, GREAT. We want to teach you how to fish. Not give you a fish, but point you to the pond, give you some pointers, and if you feel up to it and want to code a game in CHIP8 or SCHIP, we will GLADLY throw it on the badge (I trailed off on the fishing reference, but you get it) There's no point in us re-writing CHIP8 tutorials when there are hundreds of them out there, but we will lead you in the right direction and provide guidance so we can easily integrate it . The best part, there are tons of emulators that run on your Linux, PC, Mac, Android, iOS already. So you can write and test an application without even having the badge yet.

    Step 0 - History Lesson

    Before you go making a game for a system, learn about it. Most of the documented knowledge on the web about CHIP8 and SCHIP stems from David Winter. It has the history, technical, screen shots, etc. You owe David Winter this if you wish to proceed. He has a beautiful website, I wouldn't change anything.

    STEP 1 - Play Some Games

    Get a feel for the system. Have some 8-bit fun. Look at whats already out there and think about how or what you could add to the community. And you are in for a surprise because the pad layout was a 16 key Hex set.

    STEP 2 - Learn the OPCODES & Technical Specifications

    Dont get scared now, this is where it gets fun. There's only 35 OPCODEs!

    (especially pay attention to Matthew Mikolay's details on the PROPER use of 8XYN OPCODES, most people do SHR and SHL wrong. In the vein of hacker jeopardy - DONT F*CK IT UP)

    STEP 3 - Get The CHIPPER Assembler & Some Source to Practice

    Back to David Winter's page, at the bottom is a download link with the games, assembler, and documentation. Don't fret, there is an .exe and .c file in the CHIPPER directory.. Throw away the .exe, all the best hacking is done under linux anyway.

    Try mwales GitHub site he has some excellent homebrew games and ASM files

    Once you have a test ASM file, the syntax is pretty easy but first you need to compile CHIPPER.

    ## Compiling

    gcc chipper.c -o chipper

    Then grab an assembly ASM file and execute with the following pattern:

    ## Assembling ROM

    ./chipper output_file.rom input_assembly_file.asm

    Grab your favorite CHIP8 or SCHIP emulator and play that ROM!!!

    Also if you just want to try messing around in a browser based environment, try this:

    Read more »

  • Software Planning

    Zapp02/08/2017 at 23:56 0 comments

    Badge development is in full swing with our first 6 prototypes expected to arrive next week. We're patiently refreshing the order status page hoping something changes.

    August through December were spent prototyping various hardware and testing out ideas. The software was developed specifically for those tests and not as badges. In January we started a new Eclipse project that will take us all the way to DEF CON. We ported some of the drivers from prototyping over to the master project and created our backlog in the issue tracker. The backlog continues to grow as we add more detail to our ideas and use the software.

    To manage the work, we've setup a series of milestones for the software:

    • v0.1.0 - Jan: Initial drivers for all hardware on hand, demonstrate badge basics and UI
    • v0.2.0 - Jan: Focus on porting bling and supporting APIs. Explore new bling concepts. Refine UI. Work on Secret Feature 1 and initiate Secret Feature 2.
    • v0.3.0 - Feb: Focus on Secret Feature 3 and getting badge software to run on prototypes once they arrive.
    • v0.4.0 - Mar: Refinement of Secret Feature 2. Hopefully merge Secret Feature 4. Port some games / major features from DC24.
    • v0.5.0 - Mar: Cyphercon release. This will be the software that runs when we take the prototype to Cyphercon. Refine bling, fix bugs, cleanup UI. Any secret feature work will be hidden.
    • v0.6.0 - Apr: Complete Secret Feature 2.
    • v0.7.0 - May: Possible Layer One release. More cleanup. Complete Bling. Merge Secret Feature 5.
    • v0.8.0 - Jun: Feature-complete. Used for test to identify issues.
    • v0.9.0 - Jun: Final testing release, no new features, only fixes.
    • v1.0.0 - Jul: Final release

  • Prototypes are GO!

    Zapp01/21/2017 at 02:37 0 comments

      Well we missed our January 18th target by 2 days, but the prototype design has been ordered. We hope to have them in house by February 15th. This gives us about 2 weeks of slack time in case the fab and assembly takes longer than expected.

      We did an initial prototyping round back November but did not map the pins properly. This meant most of the peripherals simply didn't work. We learned a few things but had to revert to our dev kits for development and prototyping.

      To avoid issues with today's prototypes we ordered an interim "Risk Reduction" test board from OSH Park. This included most peripherals from the BOM we were concerned with and allows us the flexibility to breadboard some of our assumptions. Two issues were identified:

      1. We had the wrong connector for our display (we chose a top contact and needed bottom)
      2. The display connector footprint was missing solder paste layer

      We were able to work around both issues and test the display (which works quite nicely) and even found a better, cheaper, and stronger connector. Win win! As a final step, several PCB layers were printed (actual size) to verify footprints and size. A comparison with our DC24 badge is below.

      While we wait impatiently for the prototypes to arrive, we're using the risk reduction board and dev kit to continue software development.

  • Hackability

    Zapp01/07/2017 at 16:31 0 comments

      DEF CON 24

      One of the basic features of our DC24 badge was design for hackability. Personally, the badge project was a journey into embedded electronics. I got started with an Arduino and a breadboard, this is what I was familiar with. I designed Bender along those lines. The hardware was inspired by the Maple Mini from Leaf Labs and Espruino (both STM32F013) and ran an Arduino framework called stm32duino. We exposed as much IO as possible around Bender's eyes, provided SWD and FTDI interfaces, and USB for UART and DFU.

      We know of one user hacking their badge. @mediumrehr added his own cigar PCB and spectrum analyzer to Bender. It was amazing to watch and that his design fit so well.

      This approach had some issues, however:

      1. It required source code to modify the badge - which we didn't release until after DEF CON
      2. stm32duino is not a straightforward install - it requires many steps and is not managed through the Arduino IDE.
      3. The SWD interface was not enabled in the firmware - we released an update that enables it but at DEF CON it was not working

      All in all we were very happy with the badges, we know of at least two people who have created their own Benders from github so it can't be that hard. If you see anybody with it a Purple Bender, buy them a drink. They made it themselves and it was not easy.

      DEF CON 25

      Based off our experience at DEF CON 24, our goal remains the same: Make the Badge Hackable but we want to see your hacks in Las Vegas. We want you to share your hacks. So we're changing things up. This year's badge is not based off a development board. It is completely original. There will be no USB but there will be SWD. We will expose as much GPIO as we can. And we will provide physical dimensions where it makes sense. Finally, we want the barrier-to-hacking to be as low as possible. How? We're not sure yet, but last year the goal was nothing more than a laptop, the Arduino IDE, and stm32duino.

  • Badge Art Contest

    Hyr0n01/04/2017 at 07:34 1 comment

      So from the public's POV, you saw this on our Twitter feed. We decided to get the hype train going a little early and threw a game together to give the l337 H@x0r community of DEFCON something to do over the holiday break. BEFORE READING ANY FURTHER, KNOW THAT THIS IS AN UBER SPOILER OF THE CONTEST STEPS. IT HAS BEEN WON ALREADY, BUT IF YOU STILL WANT TO GIVE YOUR SKILLS A SHOT, DONT READ FURTHER...or if you're the kind of person who racked out their NES checklist with a Game Genie to skip past the hard parts so you could have lunchtime bragging rights of the final boss details, by all means keep reading ;) And if you're too young to know what a Game Genie is...sigh...

      Anyway, about a month ago over a much inebriated brewery board meeting, we locked down a functional baseline of our DC25 badge. At some point, we started thinking of ways to have fun with a contest, and thus this cluster fuck was born. Over a lot of booze.

      We figured, since we were going to give away a free badge, you should f-ing work for it. Instead of going the route of a certain genre of our DC interests, we decided to just layer and sandwich a bunch of stuff together. We knew since mid-October-ish (thats a word right?) we were going to do something, so we started tweeting out easter eggs and hiding stuff in youtube videos we knew we could use later on... It could have been the booze talking too...

      Now at the same time when the contest started, we were running a booster campaign. Designing and Prototyping badges isn't cheap. It costs us a lot of money. So we we're boosting with shirts that contained a silhouette of the badge design. It had a cryptic message: 42 59 54 45 20 4d 59 20 53 48 49 4e 59 20 4d 45 54 41 4c 20 42 41 44 47 45 21

      I wont give that one away, but cmon, find your favorite HEX to ASCII converter. So instantly we got many MANY guesses that, that was the secret phrase. Well our tweet said "badge design" and this is an outline. Doesn't show you much. To be fair, we quickly told everyone it had nothing to do with the Booster site. But that was a good warm-up for things to come.

      Okay so, in step by step, lead you by the hand fashion, here's a typical way someone could have gone about winning the contest.

      1. It was hidden somewhere on the internet....try our web page
        1. There's only a couple of images, if one tried to download MANBEARPIG (which we referred to a ridiculous amount of times on Twitter) you would notice you cant. We blocked it out with CSS.
      2. View Page Source
          1. Well looky here, there's the name of the style sheet "andnxor.css". Lets type that in...
        1. Looks like someone updated the manbearpig.png with a new version "v2" thats odd. Lets download it. Now that we know the file name, you can just type it in the browser address, and save as. Wow that took forever right? Well most people wouldnt notice cuz their interweb speeds are so fast. But look at the file properties. Isn't it a little odd that you have a BLACK AND WHITE PNG image that's 800kb?
        2. Steganography - the practice of concealing messages or information within other nonsecret text or data. Now this is where paths can diverge on solving the puzzle. You could verify something is hidden the proper way, load it in a hex editor, and notice the regularly unused bits of the image have data in them. Or just hack around. There's many steganography applications out there, even fewer are free and open source
        3. Load the Image in OpenStego
          1. Given the shit I've put you through thus far, you should assume its just not that easy. Of course we damn well password protected it. There were many hints thrown out on twitter, youtube and chats...
          2. I even blurted out "C1E169852F1D95CC2DA7AA791E5F4EFF"
            1. Try cracking the hash
          3. All signs point to the password being "EXCELSIOR!"
        4. Cool, so you now have a PNG with something hidden inside of it, OpenStego, and a password. Extract it and what do you get...
          1. Well shit there's the badge art which we will be screening on to the PCB. Awesome right? Well, we hope you think...
      Read more »

    • Optimizing Display Code

      Zapp12/30/2016 at 18:00 0 comments

        Over the past few months I have been working on custom drivers for various peripherals for our badge. Most of this is to learn how to build the drivers and the underlying hardware. This would have been an impossible task for me just a year before working on our DC24 badge. At this point I've come up with a custom display driver which I believe is as close to optimized as I can get it. In the process here are the factors that need to be considered:

        1. Maximize bulk transfer speed - select the highest possible SPI clock rate the MCU and display will safely operate at
        2. Minimize latency between bulk transfers - utilize DMA to asynchronously transfer chunks while preparing the next chunk for transfer
        3. Minimize data to be transferred - reduce color depth, pixels, and commands to be sent

        During prototyping we've been limited to 8 Mhz on the SPI bus. At 320x240 16-bit, a single frame requires 1.2 Mbits! Over SPI, the render can take seconds. No where close to what we need.

        One of my favorite tools as of late is my Saleae 8 channel logic analyzer. It's nice and compact enough to travel with me for work too.

        For displays like the ILI9341 (pictured), the typical command sequence is to set a window (0x2A and 0x2B commands) with the X and Y dimensions followed by raw pixel data. Below is a trace of the window command. Taking 69 usec to transfer 10 bytes (0x2A, start x, end x, 0x2B, start y, end y). The coordinates are 16-bit integers. Also notice the delay between transfers as the MCU is executing other commands.

        To draw a single pixel, the address command above plus a 16-bit color must be sent to the display - 12 bytes total! That's a lot of overhead for one pixel.

        Here's what drawing Bender on a 128x128 display at 16-bits looks like. In this case the window is set to 0, 128, 0, 128 then 16-bit colors are streamed to the display.

        Looking at the clock line, notice there are gaps here that we should be able to optimize out. Rendering appears to take 682 msec. Zooming way in we see there is a lot of space between transfers. Toggling the CS line seems to be wasting time. Data is being transferred two bytes at a time because it's being converted from a 24-bit BMP pixel-by-pixel.

        So How Do We Improve This?

        An easy way is to remove the BMP overhead by pre-processing the images. The display is in 16-bit 565 mode. By converting the image to 565 big-endian raw data using ffmpeg we can stream the pixels in the display's native format. The following command will convert an image to 565be raw format.

        ffmpeg -i RED.BMP -f image2 -s 128x128 -pix_fmt rgb565be RED.raw

        In addition we can remove some of the SPI blocking to reduce delays. The image below shows the flash memory and LCD transfers occurring asynchronously.

        The transfer in green is the LCD and red is the flash memory being setup to read the next chunk of the image. Notice the pixel data has fewer gaps. We are simply reading the 565BE data from flash and streaming it to the LCD. At this point we can draw 10.5 FPS.

        The flash setup time is wasting quite a bit of time, roughly 800 usec. We're paying this penalty many times per frame. To reduce the number of times occurs we can make a classic tradeoff between memory and performance. Next step is to increase the chunk size from 2 rows to 32 rows per transfer. This uses about 8k of memory and gives us a nice speed boost to 11.7 FPS.

        The transfers are basically blocking each other at this point. Again in the image above LCD is on the top and flash is on the bottom.

        Last Step

        Now that large chunks of pixel data can be read and streamed to the LCD very quickly, the last step is to send the pixel while the flash is reading the next frame. I can only transfer 254 bytes at a time, but can do so asynchronously. The trick is to setup the next 254 bytes of the chunk soon after the first returns but not interrupt the flash transfer. This allows the flash to be read with very little disruption setting up the next 32 rows of image data while the last are being sent.

        In the image above,...

      Read more »

    View all 11 project logs

    • 1
      1. Drink Beer
      2. Assemble Bender
      3. Profit
      4. Drink Beer

    View all instructions

    Enjoy this project?



    Similar Projects

    Does this project spark your interest?

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