I finished off everything to make PicoMax run on the Seeed OLED and went to address the FEZ Touch for Panda II, which looks like it’s discontinued and also won’t work for 4.2.
My question is if PicoMax is even still needed then if it’s just for the OLED. Anyone really looking to run it on Cerb or other low powered devices?
It’s got a lot of really nice features, but with only the one supported issue I’m thinking maybe I shelf it and go back to focusing on Tinkr (the replacement for .NET Clix).
@ Skewworks - I think a graphics library for Cerb could be very helpful, but assuming this is something you’re planning to sell, I have no notion of whether it would actually sell enough to make the remaining effort worthwhile. It would be nice to have a higher-perf way of addressing the Seeed OLED on Cerberus/Cerbuino, though.
The effort has already been done, and while I would charge for a complete solution with controls and all the bells and whistles I find
Don’t really want to release another product that is targeted very specifically (ie Spiral)
I’m never going to charge for drivers, no matter how complicated they might be.
So I’m thinking, perhaps I’ll release PicoBitmap, PicoFont, the Font Creator (yes it has variable font width and easy 1 click generation for a truetype font), and the driver to flush it all to the screen free on CodeShare.
Hi, the sample code will not compile. It is missing the skewworks circle.ico resource, as well as has these compile time errors.
Warning 1 Could not read state file “obj\Release\TinyCLR_DebugReferences.cache”. Exception has been thrown by the target of an invocation. PicoMaxPureMFDemo
Warning 2 Could not read state file “obj\Release\TinyCLR_DebugReferences.cache”. Exception has been thrown by the target of an invocation. PicoMaxPureMFDemo
Error 3 Error generating Win32 resource: Error reading icon ‘C:\Users\Mac\Documents\Microsoft .NET Micro Framework 4.2\Samples\picomax-21964\PicoFontCreator\Skewworks Circle.ico’ – The system cannot find the file specified. C:\Users\Mac\Documents\Microsoft .NET Micro Framework 4.2\Samples\picomax-21964\PicoFontCreator\obj\x86\Release\PicoFontCreator.exe PicoFontCreator
Warning 4 Could not read state file “obj\Release\TinyCLR_DebugReferences.cache”. Exception has been thrown by the target of an invocation. PicoMaxPureMFDemo
Warning 5 Could not read state file “obj\Release\TinyCLR_DebugReferences.cache”. Exception has been thrown by the target of an invocation. PicoMaxPureMFDemo
@ Skewworks - This is an amazing contribution! There does seem to be a licensing conflict, your code share is licensed under Apache 2.0 however the code comments indicate GPL 3.0. Could you clarify which license applies?
@ taylorza - hazards of having it in multiple places. It WAS CPL but I changed it for Microsoft. All the headers should be updated in codeplex. I’ll get everything down an do any needed updates later this afternoon.
I’m getting a strange and inconsistent deployment error when trying to run the PicoMaxGadgeteerDemo project. Most of the time, I’m getting an out of memory exception on the first line in PicoBitMap.cs
public PicoBitmap(int Width, int Height)
{
_data = new byte[Width * Height * 2];
_w = Width;
_h = Height;
_clipRegion = new Rect(0, 0, _w, _h);
}
Strangely, I can delete the " * 2", recompile, add it back and recompile and it will sometimes work. Other times, it won’t.
I’m trying to run this on a Cerberus with 4.2 QFE2.
Anyone else seeing this?
Debug output below.
Assembly: mscorlib (4.2.0.0) Assembly: Microsoft.SPOT.Native (4.2.0.0) Assembly: Microsoft.SPOT.Hardware (4.2.0.0)
Assembly: Microsoft.SPOT.Graphics (4.2.0.0) Assembly: Microsoft.SPOT.TinyCore (4.2.0.0)
Assembly: Microsoft.SPOT.Hardware.SerialPort (4.2.0.0) Assembly: Microsoft.SPOT.IO (4.2.0.0)
Assembly: System.IO (4.2.0.0) Assembly: Microsoft.SPOT.Hardware.OneWire (4.2.0.0)
Assembly: Microsoft.SPOT.Hardware.Usb (4.2.0.0) Assembly: Microsoft.SPOT.Hardware.PWM (4.2.0.1)
Assembly: Microsoft.SPOT.Net (4.2.0.0) Assembly: System (4.2.0.0) Loading Deployment Assemblies.
Attaching deployed file.
Assembly: Microsoft.SPOT.Net.Security (4.2.0.0) Attaching deployed file.
Assembly: Gadgeteer (2.42.0.0) Attaching deployed file.
Assembly: GTM.Seeed.OledDisplay (1.5.3.0) Attaching deployed file.
Assembly: GHIElectronics.Gadgeteer.FEZCerberus (1.1.1.0) Attaching deployed file.
Assembly: Microsoft.SPOT.Touch (4.2.0.0) Attaching deployed file.
Assembly: Gadgeteer.Serial (2.42.0.0) Attaching deployed file.
Assembly: GHI.OSHW.Hardware (4.2.3.0) Attaching deployed file.
Assembly: PicoMaxGadgeteerDemo (1.0.0.0) Attaching deployed file.
Assembly: System.Net.Security (4.2.0.0) Attaching deployed file.
Assembly: System.Http (4.2.0.0) Attaching deployed file.
Assembly: PicoMax (1.0.0.0) Attaching deployed file.
Assembly: Gadgeteer.SPI (2.42.0.0) Resolving.
The debugging target runtime is loading the application assemblies and starting execution.
Ready.
<removed debugging symbols loading for brevity>
The thread '<No Name>' (0x2) has exited with code 0 (0x0).
Using mainboard GHI Electronics FEZCerberus version 1.1
Failed allocation for 2733 blocks, 32796 bytes
Failed allocation for 2733 blocks, 32796 bytes
A first chance exception of type 'System.OutOfMemoryException' occurred in PicoMax.dll
An unhandled exception of type 'System.OutOfMemoryException' occurred in PicoMax.dll
The program '[9] Micro Framework application: Managed' has exited with code 0 (0x0).
There should be a note in the docs about this. Running attached to the debugger has inconsistent memory useage that can cause failure. Restart device sans visual studio and it should work 100% of the time. Please let me know of you Encounter otherwise. I’ll double check the note is in the docs and make it more prominent.
Thanks - I didn’t see the note. I did have a little trouble getting it to deploy (unrelated) but once it has, it appears to be working.
I’m going to try putting it in my project and use compiler directives to not send anything to the OLED in debug mode. Should make for a bit more time in debugging the display, but shouldn’t be too bad.
Will let you know if I run into anything else wonky.
The memory issue is VS’ fault not PicoMax; there’s nothing I can do on that front. Best I can suggest keep it to 1 image and 1 font if you’re going to have the debugger attached.
Gotchya - was thinking it could be a combination of the available memory on the board + PicoMax, but if there’s nothing else you can do, it is what it is.
I’m only using one image, although I’m writing over that image multiple times, but it seems to blow up on the first call to creating the PicoBitmap itself.
Will see if moving around where I create the Bitmap will make a difference.
Otherwise, seems to work great when it’s running outside of debug.
