GameBoy LCD + ChipKIT Max32

Created Sat, 28 May 2011 10:23:14 +0000 by Echelon_Force

Echelon_Force

Sat, 28 May 2011 10:23:14 +0000

http://www.robotdialogs.com/2011/05/gameboy-classic-work-in-progress-part-5.html

Was a little disappointed that I could only get a pin to toggle at 719kHz... I need 4.16 Mhz to approach the hardware in the 20 year old GB...oh well.

The board was really easy to use, I had this project up and running and the AVR C code ported and optimized for Processing in one (long) night...

I was working straight out of the Multiplatform IDE you guys have on your site. Worked well on Windows 7 64bit.

I would call the board a nice step up from an Arduino, but not quite powerful enough for this project. At least not with Processing language overhead.

jasonk

Mon, 30 May 2011 18:07:34 +0000

You should be able to get better performance by bypassing the abstraction layer. See this thread.

Echelon_Force

Tue, 31 May 2011 17:50:16 +0000

I will give that a shot. I typically work directly in C in AVR Studio, so I bypass all Arduino overhead (well...all but the C compiler's overhead) by default. I was not aware the abstraction could be so easily bypassed in the Arduino IDE... I suppose I should have guessed as much though. Hopefully I can give this a try tonight.

GeneApperson

Wed, 01 Jun 2011 23:38:20 +0000

I will give that a shot. I typically work directly in C in AVR Studio, so I bypass all Arduino overhead (well...all but the C compiler's overhead) by default. I was not aware the abstraction could be so easily bypassed in the Arduino IDE... I suppose I should have guessed as much though. Hopefully I can give this a try tonight.

Similarly to using AVR Studio with the AVR based Arduino boards, you can use MPLAB with the PIC32 based boards. To do this, you would need to get a PICKit3 programmer/debugger. Header J11, (the hole pattern on the left side of the board) is the connector for attaching a PICKit3.

I used MPLAB and a PICKit3 for all of the hardware bring-up testing on the Uno32 and Max32 boards. You will get dramatically faster performance for basic i/o operations by talking directly to the hardware. The pin mapping in the Arduino hardware abstraction layer adds a lot of overhead.

Gene Apperson Digilent

svofski

Mon, 04 Jul 2011 14:17:39 +0000

I can share my "arduinoless" Makefile if you're interested, although it's not really necessary for bypassing the hardware abstraction -- for bypassing you just don't use it :) But it's a matter of convenience for us folks who won't trade vi and command line for anything else in the world.

Mark

Mon, 04 Jul 2011 15:35:17 +0000

I would call the board a nice step up from an Arduino, but not quite powerful enough for this project. At least not with Processing language overhead.

I am not sure what you mean by "Processing language overhead" If you are talking about the Arduino abstraction layer then you are quite right there is a speed penalty. But PLEASE dont call it "processing language", it is NOT processing, it is C/C++ with a library that implements SOME of the processing ideas.

WIthin MPIDE, or with Arduino, you can bypass the abstraction layer and talk directly to the hardware. Then you have NO speed penalty. For example, I have code that drives the nokia LCD display (http://www.avr-developers.com/sparkfunlcd/index.html).

If I use the abstraction layer, it is about 70% slower than if I talk to the hardware directly. I have the code set up so that if compiled for an atmega128 or atmega1280/2560 it will talk directly to the appropriate hardware. Any other chip, for example the pic32, it uses the abstraction layer. Right now, screen fill is FASTER on the atmega boards than on the pic32 board.

What does this tell us

abstraction => portability => some speed loss

direct hardware => speed => butNO portabillity, not even among chips of the same family

If you are driving LEDs, stepper motors, other real world devices, USE THE ABSTRACTION LAYER.

If you are writing graphics drivers, then you probably know a whole lot more than the average Arduino programmer, be smart, put in the appropriate #ifdefs, and make your code such that if its NOT the hardware you are developing on, revert back to the abstraction layer. Then it will work for someone else, just not as fast.

or put an #ifdef that spits out an error, i.e. for something that is only going to work on a megas2560

#if !defined(AVR_ATmega2560) #error this code is not set up to work properly on the selected CPU type #endif

This way the user will get an error and realize what is going on

Mark