connection problems with HY-MINISTM32V 3.2

What's the actual speed of the display when using your driver code? The one that comes with the HY is neatly fast and fun, especially to use compared to the SPI-only ILI I use with Gordon's board right now (because of the CC3000). Behaves more like a Etch-a-Sketch than a display.

I suspect there's something about the js ILI module that slows it to well below the potential of the hardware - 2MB/s is not "etch-a-sketch" speed. I haven't gotten a chance to look at it. I got a display with a similar controller and was going to write a module for it based on the existing ILI module, but I was so disappointed when I saw how tiny the screen was (and after failing entirely to make another display I bought at the same time work), I got depressed and went back to monochrome displays.

I'm with @DrAzzy here - SPI's not up there with FSMC, but it should be fast enough.

The issue is really the JS execution speed for the current module. If someone wrote a version of setPixel and fillRect in inline assembler it'd be pretty speedy.

I've got a branch here that adds some stuff that may help with the speed, but initial impressions are that it still isn't great except for fills of big areas. The best solution might be to come up with a general purpose SPI graphics driver that's built in to Espruino. Pretty much all of the controllers for these displays work almost identically over SPI, just with different initialisation code and opCodes.

The speed is actually high. I use STemWin (Segger's emWin sublicensed to ST - free for all STM32 users) and it's internal benchmark

Sorry. I messed with numbers. Earlier I wrote it was 8MB/s. Actually it's 8 megepixels/s (and each pixel is 16bit)

So:
for 16 bit parallel inferface it's 8 megapixels/s
for 8 bit parallel inferface it's 4 megapixels/s
for SPI inferface it's 1 megapixels/s

You choose :)

Yes, it's definitely slower - however 1 megapixel/sec is still 13fps for full updates. It's not amazing but is fast enough for a lot of stuff. At the moment we're not getting anywhere near that with the module though.

Hi,

I have successfully set up my build environment. I can confirm that current version from git repository works fine with my HY32 board.

Details:
Windows 7-64 host
VirtualBox 4.3.2
Linux absolute 3.2.0-4-686-pae #1 SMP Debian 3.2.57-3+deb7u1 i686 GNU/Linux
Distributor ID: Debian
Description: Debian GNU/Linux 7.5 (wheezy)
Release: 7.5
Codename: wheezy
Sourcery CodeBench Lite 2013.11-24

Hey Gordon, I can share my VirtualBox image. Just give me a link where I can upload ~900MB

I'd like to add to Urri's post, that the code also cross-compiles with the native GNU ARM Tools under (Mac) OS X and also runs on my HY32 boards without changes. The Makefile really seems to have improved, so using the arm tool chain is really just a matter of installing XCode's CLI tools (for make), MacPorts for gdu, the ARM toolchain from https://launchpad.net/gcc-arm-embedded, add the path to to the bin folder of the tool chain to your .profile in your home, then clone the git branch and do a make with the correct platform selector (from the makefile) and RELEASE = 1.

I still have a problem with the reliabilty of the LCD on startup, that weird LCD variable (= {}) (where did it come from, again?) and what's really biting me (and might have to do with all this) is that once I save() to flash, the device tends to not boot anymore, hanging in "loading from flash". I added supporting pin changes for CC3000 on SPI2 and changed the optimization flag and decreased the number of vars to 1843, but I would not think that this would break anything in regard to the flash.

I am using SPI2 as well as pins B12, B8, B9 for the CC3000. Don't know if I've overseen anthing that might get me in trouble here.

Cheers
Stev

Great news about the build. I'll see about switching my compiler over to the newer compiler - perhaps it was actually some problem with the old one (which I'd been using because it managed better code size in -O3).

The LCD variable is created in libs/graphics/jswrap_graphics.c - you're not getting duplicates now though? It's actually an instance of Graphics that renders direct to the LCD via FSMC. Try LCD.drawLine(0,0,100,100). Last time I looked into this it seemed that it was actually some crash when trying to initialise the LCD a second time. All seemed a bit strange though.

As Stev noticed, the screen on HY32 works unreliable.

For me it reports "Unknown LCD code 0 0" 100% of time after reset(). However, it prints Espruino welcome screen.

What I noticed is that if I change FSMC initialization code (\libs\graphics\lcd_fsmc.c: LCD_init_hardware) to the one from HY32's examples, it stops complaining. This means that timings are wrong (at least for reading).

Gordon, if you want me to contribute to your project, I would rewrite FSMC init part of code.

@Urri: that would be great. So no particular problems with 'LCD_init_panel', but it's the actual FSMC hardware init?

(LCD_init_panel has been totally bodged around because there are so many different types of LCD controller that get fitted to these boards!)

It would make a lot of sense, because Espruino used to run PCLK and PCLK2 at a lower speed in order to draw a bit less power. Due to a silicon errata in USB I had to raise them though, so that would probably have raised the FSMC clocks which would have made it unreliable.

It also happened at about the time it stopped working reliably - just before the first Espruino boards got sent out.

Right. Just FSMC setup. I will take setup code from my other project. Can I push the changes directly to git or just publish fragment here?

There are really many different controllers used. Even HY32D display can be based on 2 different ones.

Up to you - if it's small you can put it here, or a pull request means you're credited in the commit log :)

The LCD variable is created in libs/graphics/jswrap_graphics.c - you're not getting duplicates now though? It's actually an instance of Graphics that renders direct to the LCD via FSMC. Try LCD.drawLine(0,0,100,100).

Yes, I am using it all the time. The duplicates are gone. Still I can just delete the var and feel no difference :) I was just curious, since it reads "={}" and is visible in dump() while others (LEDs, other complex ports, Touchscreen) aren't.

On a sidenote, can we somehow also have "Touchscreen" directly available in the HY32 bin without the need for importing it from sd card or pre-caching/flash-saving it (which I find a cool solution nonetheless)? Still don't know how one would do that.

Stev

Hi Gordon,

I can't currently 'git push'. Could you please add me into the list of contributors on github? User name: utemkin

@Urri: Can you just submit a pull request? If you fork Espruino into your own personal GitHub, you can push there, and can then issue a pull request from there.

@Stev: Having modules built-in would be cool - I was going to add it, but the lack of flash on the parts means it's not that much use. The best solution for now is just to type require("Touchscreen") on the right, send it to Espruino, and then type save(). Either that or I think there's working SD card support? If so, just put the module in a node_modules folder on the SD card.

@Gordon. That's what I am using right now. Pulling the lib in via sd card and then saving it. Works reliably. Until I flash a new binary and have to redo the steps. Which is why it became a bit annoying or looked at least like steps that could be saved.

Right now, even with the CC3000 support I have a build size between 170k and 180k whith -Os and the Touchscreen module seems really tiny.

The other thing would be to save the user/var flash altogether and rewrite it externally. Might be a good appraoch for batch programming anyway. Any hasSavedVars flag that I would need to set somewhere to have espruino load it on startup? Or do I just have to calculate the page and pagecount and read/flash those pages?

Gordon,

I'm always wondering why don't you use STM32F103RF? I understand it's $0.7 more expensive, but 3 times more flash and 2 times more RAM could save a lot of efforts for you...

http://www.aliexpress.com/item/Free-Ship­ping-Original-STM32F103RFT6-franchise-ST­32F-SCM/1467537996.html

If you're keeping the SD card inserted, you shouldn't have to worry about saving...

To just reflash the same saved code, you just need the last few pages of memory. There's a #define in gen/platform_config.h that would tell you how many.

Having said that, you may be able to change the stm32loader flags (or modify the loader itself) so that it only erases the pages that it is overwriting. That might actually be the easiest way around it?