Only Touch and Connect shield start shipping at 29th of april.
Is there a representative in Europe that will off these items too?
My normal supplier is Watterott in germany but I do not see these items in their webshop yet.
@ WimC
both the S65 and the MI0283QT-2 boards suffer from SPI mode in managed code. Your face will fall asleep waiting for action - even in 8-bit mode. The FEZ variant would have the advantage that it uses an 8-bit parallel interface - much faster, even in managed code.
Both the S65 and MI0283QT code be run at an adequate speed using the RLP method. There’s not much code for the standard methods and widgets.
But I liked Gus’s suggestion (especially since the shipping to Europe is so expensive) to talk to Stefan Watterott about stocking these parts, as well as a few of the other new boards.
I can say… I use the Mi0283QT-2 with my netduino and Panda II Board and the Speed is fine. I will send the example Code for both boards to Andreas Watterott and he will serve it on his website.
@ Andreas
be easier for others if the code was posted on the link Gus gave.
Speed is of course relative. I’ve tried the S65 Shield on Panda and with a PIC32 - like night and day. I’ve only used the MI0283QT-2 on PIC32 and can’t image the Panda being anywhere near it - without RLP.
Be nice to see your version.
Thanks. I have several of those MI0283QT boards and would like to salvage them for something.
Looking forward though to GHI’s new board at the end of April.
@ Andreas
Thanks for posting. Looks very promising. Had a few problems until I changed to running on external power. The GC is unusually busy. In any case, looks very promising. I’ll play with it some more. I like the way the SPI is set up - nice to see code from someone who understands the language
Looked like a power problem, but seems to be random out-of memory problem while drawing. I think I'll try a global byte buffer for some things to ease the GC running constantly.
@ Lurch
Thanks the reason seems to be, that i carry the code from the c code.
The out-of-memory problem seems to me a FEZ problem. When i run the code without vs2010 debugging, the code runs without memory issues. This is what you also said. First i used the code on a netduino board, no memory problems in any way. Now using the Panda II it throws exception. Funny, i never used the GC before, but now what i’ve read, it is strongly the main function But i like the Panda and the SDK’s from GHI !
I’ve ordered the stuff as mentioned before and hope the customer gives me the extra time.
But I’m still interested in the code and the connections.
See there is code already in the designed area, evan a complete project.
Going to study on that.
@ Andreas
Sorry for the delay. It was 23°C and sunny on the Rhein, so I went biking all day.
The speed seems to be exceptionally good. I’m afraid I was negatively influenced by the S65-Shield code posted on FEZZER. I wrongly attributed the speed to managed code. I have too little experience with it. I want to backtrack on the S65 as well and compare it to your code to see where it (or I) goes wrong.
Your project has definitely made my day. Not sure how exactly GHI controls the GC. There are probably ways to cut down the allocations by using a fixed byte array for some stuff.
Thanks again for sharing your code. Very nicely done.
I also think I’ll spend some time looking through the NetDuino website. Looks like the libs and tips there may help me.
Have a nice day!
Speed is fine. Colors OK. Fonts nice. All in all very nicely done.
I only changed the calibration to wait for tp.GetPressure < 8 between points because it occasionally skipped / jumped. May have been a jittery hand. Lots of space left for programs / widgets. Cool Rated it 5 stars.
@ Lurch
Thank you, good to know that you can use it.
Meanwhile, i added routines to store the calibration data on a sd, so calibration is only done once.
In addition i also added bmp loading and showing. images with a size of 50 x 50 are done without memory complication.
I will pack this together and update the code here in the code section the next days.
@ Andreas
Thanks. I tried an SDCard method for images and calibration data. A little bit large in deployed code, but a good exercise in C#. I was thinking of using SPI flash, but the SDCard would be better for images.
Outside of debugger mode all works very well. The debugger problems may be the same as turned up in an http project (NetConfig) being discussed in the forum. Maybe they’ll find an answer.
Happy Easter.
@ Andreas
Got sick of Easter eggs and played with the code again. Noticed that the DrawBox (and DrawCircle) consume a lot of memory for x*y ushort. Played with somewhat more complicated but smaller memory versions that were fast enough. Box doesn’t necessarily fill - so framing stuff already on the screen can be done. Unfortunately, my C background my “color” the code.
public void LCD_Box(ushort x0, ushort y0, ushort x1, ushort y1, ushort color, bool fill, ushort fillcolor)
{
int i;
int hx = x1 - x0 + 1; // how many pixels on each axis
int hy = y1 - y0 + 1;
byte[] start = { LCD_DATA };
// Draw upper and lower horizontal lines of Box
ushort[] buffer = new ushort[hx];
for (i = 0; i < hx; i++)
buffer[i] = color;
SetArea(x0, y0, x1, y0);
StartDrawing();
_SPI.Write(start);
_SPI.Write(buffer);
StopDrawing();
SetArea(x0, y1, x1, y1);
StartDrawing();
_SPI.Write(start);
_SPI.Write(buffer);
StopDrawing();
if (fill)
{
for (i = 0; i < hx; i++)
buffer[i] = fillcolor;
buffer[0] = color;
buffer[hx-1] = color;
SetArea(x0, (ushort)(y0+1), x1, (ushort)(y1-1));
StartDrawing();
_SPI.Write(start);
for (i = 0; i < hy - 2; i++)
{
_SPI.Write(buffer);
}
StopDrawing();
}
else
{
buffer = null;
// Draw left and right vertical lines of Box
ushort[] buff = new ushort[hy];
for (i = 0; i < hy; i++)
buff[i] = color;
SetArea(x0, y0, x0, y1);
StartDrawing();
_SPI.Write(start);
_SPI.Write(buff);
StopDrawing();
SetArea(x1, y0, x1, y1);
StartDrawing();
_SPI.Write(start);
_SPI.Write(buff);
StopDrawing();
buff = null;
}
}
My Panda’s (I & II) can breathe better with this. Circle is still too slow. Need better math for that.
@ Lurch
You are right, the Code is Perfect. I always thought spi writing is the bottleneck.
I will transfer this in my code and will optimize all a little bit more.