Regaining boot screen platform independence about ironos

[Ralim]

Hi, the program converts your bitmap into the orientation and alignment to suite the oled screen which dramatically removes complexity on the iron. So it's not just making a 1 bit bitmap. Though I agree it's complete overkill. You can run the program under mac and linux using mono. It's also a one time deal (keep the .hex file for future use). In the future it will compile fully for Mac and Linux but I haven't tried those yet.

I know it's complete overkill, but adding in the usb emulation takes up more room on the microcontroller than is left, because I'm using the free open source compilers (gcc). The original firmware could only fit it due to the use of the paid compiler tool chain from iar. As it's better at optimising. I cannot use this on my pc as I do not have a licence of it (costs around $4-5k per year).

At the moment I'm looking into making a python equivalent so at least it's better at crossplatform operation.

Basically at this point I do not have the money to spare on a compiler, as well as the hundred or so hours to implement a virtual flash drive just to support a boot up logo.

If you are on osx and dont want to use mono to run the program, just email me or post it here and I'll convert it for you happily. :)

Plus, even the usb emulation is actually hard to do correctly, just look at all the systems that have issues with the DFU bootloader on the chip already.

[JoshuaACNewman]

Really interesting! Thanks!

I'm trying out Mono, but it's outside my field, and it's giving me an error. Thanks for the offer to output my icon, but I don't want to ask you to run around for me! I'm enjoying your work developing for this tightly constrained environment. I'm happy to wait until it's cross-platform.

[Ralim]

No problem, sorry I can't give a magic answer about this.
It was a design choice I had to make early on sadly.

Honestly, im happy to convert files at the moment for people who are stuck without an easy means to convert the file. Since cross platform could be a bit further away as its not a big priority as of yet.

[thanks4opensource]

@Ralim
You mentioned above doing a Python equivalent of the Logo Editor. Would you like me to take a try at writing that?

I looked at Form1.cs and despite being C# (right? I don't even know that) (and I'll be honest about my anti-anything-that's-not-Linux prejudices) it looks very straightforward. I'd use PIL -- the Python Imaging Library which I have a lot of experience with -- for reading JPEG/BMP/PNG/PPM/anything input images and downsampling/grayscaling them, and I just now found a Python Intel Hex library which should work for writing. Python has everything! ;)

Note this would strictly be a command-line only utility:

$ ts100_logo_editor.py <name-of-input-image-file> <name-of-output-hex-file> [--preview=<optional_preview_output_file>]

So Windows and particularly Mac users would hate it, but at least they'd have a fallback they could use by opening a DOS shell on Windows or a Bash terminal on Mac. No GUI file chooser, no display of preview image (use an independent image-viewing app), no nothing -- just get the job done.

Not sure where I'd fit it in with my other commitments or when I'd get to it, but if you're interested I'll try and send you the results. You can always drag it to your Windows "Trash Bin" if you don't like it. ;) I don't personally have much need for this (I'm happy without having a custom logo) but maybe it could be my small contribution to the project after asking so many questions. ;)

[Ralim]

Please do, I haven't had time to even look at it, at the moment.

Yes indeed it is C#, I code under mono most of the time these days on Linux, but just never really liked python much. 😕

No one would hate it 😄 I mostly provided a GUI because it was easy to do at the time for most users.

The main things to be aware of are :

• The intel hex must have a width of 16 bytes per line
• The intel hex file must be over ~1KB (which is why I actually repeat its contents in my generated file)
• Watch out for comparing pixels for thresholding :) And probably provide a means to invert the output.
• Remember the screen is setup with a 1 being a white pixel and 0 being black

Should be quite doable, and can compare output with the C# tool as well :)

[JoshuaACNewman]

On MacOS, the preview would be generated as soon as you looked at it. And I think anyone who cares about this kind of thing is going to be comfortable making a 1-bit image and orienting it appropriately, anyway. The only real concern is knowing how to add it to the firmware code.

Furthermore, you can get the file path in MacOS simply by dropping a file onto the term window. So a command line program, while probably not ok for other applications, won't be particularly hard to use — particularly for a user who's hacking a soldering iron.

[thanks4opensource]

Thanks for the info. I'll take a crack at doing the Python translation.

@Ralim, your C# code is very clear, clean, and well-documented. Your meta-comments, above, are also very helpful -- I was confused as to why btnSaveHex_Click() was allocating 1024 bytes for 16*96 pixel image encoded at 1-bit-per-pixel == 192 bytes. I'll add an "invert" option, and another to switch between the original (r+g+b)/3 > 128 thresholding and a more standard color-to-luminance-to-black&white transform (sorry, I've done a lot of work in that field). If the Python IntelHex module can't do 16 bytes per line I'll do some workaround (fix the source code, post-process the output, something) or just port your IntelHex.cs, although that's bigger than the actual conversion code. :)

Because of the thresholding, plus the fact that different JPEG decoders can output slightly different RGB values, the Python output might not be byte-identical to the C#. Very close, but not exact. So I'm thinking about including a "reverse" option (Intel hex to BMP or something) so the results can be checked visually.

@JoshuaACNewman, agree that most people doing this should be comfortable resizing and transforming images. The non-standard part is putting it into Intel hex format -- I've never seen an image-editing program that outputs that, much less in this specific bit/byte schema. So some kind of custom utility program is needed.

[thanks4opensource]

