Liquid Soulder

Member Since: May 25, 2018

Country: United States


Neptune the Grey

Naturally, having just fired up the new Transparent Graphical OLED display, I wondered what it would take to make a 3D display. Here's the story of the struggle, as told in an intentional allusion to interpretive alliteration.

Continue reading

Introducing SparkFun's new microcontroller graphics library: HyperDisplay! What is it, why did we make it and how can I learn more about it? All your musings will be concluded right here, right now.

Continue reading

The motivation behind the "Three Quick Tips for Using U.FL" tutorial

Continue reading

Details of a silly problem with a silly solution: How to not overwrite your outgoing SPI data buffer when using the Arduino core libraries

Continue reading

TFT LCD Breakout 1.8in 128x160 Hookup Guide

April 11, 2019

This TFT LCD Breakout is a versatile, colorful, and easy way to experiment with graphics or create a user interface for your project.

SparkFun Edge Hookup Guide

March 28, 2019

Get to know your Edge board, including both the hardware features for you to utilize as well as how to get talking to it.

Using SparkFun Edge Board with Ambiq Apollo3 SDK

March 28, 2019

We will demonstrate how to get started with your SparkFun Edge Board by setting up the toolchain on your computer, examining an example program, and using the serial uploader tool to flash the chip.

Transparent Graphical OLED Breakout Hookup Guide

March 7, 2019

The future is here! Our Qwiic Transparent Graphical OLED Breakout allows you to display custom images on a transparent screen using either I2C or SPI connections.

Everything You Should Know About HyperDisplay

February 20, 2019

This is a tutorial to go in-depth about the SparkFun HyperDisplay Arduino Library.

Three Quick Tips About Using U.FL

December 28, 2018

Quick tips regarding how to connect, protect, and disconnect U.FL connectors.

SparkFun LoRa Gateway 1-Channel Hookup Guide

November 15, 2018

How to setup and use the LoRa Gateway 1-Channel in Arduino.
  • You may need to generate the BSP library archives. Try navigating to {SDK_ROOT}/boards/SparkFun_Edge_BSP/bsp/gcc and running make. This should generate the necessary libraries. Then you can try making the example again. HTH

  • Hmm. It appears you are using windows which is surprising because the driver issues (also on the SparkFun forums for Edge board)have mostly appeared on Mac and Linux.

    Some things to check are that you're using the correct baud rate (115200 if you got your board at the TensorFlow conference and 921600 otherwise) and that you're following the proper bootloading button sequence. That is:

    • Hold down button 14
    • While holding button 14 press and release the reset button
    • While holding button 14 run 'make bootload' on the computer
    • When prompted with 'done, sending reset command' press reset to begin the application

    If those steps don't work out please check out the resources in the SparkFun Forums for Edge

  • Great question!

    • First and foremost the 'write()' method can be inherited in a sub-class and changed to anything you like, given the available information (which character to write, and anything in the HyperDisplay base object). That's the most flexible way to implement a custom font, but not the easiest.

    • If you want to use the default 'write()' method you can choose to just provide your own 'getCharInfo()' method. In this case the default 'write()' function will use the information in the char_info_t structure to decide how to show the character. The way it works is that a given character will have numPixels to display. There will be numPixels x and y coordinates to indicate where each pixel should go relative to the character's origin (top left). You can supply a color sequence to use in the pixels, or provide NULL to use the current window's default color sequence. The xDim and yDim members will determine how far to advance the origin for the next character. The 'show' member can be used to decide if a certain character should be shown on screen.

    So in your case check out the current default 'getCharInfo()' function and see how it affects the 'character_info' struct. (Basically it goes over all the pixels in the bitmap and if it exists it adds the location to the xLoc and yLoc arrays). You'll need to loop over the data in the larger font and do a similar thing with it.

    Though it's not exactly the same the inspiration for this method came from the RGB OLED library. You can check out the Custom Font Example for some inspiration and a little more explanation.

    Please show it off when you get it working!

  • Awesome, thanks for sharing!

  • Oops! We're posting it on the Documents tab anyway b/c that's where it oughtta go! Thanks for calling that to our attention. P.s. even though it says confidential we have gotten permission to share it with you all.

  • Well, I was just thinking about this and here's my first reaction.... On the B+ you don't have any convenient way to run C++ or Arduino code (right? I haven't really pushed the limits here). So unfortunately you won't be able to use HyperDisplay directly. IMO that leaves you with two options: 1. try reading the code for the driver to understand what I2C commands are used to set it up and draw pixels, then making that happen on the Pi with Python, or 2. Control the graphical OLED with an arduino-compatible microcontroller that runs HyperDisplay, and use a communication protocol of your own to activate the various drawing functions from the Pi. This is a pretty good option for the Transparent Graphical OLED since it is on/off only - you won't need to worry about handling colors in your protocol.

    Let us know what you end up doing, it could be a good resource for others!

  • Aha! Thanks for explaining, I see now. I'll go over and fix that snippet :)

  • Okay so I gave it a look-over and still couldn't see the missing pointer setting. In lines 79-80 there are two different functions being called - one sets the memory for the current window and the other requires that you specify which window to set the memory for. That might be able to account for the confusion. If it doesn't and there's still trouble will you consider posting a pull request with your desired changes on GitHub? Or if not that then just an issue with a screenshot of what you're seeing would be good.

  • Thanks spotting that! I couldn't find anything in the Buffering Example on GitHub. Is this the right file? Could you suggest a line # or something so I can find it more easily?

  • Thanks for posting these notes!

No public wish lists :(