Porting Arduboy2 library to SAMD

I’ve been looking at getting the LCD display working with Arduboy2 library this morning. I’m using a variety of sources to try and pin down what commands and data format should be sent to the UC1701 display controller but the main reference at the moment is the capture from my oscilloscope while using the verified u8g2 demo program you see in the video above. By introducing delays between the frames, I can do a single trace capture and compare e.g. the u8g2.begin() output with the library. So far I can match the data that is sent at arduboy.boot() with that sent at u8g2.begin(). But no boot logo appears and I can’t do a print screen. I think it would be easier to confirm using an image rather than a print function, so I’m working on the basis that I should get the boot logo working first.


Ignore the blue (not cyan) trace - it’s not connected. This is the capture from a working transfer of an image to the LCD using u8g2 library. Pink is connected to DC, so we can see at the start of each of the two burst sections of data that three commands are sent. There are 8 of these bursts of, I’m assuming, 128 bytes (128 x 64 / 8bits / 8 bursts = 128 Bytes).

The first two of the three command bytes at the start are always 0x10 and 0x00. The third is 0xB0, 0xB1… …0xB7 for the last one (couldn’t fit all three commands on the scope screen hence the decoding isn’t showing up but it is there if I zoom in).

This is making me think we need to adjust the Arduboy2Core::paintScreen(uint8_t image[], bool clear) function to insert these commands at the appropriate point. Like

  for (int i = 0; i < (HEIGHT*WIDTH)/8; i++)
  {
	  if (i % 8 == 0) {
		  SPItransfer(0x10);
		  SPItransfer(0x00);
		  SPItransfer(i / 8);
	  }	
    SPItransfer(image[i]);
  }

Any thoughts? I don’t know the SSD1306 like some of you lot do so is there’ a reason why I can’t see this kind of organisation already happening in the Arduboy2Core::paintScreen(uint8_t image[], bool clear) function (remember that the AVR version is nothing like the SPI.transfer() function that we have adopted for the SAMD)?

EDIT that code clearly didn’t work. Here’s something slightly more informed but not tested:

  uint8_t rowPair = 0;
  for (int i = 0; i < (HEIGHT*WIDTH)/8; i++)
  {
	  if (i % 8 == 0) {
		  LCDCommandMode();
		  SPItransfer(0x10);
		  SPItransfer(0x00);
		  rowPair = 0xB0 | (0x01 << (i / 8));
		  SPItransfer(rowPair);
		  LCDDataMode();
	  }	
    SPItransfer(image[i]);
  }
1 Like

I’ve supported many of the Rabid Prototypes campaigns on Kickstarter and he truly has dropped the ball on the Tachyon campaign. It really is a shame. I was issued a refund without requesting one as I guess he didn’t like that I would occasionally ask for updates on the project. (Shake head) I went with the Adafruit Itsybitsy M4 quite some time ago as I regularly purchase form Digikey and add Adafruit boards to bump orders into the free shipping tier.

2 Likes

So, here’s where I’m up to with getting Arduboy2 to send data to the LCD, using the HelloWorld example sketch. I’m very pleased as even though this is messed up, I can see data that we intended to be passed appearing on the screen! Going to take a break and drill holes in aluminium with my CNC router as a reward!

1 Like

Getting closer?

1 Like

Bingo


A bit too much contrast (I think it’s only one setting below max) and the code needs a huge amount of tidying but this modified HelloWorld.ino seems to be working nicely. It uses a 15fps frame rate so I don’t know if changing that as well as the contrast would help.
2 Likes

Nice work! The ghosting tho :dizzy_face:

It may get better with different screen settings - the LCD controller seems to have a fair amount of adjustment available:

Snippet from UC1701 datasheet

But if not, “because retro”. It’s highly intentional, to give an authentic 8bit feeling. OLEDs indeed! :grin:

Anyway, I have a serious question. The hardware configuration files that you find in an Arduino hardware folder to specify compiler options, pin mapping etc are clearly not part of the Arduboy2 library but they are part of getting Arduboy2 working on the SAMD microcontrollers. What’s the best way to share them? As a separate repo? Somehow linked to other repos that may also contain hardware configuration for Arduboy devices? I don’t have an Arduboy so I haven’t even checked what’s out there already.

