Brick-Simulator?

[Martin Wagner]

Hi Anders,
working on that GiroBoy-thread approach I am having problems with not reacting buttons on the EV3 and (currently) no debugging possibilities (to find logic errors). I found myself writing a small forms application to simulate button presses and a textbox as lcd, but with strong doubts whether this would behave similar to the brick. I am looking for my logical errors especially towards threads, events and co.

Then I was digging through the MonoBrick-Repository to find the spots in your code to place hooks to get as close as possible to the real thing, but I got lost since I am not familiar with C#.

Do you think it’s possible to write a Brick-Simulation-Gui that is driven by a modified MonoBrick-DLL (maybe the same code with compiler switches)? It surely would not give real-time answers, but should behave “thread-wise” as the original. It would be great, if you could use all the standard (VS) debugging features to track down your logic errors and when done, then tackle the dynamic questions on the brick itself (e.g. with recording to memory and file as you mentioned).

If you take me by the hand and point the direction, I guess I could try to work on that. Since it would be probably a WPF implementation, this would be a good way to get familiar with this.

What to you think? Or do you say: Oh, by the way, it’s already/almost done, I just didn’t publish it yet? 😉

Martin

[Anders Søborg]

Hi again

If you are to write a simulator have a look at lib c implementation every class that uses this file should somehow be replaced by “simulation class”… I think there is a lot of work to get this working. But buttons might be the first place to start. Look at the UserInput namespace

Anders

[Martin Wagner]

Hi Anders,
I’ll start digging into WPF and your code when possible. But it will take some time since my vacation is over tomorrow. I’ll get back to you when I got questions or a first suggestion.
CU,
Martin

[Martin Wagner]

Hi Anders,
I have spent some time in different implementations of the buttons.cs, … and I need your opinion:

1. Interface with EV3- and Simu-Implementation
+ object oriented,
– a lot of changes, high coding effort, EV3 version contains simu code and data objects for binding of WPF elements

2. Global Boolean with If … else … endif
+ simple
– EV3 version contains simu code, overview over e.g. all EV3 codes only via ‘Find all references’

3. Compilation symbol with #If … #else … #endif
+ simple, clean code for each version
– overview over e.g. all EV3 codes only via ‘Find all references’

I would prefer the third way because you see the differences directly in the context of the surrounding functional code. I think this is more important than the overview of all e.g. simu code in one spot, but the code is more difficult to read.

What do you recommend? What fits best to your programming style and is better for code maintenance?
Thanks for any comments,
Martin

P.S.: Sample of how I should do it would be the best.

[Martin Wagner]

Hi Anders,
sleeping over: It can only by the first approach. I am just having problems with C# as a VB.Net-guy. It would be great if you could post a short code sample of how the hardware abstraction layer should look like (a mini interface, Ev3 and Simu implementation with , just new and dispose). Then I could keep going in your style.
I’ll keep going,
Martin
P.S.: I guess buttons, lcd, sound should be singletons, the rest can have multiple instances.

[Martin Wagner]

Hi Anders,

I think that now I have something that gets the best of all: A HAL class with two code blocks (real and simu), controlled by a compiler switch. After making the HAL class a singleton it even seems to work for the buttons. ;-).
The display will be the next.

What do you think?
Till soon,
Martin

P.S.: I can’t implement the led, because I don’t no the meaning of the pattern integer. Is there a documentation which parts of the integer control color, blinking and on/off?

[Martin Wagner]

Second try with files

Attachments:

You must be logged in to view attached files.

[Martin Wagner]

