Experimentation with Adafruit ItsyBitsy M4 board

Discuss anything not related to the current Uzebox design like successors and other open source gaming hardware
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Experimentation with Adafruit ItsyBitsy M4 board

Post by mast3rbug »

Hi all.

Long time I did't log into this forum, but I'm still active in the MicroControllers scene.

Here a quick post about a new experiment I have done;

Recently, I purchased this board because I wanted to experiment with ARM CPU since long time. Also, it's really low cost and it have an ARM Cortex M4 Micro (ATSAMD51G19) with capable clock speed of 120 MHz. Herre a picture of the board itself:

Image

The cool thing about this Microcontroller is it's have 192K of RAM. So really good at a minimalist video plateform but with a lot of possibilities. (2 video buffer of 64K ).

For now, I was able to display on a VGA monitor a picture at 256 x 256 resolution in 256 colors. I was able to do it at a low clock rate only (I think it's 48 MHz with internal FPLL, but the documentation is not clear about the basic clock speed of the chip). The jitter is about 1/2 pixel. With the Internal PLL, I was not able to manage a stable picture at 120 MHz, probably due to instability with the internal reference clock. the jitter is about 6 pixels.

It really need some resistors on the breadboard, nothing else to generate a VGA signal:

here a picture of it, it's better in real.

Image



I will keep you informed about my future experiments on this new chip. Cool projects to come!

Mast3rbug.
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by nicksen782 »

Glad to see you back! I've always enjoyed your projects and insights.
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by mast3rbug »

I'm working now on the picture stability, I'm trying to use counter instead of interrupt to manage the Hsync. Also, in this particular chip, it looks like it is able to copy Data from RAM to IO with DMA with 0 CPU intervention at full 120 MHZ speed. I don't know if some jitter will occure interfering with not completed CPU cycles with a DMA request at the same time, but there is also a 8KB ram Elsewhere on another isolated bus, so I think the DMA can copy data frop Backup Ram to Video output without touching the CPU BUS at all.

I will keep you informed of my developments.

Cedric
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by D3thAdd3r »

That device sounds like it has real potential for more 16bit-era graphics with all the cycles, ram, and DMA. Interested to see how this develops!
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by mast3rbug »

Okay, After a lot of work (I found these AMR chip are really complicated compared to Atmega...) and a lot of documentation reading (The SamD51 data sheet is about 2500 pages). I managed to have a stable image at 120 Mhz, for now only 1 pixel jitter. (Better than 6 pixels, and I'm comfortable with that at the moment). I will be able to write some useful code to experiment what I can do at 120 MHz yeah!!. I already have written code in C from my ATXMEGA game console that I can port directly on the ARM chip.

Here the thing I had to do to have it working at 120 mHZ:

I had to generate Horizontal and Vertical timing by counter and used 1 EVENT channel to trigger the Vertical Counter to start at the right timing. The counters are sourced from 48 MHz internal DPLL. An interrupt trigger the CPU driven pixel bitbang clocked at 120 mhZ. So the Main CPU is at 120 mhZ and the Synching are at 48 Mhz. I experiment things with this chip since 1 month now, and I must admit that starting with only the ATMEGA AVR experience, it was really hard. There is almost no example for the SAMD51 chip over internet, and the only examples availables are with the ASF microchip Hugly framework.

By the way, It's working now and I'm more and more confident with this chip. Stay tuned...
Cedric



UPDATE--
Note1:
I had to clock the Main CPU to 124.578 MHZ to have 320 Pixel wide from corner to corner. Not bad only little overclocking.
Note2:
It looks like the board have one port mapped to a VREF for Analog dignals, Not sure how easy it is to cut the trace on the board, but in worst case, will have 128 colors instead of 256. not too bad, we can use one bit reference in RAM for Sprite collision.

Update 2: Had to cut a trace on the bord for a VREF pad and a capacitor. The signal works now!
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by Jubatian »

Nice stuff!

Just saying that I am following this as well, and maybe start experimenting with the actual thing at last! (Still having a BitBox laying around, an STM32F4)

I feel like the jitter could likely come from that the interrupt simply can not be jitter-free, you would have to compensate for it by reading the timer (like the Uzebox kernel does). However the ARMs are complex enough so that they might even have better options, at least on the STM32 I see that it could be possible to fire DMA transfers for example directly by the timer (so no interrupt entry jitter). Another thing to look out for is flash wait states if you are running the code from the internal Flash. STM32's have caches to mitigate this, but of course that makes timing unpredictable. The timing critical code would have to run from RAM. The libraries should set up wait states and caches automatically depending on chosen clock speed, at least generating stuff for the STM32 works this way, and for this, it could indeed happen that there is little jitter at low clock frequency, but more significant jitter when running faster.

Maybe you are through these, just thoughts. And of course it could be that too that the internal clock just isn't stable enough.
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by mast3rbug »

I feel like the jitter could likely come from that the interrupt simply can not be jitter-free, you would have to compensate for it by reading the timer (like the Uzebox kernel does).
Yes for sure! don't worry about this, I built about 6 devices that generate video signal, I had to manage all kind of problems related to sync. This is a fun challenge. Just a link to one of them on an Atxmega just to show you my skill on the subject (The music is also generated by the Atxmega real time, 4 voices .MOD player computed in Hsync CPU free time):

However the ARMs are complex enough so that they might even have better options, at least on the STM32 I see that it could be possible to fire DMA transfers for example directly by the timer (so no interrupt entry jitter).
Yes this is something I will try in a near future, after having done some animation routines and stuff and maybe translated my .MOD player from Xmega to this ARM chip.
Another thing to look out for is flash wait states if you are running the code from the internal Flash. STM32's have caches to mitigate this, but of course that makes timing unpredictable. The timing critical code would have to run from RAM. The libraries should set up wait states and caches automatically depending on chosen clock speed, at least generating stuff for the STM32 works this way
The good thing with this new chip (SamD51), the Flash and RAM can run without latency up to Max Speed. So no need for tweak in the code location or caching stuff.
Maybe you are through these, just thoughts. And of course it could be that too that the internal clock just isn't stable enough.
The internal clock introduce some jitter. I wil try soon to clock from external source to have a more precise timing. There is also some errata about the PLL system. I se the instability right now, over 1-2 minutes, I can see the the screen width changing really slowly about 1 mm.

Still lot of things to try, equalizing the interrupt routine with couter read, Short sleep that wakeup with the horizontal event (This eliminate random instruction cycle lenght when the interrupt is called since Event are generated without CPU intervention), polling the Horizontal pulse, DMA stuff...

I really thing this chip can do something really good. Even a system compatible with the uzebox in term of kernel (Just need to adapt and recompile the source code of games and programs, having 2 version of Final code for the two consoles versions but the exact same game library without too much work.)

And also what is fun about that, no need to do complex timing in Assembly language to emulate the video modes, because all can be done in C in the main program, at this clock speed, all the video modes can be emulated insted of constructed in the video loop.

This is the weeken, I hope will have some time to do cool stuff in the project!

Cedric
Last edited by mast3rbug on Sun Feb 17, 2019 12:33 am, edited 1 time in total.
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by mast3rbug »

Also, I want to design from start the RGB generator the same as the UZEBOX, I see the Uzebox is byte reversed

RRRGGGBB

(PORTC)
PPPPPPPP
CCCCCCC
01234567
Is someone that can confirm to me the byte order of this? I mean:

012 = 0 MSB RED and 2 LSB RED and so on?...

Thanks
Cedric
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by Jubatian »

Running a Flash at 120MHz - WOW! :o I will look into the specs of this thing, I wouldn't have ever thought that such a physical design was possible!

The ST ARM devices feel absolutely horrible regarding their internal Flash and nonvolatile storage options. They have no EEPROM, and the internal Flash on a particular chip I am designing for at work is partitioned like 4 x 16K and 1 x 64K erase blocks (you can not erase in any smaller granularity). This is where I get the feeling that oh, sure, you might get that 32 bit ARM at a clunky old 8 bitter's price, but very soon you will have to add an extra chip since it is just lacking something crucial there.

Great stuff, I see you have full control of the technology there! :)

The Uzebox palette is BBGGGRRR, the highest bit of the byte is the highest bit of the Blue component (so how you described it is right).

After some thoughts and some DAC sketching I also got the conclusion that this is about the best palette for these sort of things. Fewest components to get 8 bit color, having only 3 bit DACs neither drive for such an accuracy which you might struggle to get when home-building the thing. RRGGBBII would be nice, but that's more components, actually needing an RRRRGGGGBBBB DAC where you source the low 2 bits of each colour from the I bits.

A bit back to your original pondering on the palette: For 127 colors actually an RRGGBBI layout might be a nice solution (build an RRRGGGBBB DAC, and source lowest bit of each color from the I bit).

I checked the Datasheet of the MCU as I just couldn't believe it is running the Flash at 120MHz. It indeed, can not, however...

Datasheet: http://ww1.microchip.com/downloads/en/D ... 01507C.pdf

The Wait States you need to configure for the NVM controller are on Page 2042. If you use the Microchip library, it likely does it for you. But why you may still see it running blazing fast like if it ran without any fishy stuff is that this MCU has some apparently quite awesome Instruction & Data cache! The chapter describing it begins at Page 81. It can use up to 4K of Tightly Coupled Memory (you may choose to not use the cache and have 4K extra RAM instead, or split it up arbitrarily), and it supports locking areas into the cache. If you have a small, experimental program, then it may well fit within the cache entirely (the part which is relevant to the spiffy graphics stuff), if the program grows bigger, then you may use the mechanism to lock the appropriate parts of your code permanently in the cache.

It is a lot cleaner than copying stuff into RAM for sure. The STM32 Cortex M4's don't have anything quite similar.

And also the Flash has 512 byte erase pages, which makes it actually useful to serve as a replacement for the missing EEPROM. Also it seems to be possible to realize a bootloader like that of Uzebox's on this MCU :) (I mean one which updates page by page, only writing what is necessary to be written).

Nice, quite spiffy toy to play around with!
User avatar
mast3rbug
Posts: 81
Joined: Sat Jan 08, 2011 8:15 am

Re: Experimentation with Adafruit ItsyBitsy M4 board

Post by mast3rbug »

The Wait States you need to configure for the NVM controller are on Page 2042. If you use the Microchip library, it likely does it for you. But why you may still see it running blazing fast like if it ran without any fishy stuff is that this MCU has some apparently quite awesome Instruction & Data cache! The chapter describing it begins at Page 81. It can use up to 4K of Tightly Coupled Memory (you may choose to not use the cache and have 4K extra RAM instead, or split it up arbitrarily), and it supports locking areas into the cache. If you have a small, experimental program, then it may well fit within the cache entirely (the part which is relevant to the spiffy graphics stuff), if the program grows bigger, then you may use the mechanism to lock the appropriate parts of your code permanently in the cache.
Ok, I didn't read this part in the document. I don't know where I get that the NVM was 0 wait stait at 120 MHz, maybe it was related to peripherals... Now I understand that 6 pixel jitter at 120 Mhz and the 1 pixel jitter at 48 mhZ. There is another extra 8KB in the memory, I will try to move the code there. Also, I think one solution to fix the jitter when it enter in the Video interrupt may be to read the SYSTICK timer and compensate for lost cycles like in an Atmega, and then write back 0 to it to read it at the next interrupt. What do you think about that? It looks like you have more experience than me with ARM MCU.

Also, one thing I'm not sure to understand in ARM vs ATMEGA, the SREG. on Atmega, we have to backup the SREG in interrupt, but I can't find any things related to this with an ARM. What I understand is the status registers(I think there is more than one status register in ARM??) are automatically backed up at the moment of interrupt, and when we clear the Interrupt flag the registers are restored?

Cedric
Post Reply