Mogd# crashed while uploading font

[niston]

Mogd# crashed on me while I was uploading a font to the display (id 7).
It must have corrupted something, because now I can't overwrite the font (id 7) anymore.

Any way to fix this?

Also, is there an inverted version of the font "clear"?
Using the "invert font" option in Mogd# produces either unreadable text (no char spacing) or a discontinuous background (char spacing > 0).

TIA

[Raquel]

Hi TIA,

Thank you for posting in the forum.

I am not sure why your display will not upload anymore to the same slot. Have you tried uploading font to a different slot?
I deliberately interrupted a font upload to see if I can replicate, but (un)fortunately I was able to upload to the same slot again.
If you still have all the fonts and bitmaps you need, I suggest that you wipe the filesystem and start uploading the files again.

If I may ask you to watch out on how mogd# crashed so I can try it here and debug.

As per the inverted clear font, you will need to have a background with all pixels on (white for WB displays, black for YG,FGW displays) in order to see the inverted font properly.
Try drawing a filled rectangle then send the text.

Please let me know if these help.

[niston]

Hi Raquel,

Name's actually Chris, I meant thanks in advance :P

Anyways, the crash was exactly as described in my other thread: http://www.lcdforums.com/forums/viewtop ... f=1&t=6582. So I conclude that either my development machine has a faulty USB subsystem (funny though, everything else works fine), or that there is indeed a nasty bug in the 64bit version of the Wintendo FTDI driver...

In any way, I was able to upload to another slot. Haven't tried slot 7 since, and I'm currently reluctant to do so as I urgently need a functioning device tomorrow ;-)

Concerning the inverted clear font: Yeah, I also had the idea of drawing a rectangle into the background. But: clear is a proportional font. This means I will need a way to measure how long (pixels in X dimension) my text exactly is gonna be in a particular font, so I can draw background accordingly. I figure I could do this by parsing the font files since the width information for each individual character is stored there.

However, on the occasion, I might as well ask you to provide a command that takes a string (text) and a font id, and returns how long the string in pixels will be? This would also eliminate the nasty problem of the host not really knowing which font is in what slot on the display.

Something else I wish for: Some way to disable the auto CrLf at the end of a line, especially in labels. So that text is just simply cut off at the end of label/line.

[Raquel]

Hi Chris,

:) you are welcome for the 'TIA'

I will leave Troy with you on the problem (perhaps) regarding drivers.
As per your request regarding string extents where you will provide your string and the font id and the display will respond with the width and the height - I can look into that.
As per labels, I have tried sending characters that go beyond the width of a defined label, and I see text being cut off. I am not sure what you mean with auto CRLF.
Can you please give an example so that I may be able to try?

Thanks,
Raquel

[Clark]

Hi Chris,

We've had no trouble with the 64bit version of the FTDI drivers, yet. However, once you're able to send your code over, I'll be happy to take a look.

As for the carriage return + line feed behaviour, it should not occur for labels and can be turned off for text by setting Auto Scroll off. Given your inverted, variable width font and string length, you might find a label with a background parameter of 1 most useful. If you can provide a few more details we can look into that and the string extents feature.

Finally, when you do get a chance to look into the font issue further, I would recommend wiping the file system and starting your uploads from scratch. It is possible for corruption to occur when overwriting an existing font, so the safest method is to start from scratch, when you are able.

Cheers,
Troy

[niston]

As promised earlier, here's my code:

https://sirp.codeplex.com/

Holler at me if you need help setting it up :)

[Clark]

Hi Chris,

Much appreciated, thanks!

I'm having some trouble with the following line in the AudioStreamer.cs file, the exception reads "Unable to load DLL 'bass.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)".

Code: Select all

Bass.BASS_PluginLoadDirectory(Environment.CurrentDirectory + dirSep + "codecs" + dirSep);

Cheers,
Troy

[niston]

You need to get the BASS Audio Library from http://www.un4seen.com/bass.html. If you have it, copy the bass.dll to the folder where sirp.exe resides. For me, that's usually the \bin\Debug folder. Also create a codecs folder there and optionally put any BASS plugins, the AAC one perhaps, into the codecs folder.

[Clark]

That was the ticket, thanks Chris!

I'm a little further, but I'm stuck at another dll, this time 'bassmix.dll' at the line below.

Code: Select all

_MixerStream = BassMix.BASS_Mixer_StreamCreate(sampleRate, numberOfChannels, BASSFlag.BASS_MIXER_NONSTOP | (FloatingPointSupport ? BASSFlag.BASS_SAMPLE_FLOAT : 0));

Cheers,
Troy

[niston]

Hi Troy,

Sorry for late reply, I was out on the road.
Yeah, the notorious BassMIX ;-)
It's a BASS addon that can be downloaded from http://www.un4seen.com/bass.html#addons. Just put it in the same folder with sirp.exe.

I edited the documentation page on codeplex to reflect these requirements.

[Clark]

Hi Chris,

I'm up and running, thanks again.

I have observed two System.UnauthorizedAccessException: 'Access to the port is denied' exceptions, and have now setup a break point on your System.IO.IOException catch. I'll let you know what I find.

Cheers,
Troy

[niston]

The funny thing is, this doesn't happen on Linux/mono.
I have not yet come around to try on my 32bit Windows netbook.

[Clark]

Chris,

This is a funny one indeed.

I added a catch for the Unauthorized Access Exception to your send function in SerialIO.cs, in the same manner as the existing IO Exception catch, and put breakpoints on both to try to start tracking down the source of the error this morning. Unfortunately, everything is still running as of this afternoon. No exceptions thrown, and the program is working perfectly. Strange.

Please let me know what you find with 32bit Windows, I'll keep plugging away at it from this end as well.

Cheers,
Troy

[Clark]

Chris,

Unfortunately, at least for this issue, my unit has been running well all weekend and so far this week, without raising any exceptions. If you find anything more on your end please let me know.

Cheers,
Troy