Home→Forums→MonoBrick EV3 Firmware→Brick-Simulator?
- This topic has 27 replies, 3 voices, and was last updated 10 years, 10 months ago by Martin Wagner.
-
AuthorPosts
-
January 7, 2014 at 17:33 #3797
Martin WagnerParticipantHi 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
January 7, 2014 at 19:40 #3801
Anders SøborgKeymasterHi 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
January 7, 2014 at 22:07 #3802
Martin WagnerParticipantHi 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,
MartinJanuary 10, 2014 at 23:42 #3825
Martin WagnerParticipantHi 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 elements2. 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,
MartinP.S.: Sample of how I should do it would be the best.
January 11, 2014 at 08:15 #3826
Martin WagnerParticipantHi 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.January 12, 2014 at 00:13 #3827
Martin WagnerParticipantHi 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,
MartinP.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?
January 12, 2014 at 00:16 #3828
Martin WagnerParticipantSecond try with files
Attachments:
You must be logged in to view attached files.January 12, 2014 at 13:01 #3830
Martin WagnerParticipantHi 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 //SingletonStuffCan one of the mono experts have a look at it?
Thanks,
MartinJanuary 12, 2014 at 20:08 #3832
Anders SøborgKeymasterHi Martin
I will have a look at it tomorrow – thanks for the effort so far…
Anders
January 13, 2014 at 00:10 #3835
Martin WagnerParticipantHi Anders,
code update (buttonHAL fixed, LcdHAL created). I am struggling with the binding of Lcd to WPF.
Good night,
MartinAttachments:
You must be logged in to view attached files.January 13, 2014 at 19:16 #3839
Anders SøborgKeymasterHi 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
January 13, 2014 at 23:03 #3840
Martin WagnerParticipantHi 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 MWBug or feature that I miss? Shouldn’t it be
public const int bytesPrLine = Width*(1+7)/8; // This doesn’t work eitherDo you have any suggestion how to convert dispBuffer in an standard Image or BitmapImage?
Any help would be great,
MartinJanuary 14, 2014 at 00:08 #3841
Martin WagnerParticipantIt’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,
MartinJanuary 14, 2014 at 21:57 #3842
Anders SøborgKeymasterHi 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
January 16, 2014 at 00:31 #3849
Martin WagnerParticipantHi 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,
MartinAttachments:
You must be logged in to view attached files. -
AuthorPosts
You must be logged in to reply to this topic.
Follow