I have a crystalless bootloader (might have made a crystalless version of the Zero bootloader but I can’t remember - was back in the summer) and today made an accompanying set of variant files. The main edit was adding -DCRYSTALLESS to the build options in boards.txt (which took a while to track down as the source of my board’s silence on the oscilloscope, so it was a breakthrough even though it was trivial to rectify). The rest was changing names in boards.txt so it would appear as a separate board in the Arduino IDE and copying the Sparkfun SAMD21 mini’s variant.h and variant.cpp into the folder (which lives in the Arduino IDE project folder’s hardware folder, for a local board. This could easily be added to the boards manager in the IDE if we hosted it somewhere and added the required acoutrements, such as version folder, json file, changelog, variant compliance changelog etc.

Fixed the screenshot for you too

There was still some blue left

Thanks, my subscription to Photoshop ran out while I was looking for more ports on my oscilloscope to connect random traces to earlier!

1 Like
C:\Users\...\AppData\Local\Temp\arduino_build_588628\sketch\Utils/Eeprom.h:21:24: fatal error: avr/eeprom.h: No such file or directory
 #include <avr/eeprom.h>
                        ^
compilation terminated.

Bum

I know I went through Arduboy2.h and .cpp and deleted/commented out any reference to eeprom, and now it’s coming home to roost. I promise to take a look at the Pokkito port in due course but if anyone has any bright ideas about how to tackle eeprom in SAMDs, I’m all ears. We may need to do it properly from the start though. IIRC, the adafruit library port for circuit python just writes a file and treats it as eeprom, so not very useful here.

In the meantime, I will have a dig into the LCD settings. By the way, for anyone playing along at home, the settings for all the screenshots and videos you’ve seen so far are:

0xE2, /* soft reset 0x0e2*/
0xAE, /* display off 0x0ae*/
0x40, /* set display start line to 0   0x040*/
0xA0, /* ADC set to reverse 0x0a0*/
0xC8, /* common output mode 0x0c8*/
0xA6, /* display normal, bit val 0: LCD pixel off. 0x0a6*/
0xA2, /* LCD bias 1/9 0x0a2*/
0x2F, /* all power  control circuits on 0x02f*/
0xF8, /* set booster ratio to 0x0f8*/
0x00, /* 4x 0x000*/
0x23, /* set V0 voltage resistor ratio to large 0x023*/
0x81, /* set contrast 0x081*/
0x27, /* contrast value 0x027*/
0xAC, /* indicator 0x0ac*/
0x00, /* disable 0x000*/
0xAF,  /* display on 0x0af*/

Which is quickly followed by the contrast being raised to either 0x3E or 0x32 (out of 0x3F max)


Arduboy2Core::paintScreen(uint8_t image[], bool clear) should be nearly up to @Pharap’s standard in the most recent commit. Just be aware that I haven’t been able to successfully make the LCD vs OLED displays conditional, so in that commit I have made the default display the UC1701-driven LCD. I’ll revert if someone can tell me how to make the display settings conditional (I tried doing #define (UC1701) in Arduboy2Core.h and #if defined (UC1701) in Arduboy2Core.cpp but the compiler didn’t seem to react to it).

Give GIMP a go instead:

Open source and completely free, no silly subscriptions to worry about.

For now your best solution to this would be to create a dummy avr/eeprom.h.
You’d have to implement a number of functions,
but they don’t actually have to be functional at this point,
you could get away with making them do nothing.

Most of what you’d need is already here:


If you take that and comment out the readEEPROM and writeEEPROM calls then you should have more or less what you need.

If you don’t have access to a C++11 standard library implementation then you’ll also need to remove all the uses of std::, but that’s a simple find-and-replace operation.

The problem with that approach comes with flushing the data back to the device.
With EEPROM, all writes are immediate, there’s no buffer and no flushing required.
With SD cards and similar systems the data hangs around in a RAM buffer and has to be manually flushed to disk.

If that’s literal, then you’ll want to remove those brackets for a start.
I’m not even sure how the preprocessor would react to that.
Logically it should try to define a function macro that doesn’t have a name,
but even if that were legal I’d assume it would be impossible to actually use a macro with no name.

For adding new hardware to the Arduino IDE, you should use the following documents:

Edit: Also this:
https://playground.arduino.cc/Main/BoardsManagerSupport/

2 Likes

@MLXXXp thank you. I am aware of the Arduino way of adding board support but I was rather after any Arduboy community preferences on e.g. whether it should be added to an existing repo or given a standalone, both short term (as WIP) and longer term.


I’m pretty sure I tried without brackets first. I’ll go back and try again.

@MLXXXp manages Arduboy2 github so I’d imagine if you made a push request there he would review it.

I dunno my general feeling it’s enough of a jump that it probably warrants it’s own repo.

Maybe call it Arduboy3? :smiley:

1 Like

I think it’s just hardware specification files, not game compiling libraries, so probably needs a separate repo if there isn’t already a boards.txt for Arduboy (wouldn’t it be easy to do one?)

I stated earlier in this topic:

However, if you wish, I don’t mind having this work on a branch in my Arduboy2 repository, without it interfering with the master branch. I could make you a repository collaborator so you could maintain that branch.


No. As I’ve already stated in this topic:

If it’s renamed to something else, such as Arduboy3, you then have to modify each sketch in order for it to compile against the new hardware. It should be part of Arduboy2 using conditional compiles.

However, if the new hardware ends up being different enough that many Arduboy sketches wont compile or work properly without modification, such as having a new display that’s not 100% backwards compatible, then that’s a different story.

There is. The URL to add it to the Arduino IDE is:
https://arduboy.github.io/board-support/package_arduboy_index.json

1 Like

I would like the branch of Arduboy2 that is SAMD compatible to be merged back in to the master if possible, as I think we have discussed before.

My current line of enquiry is about the 3rd party hardware specification and the files that go with it. I would like to add them to an existing repo (thanks for the json link @MLXXXp) but will set up a separate one or fork the original to add the SAMD board that I have developed and should also be compatible with other SAMD21 based boards.

Yes, do that for now until if/when hardware becomes official or popular. You don’t currently plan to actually have it listed by Arduino, do you?