Graphics/USBizi

I’m a little confused by one of the statements in the Beginners e-book. In the section, “Native-support on non-standard display” for LCDs, it says, “USBizi doesn’t support graphics”, and I can only use the Bitmap class if it’s supported for the device (in my case, a FEZ Panda).

Why is this? I understand that the RAM requirements for large displays is beyond the capabilities of the Panda, but if I want to run a little B&W 128x64 display, and have all the nice features of the Bitmap class (such as drawing lines, ellipses, etc), do I have any options?

Thanks,
Paul

I think in the ebook, they are referring to WPF and colour LCD’s…

I run a 128x64 B&W graphical display on a Panda… You cant use the bitmap class, but if browse through fezzer and the netduino forums and you’ll find one…

I use a glyph( sort of an icon) 16x16 bitmap on my crane remote control… Its the same as drawing text, but it works for me.

Cheers Ian

The graphics support on netmf is complete and very powerful but it is more than any single chipset can handle. Now, you can still connect displays all you like and draw graphics like you do with any other micro, over SPI bus fir example.

We already provide display boards and provide the code to do fonts and shapes

Ok, so help me understand this. If I try to create a Bitmap object on my Panda, I get a “System.NotSupportedException” thrown.

What code is responsible for deciding that Bitmap is not supported? (or in other words, what code actually throws the exception) ?

I currently have code running that writes text and draws simple shapes (it even displays simple, contrived .bmp files loaded from an SD card) to my 128x64 display, but it seems like the code I’m writing essentially duplicates the functionality of what’s provided by the Bitmap class.

And similarly, the driver code provided by GHI for the 128x64 SPI displays does a lot of the same things as Bitmap (as far as drawing). Why can’t we just use Bitmap?

I hope my question makes sense…

Paul

The presentation library is written in the internal core in C++. If you try to use it on system that do nto have it, you get “not supported” exception.

The Bitmap class is a part of a much larger system for graphics (presentation), in which doesn’t fit on a single chipset (USBizi). Systems that support bitmap (part of presentation lib), like EMX, have megabytes of RAM/FLASH.

Another thing here is the runtime RAM usage. When you write your own code, not depending on bitmap class, you can decide how to manage resources to fit your needs. The 60KB of RAM found on these small devices can do a lot of amazing things if managed properly.

Finally, not all users need graphics on those small system, actually most of them do not. It would be a bad idea for GHI add something internally that use more of the precious resources. Leaving it out, make the resources more configurable.

We work very close with many users and always try to come to the best common grounds to everyone, the ones that need graphics and the ones that do not. So, even though we didn’t include graphics internally, we still explained it in the book and gave you all source code you need to do graphics :slight_smile: … and provided a ready to run display board too :slight_smile:

Don’t get me wrong. I’m not complaining about anything. I’m thrilled with everything that is available, but still trying to figure out how all the bits and pieces fit together.

Thanks for the info. Makes perfect sense now.

I was only trying to explain in details :slight_smile: Maybe I over-explained