Thinking about STMUzebox

[hpglow]

I will give Yagarto a shot. I'm still trying to figure out how to get Attolic how to compile a project. I may just need to download a working project from somewhere and use it as a template for now.

I ran the 5V to pin 9 nothing new happened (not supprised.) I think I just need a re-compile with the f4 discovery libraries.

[filipe]

I received my board too, the STM32F4DISCOVERY and will try it out soon. In the meanwhile I'm looking for a tool chain. Which one did you use? All of those recommended by ST are expensive commercial packages with limited trial versions. Only Atollic TrueStudio seems to offer a free "Light" version that is not too limited. But it doesn't support advanced debug options or even C++, which kinda limit it's appeal. Is there a relatively easy to set-up open source tool chain you are aware of for the STM32F4?
-Uze

I've been using Keil MDK. It is for ARM what AVR-Studio is for Atmel.
There is a "lite" version for free which imposes a 32KB binary limit, but now, there is no limit using GCC.
http://www.keil.com/

I didn't try yet, but NXP has a nice IDE (eclipse based): http://ics.nxp.com/lpcxpresso/
A dev board+jtag costs ~£20 (LPC1768/9)

-Filipe

[TonyD]

I've used Keil with GCC for my ARMee LCP2106 project back in 2005 and it worked well.
CrossWorks for ARM from Rowley Associates is a nice ARM development system I've used in the past. There have a personal / non-commercial licence for $150

[Harty123]

another interesting GNU based development system for ARM cortex (and also AVR) is COOCOX:

http://www.coocox.com/

-Harty

[hpglow]

I downloaded Keil, it works fairly well. I haven't switchted it over to use the gnu compiler yet. I haven't gotten the tutorial to compile yet, because there are some differences between the F1 and F4 standard perephreal libraries that have caused some errors. For instance the compiler tells me that GPIOA has no field named BRR, and there are a list of such errors that means I'm going to have to take a little time and look through the .c .h and see if I can figure out what they were renamed to.

EDIT: I cleared all the compiler errors and now I am getting a bunch of linker errors. Also I found out about the binary compatibility. It only exists for the F2 series, meaning the F4 is pin and binary compatible with F2 not the F1. Which is why it didn't work when I tried to load the before mentioned .hex file.

[filipe]

Have you thought about how to render the pixels? Uzebox uses assembly for time accuracy, but that is not so easy with Cortex-M3. Some instructions have variable cycles and if you chose to run from RAM, you might get some wait-states as the bus is being shared with data.

I was checking how the guys from mbedgc are doing. They are using a framebuffer . The resolution for their demo is 53x242 which means their are already using ~12.5KB of RAM for a very small screen

Cheers,
-Filipe

[hpglow]

From what I gather from what Vasek has said. The renderer uses the hardware timers and interupts to time the video signal, which has to be written in ASM to keep the timing strict. From what I could tell, one row of pixes is buffered to the ram at a time.

[vaclavpe]

Have you thought about how to render the pixels? Uzebox uses assembly for time accuracy

Hi, my idea was to take ASM code generated by GCC compiler from the render routine currently in C-language. And restructure it a little bit to be cycle accurate. GCC 4.6.0 (yagarto) gave me better results than older GCC.

Currently I am porting Megatris to see some more interesting results. But if you had a look in STMuzebox SVN, more functions are missing. So I need to add them (for sound, functions will be just stubs).

There is one thing I noticed. There is SetFontTable() and SetTileTable(). I currently have it wrong in my code as I don't perfectly understand the real difference. Does SetFont() copy font to tile table?

[uze6666]

There is one thing I noticed. There is SetFontTable() and SetTileTable(). I currently have it wrong in my code as I don't perfectly understand the real difference. Does SetFont() copy font to tile table?

SetFontTable() is used only for mode1 if I recall. This is because Mode1 uses a 16bit pointer-offset-to-tile based VRAM (if I recall, have to check to confirm). It basically allow two simultaneous banks of tiles to be used at once by the API. One for the regular tiles (SetTileTable) and the other for Print/font operations. Other video modes based on 8-bit indexes uses the SetFontTileIndex instead to indicate the first font tile in the tile set. SetFont will just like SetTile but uses the font base address.

Btw, I think that it would be a good idea to define some target specs before moving forward too much. I know vaclavpe you are using the M3 currently, but I wondering why not use the M4 (STM32F4)? When I saw the spec, I got that same warm feeling that when I saw the ATMega644, a powerful chip with lots of RAM at an awesome price.

-Uze

[vaclavpe]

Btw, I think that it would be a good idea to define some target specs before moving forward too much. I know vaclavpe you are using the M3 currently, but I wondering why not use the M4 (STM32F4)? When I saw the spec, I got that same warm feeling that when I saw the ATMega644, a powerful chip with lots of RAM at an awesome price.

Hi UZE, I have several reasons to use STM32F103. F4 line exists now just as the Discovery kit. No MCU available at Farnell so far. No samples at ST.COM so far. I already have a lot of kits - for PIC16, PIC32, STM8, MSP430 Launchpad etc. And for STM32F1 as well. Recently we with my friend developed FDC emulator for one 8-bit computer ( you can find it here http://mz800ukp1.sf.net/ ). First version was with ATMEGA64 and I finally decided to run it on STM32. STMuzebox is just a means to evaluate MCU's power (in the FDC emu, STM32 was about 2 times faster than ATMEGA). And finally, I have tuned the toolchain and it works for me.

Another MCUs to evaluate Uzebox can be PIC32, LPC, LM3S - but I have chosen STM32F1. Just for my personal interest. From other projects I learned that less than small amount of people is interested what I do or I did. So I just play with STM32 and would be glad if somebody can continue with me. That is all...

If somebody takes Uzebox and ports it to STM32F4, it will be great.