Hi Anders,
sorry, the singleton implementation is DotNet4 stuff and I don’t know whether it runs in Mono.
(Source: http://geekswithblogs.net/BlackRabbitCoder/archive/2010/05/19/c-system.lazylttgt-and-the-singleton-design-pattern.aspx)

#region SingletonStuff
// ensures that only one instance of this class can exist, so everybody writes and reads the same variables
private ButtonHAL() { } // hiding creator

// static holder for instance, need to use lambda to construct since constructor private (DotNet4 only)
private static readonly Lazy<ButtonHAL> _instance = new Lazy<ButtonHAL>(() => new ButtonHAL());

// accessor for instance
public static ButtonHAL GetSingleton { get { return _instance.Value; } }
#endregion //SingletonStuff

Can one of the mono experts have a look at it?

Thanks,
Martin

[Anders Søborg]

Hi Martin

I will have a look at it tomorrow – thanks for the effort so far…

Anders

[Martin Wagner]

Hi Anders,
code update (buttonHAL fixed, LcdHAL created). I am struggling with the binding of Lcd to WPF.
Good night,
Martin

Attachments:

You must be logged in to view attached files.

[Anders Søborg]

Hi Martin

Everything looks good – We are using Mono Version 2.10 (we will update at some point but this requires a new Linux kernel hence a new image). Mono 2.10 has support for .NET 4.0. Let me know how it goes – maybe a screen shot 🙂

Anders

[Martin Wagner]

Hi Anders,
still fighting with Lcd: I cannot convert the byte-array to an image/bitmap.
Since Width=178 and Height=128, why is the dispbuffer-size = 2944 bytes, when 178*128/8 = 2848 bytes?

In all the information I found, the stride(bytes per line) is calculated
stride = width*(BitsPerPixel + 7)/8 with BitsPerPixel=1 (monochrom) I guess. Or is it a color bitmap?? (The code has color calculations.)

In lcd.cs it is:
public const int Width = 178;
public const int Height = 128;
public const int bytesPrLine = (Width+7)/8; // changed to public MW

Bug or feature that I miss? Shouldn’t it be
public const int bytesPrLine = Width*(1+7)/8; // This doesn’t work either

Do you have any suggestion how to convert dispBuffer in an standard Image or BitmapImage?

Any help would be great,
Martin

[Martin Wagner]

It’s just too late in the night.
I am wrong, e.g. see http://msdn.microsoft.com/en-us/library/system.windows.media.imaging.bitmapsource%28v=vs.110%29.aspx, section examples. And, yes it must be a BlackWhite bitmap.
It’s just converted to colors for the export.

I still don’t get the byte array converted to an image, but at least this works:
Dim p As String = “C:\Users\Martin\Documents\Visual Studio 2013\Projects\MonoBrick\Ev3Simu\TestProg”
Dim ml As New Lcd
ml.WriteText(Font.SmallFont, New Point(10, 10), “I am on the screen”, True)
LcdConsole.WriteLine(“Not visible”)
ml.Update()
ml.TakeScreenShot(p)

Although LcdConsole.Writeline does not work, it seems to write to a different instance of lcd.
private class ConsoleWriter
{
Lcd lcd = new Lcd();
Font f = Font.SmallFont;
Or is it not allowed to mix lcd and LcdConsole?

Good night,
Martin

[Anders Søborg]

Hi Matin

I think your project is really exciting.

still fighting with Lcd: I cannot convert the byte-array to an image/bitmap.
Since Width=178 and Height=128, why is the dispbuffer-size = 2944 bytes, when 178*128/8 = 2848 bytes?

The buffer size is not 2944 since each pixel is masked. bytesPrLine=(178+7)/8 = 23. So the buffer is 23*128=4096. This is taken from the following code:

public const int Width = 178;
public const int Height = 128;
const int bytesPrLine = (Width+7)/8;
const int bufferSize = bytesPrLine * Height;
const int hwBufferLineSize = 60;
const int hwBufferSize = hwBufferLineSize*Height; 

Also you should have a look at the set and get pixel functions…

Maybe I don’t understand your question

Anders

[Martin Wagner]

Hi Anders,

could spent some time on it again.
I finally managed to get something on the screen, inverted colors and corrupted pixels (see screenshot). It should read: “I am on the screen”

I’ll get back, when there’s more to talk about.
Good night,
Martin

Attachments:

You must be logged in to view attached files.

[Author]

Posts