I've got the Python port of the TS100 Logo Editor mostly working. Could someone post and attach an image file and matching Intel hex format output so I can see if I'm doing it right? (I can't run the C# version myself -- that's the whole reason for this exercise).
Mostly not sure if the Python IntelHex library can output the correct type of Address Record, but also want to check the pixel/byte/bit formatting. Thanks.

[sreichholf]

sure, here's my bootlogo in png and hex

flashable.zip

[thanks4opensource]

Thanks, @sreichholf . That's exactly what I needed.

Looks like the Python lib will only do RECTYP 03 Start Segment Address Record or 05 Start Linear Address Record, and @Ralim wants 04 Extended Linear Address Record. :(

I'll figure something out. Maybe post-process the Python data, or fix the lib, or just port Ralim's original C# Intel hex generation code.

Thanks again for the example.

[Ralim]

@thanks4opensource Yeah, there are a lot of different ways to get to the same goal with intel hex. I'm sticking with that format as both the newer bootloader will support it, and the original bootloader also supports it.

[thanks4opensource]

Almost finished with the Python version. I went with coding my own Intel hex writer from scratch -- it was the easiest thing to do (and also removes the dependency on the IntelHex module).

@Ralim wrote:

The intel hex file must be over ~1KB (which is why I actually repeat its contents in my generated file)

Do you mean the file itself -- in Intel hex ascii format -- has to be over ~1K, or that it has to contain over 1K of binary data?

The example file @sreichholf posted is 11550 bytes long and contains (258 - 2) * 16 == 4096 bytes of data. Should I output that much? If so, do the low-order offset addresses on each ascii line need to restart at 0xB800 for each repeat of the LCD data? I ask because for what it's worth the Python IntelHex module didn't like that:

>>> import intelhex
>>> ih = intelhex.IntelHex()
>>> ih.loadhex('../sreichholf/dreamlabs.hex')Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "intelhex/__init__.py", line 209, in loadhex
    decode(s, line)
  File "intelhex/__init__.py", line 142, in _decode_record
    raise AddressOverlapError(address=addr, line=line)
intelhex.AddressOverlapError: Hex file has data overlap at address 0x800B800 on line 66

[Ralim]

There is a magic value, somewhere over 1K that the bootloader will accept as a minimum, I couldn't be bothered to find the exact value so I just repeated the values multiple times. (to bloat out the file with technically valid data). Also the hex file must contain the data for one page of flash (as the bootloader cannot write anything less than one page). Which is why the array is 1K exactly.

So you create the logo binary stream, then you place that into the 1k buffer for the page that it's being written to (the remainder of that 1K page is wasted at the moment.
I would with just that single page of information the bootloader would always reject the file. So I repeat that array multiple times to get past the bootloaders size restriction.

So yes you should output that much. And we have to do address repetition as its the only valid way to do it without having to know about what is in the rest of the flash.

Some decoders handle it well by just letting it replace the previous values, whereas others are pickier. I'm disappointed that they thought it was worth throwing an exception over rather than just a warning. (There are other files like this I have come across before).

[thanks4opensource]

Thanks for the info. Will do as you suggest.

[thanks4opensource]

Got it working. Byte-identical output on the @sreichholf test case (except for DOS "\r\n" vs UNIX "\n" line endings -- will that hurt anything?).

A little cleanup and documentation and it will be ready for testing and/or usage. @Ralim: My GitHub-fu was never very good, plus it's a bit rusty now. I can try doing a git push and a pull request. Or can I send it to you at your website email address and have you put it up here if and when you validate it?

BTW, I too was disappointed with the Python IntelHex module. Seems like someone wrote it only to do what they needed vs. being a complete implementation of the standard. That's fine, but should be advertised as such.

[Ralim]

I would make it output the same as the one mine does just as we know that one works.

Basically, easiest way is if you fork this repository to your own account, then push your file into that one (your fork) then you can create a pull request to this one. That way I can merge it in and it keeps the history of who wrote it :)

[thanks4opensource]

Fork created and pull request made. Hope I did it right. ;)

From pull request:

For review, test, and possible inclusion in main repository.

This is a commandline-only utility: No GUI, no visual display, no interactive control. It depends on and requires installation of the Python Imaging Library (PIL). A semi-user-friendly error message with hints on how to do this is provided.

The code has been tested against one 96x16 1-bit colormap PNG input image and produces Intel hex output that is byte-identical (including DOS "\r\n" line endings) to a file created with the original C# TS100 Logo Editor utility.

It should do the same for any 96x16 pure black-and-white input image regardless of file format. It will not create byte-identical output for any other size or color/grayscale input as it uses a more standard grayscale-to-1bit conversion from the PIL. Any reasonably close visual result (though still not necessarily byte-identical) should be achievable via use of the "--threshold" argument.

Additional differences may come from PIL's downsizing algorithms vs. those in the C# "System.Drawing"(??) library. In any case it is highly recommended to create a 96x16 1bit input image by other means (image editing program) as downsampling to this resolution and bit depth via any conventional method is unlikely to produce recognizable results.

Several other options provided. Use "--help" flag for info.

Hope this is of some use to the community.

@Ralim (or anyone else), please test when you get the chance and give feedback, bug reports, suggestions. If it's completely wrong and/or useless that's OK, too -- we can just delete it and move on. ;)

[Ralim]

I have used the script twice now and its worked well for me, so thank you @thanks4opensource
@JoshuaACNewman Have you had a chance to try this alternate method?