HYSTM32_28 examples

I'm pretty sure I have seen some code examples for the HYSTM32_28 board on the site.
But I can't find it any more.

There's some touchscreen code here:

http://www.espruino.com/Touchscreen

I'm in the process of redoing the projects for the Espruino board at the moment though. There's always this one:

http://www.espruino.com/Project+2

Ah, thank you. This was the Demo I was looking for.
I'm beginning to wonder if I got the right hardware. :-/
I have a 2.8" inch display version (better fit for my project)

The hardware difference seems to be with the SPI pins. At least with the Project 2 code that also sends SPI to the LED strips.
But the Touchscreen code specifically for the 2.8" version also does not run.

I was not too concerned with that, because I thought the SPI stuff is just for the Touchscreen input. The Display should work independently.
Right assumption?

This does not look right: (after loading the Touchscreen demo)

>dump();                                     
var LCD = {};
function onInit() {
  SPI1.setup({sck:A5,miso:A6,mosi:A7})
  SPI1.send([0x90,0],A4); // just wake the controller up
}
function touchFunc() {
  if (!digitalRead(C13)) { // touch down
    var d = SPI1.send([0x90,0,0xD0,0,0],A4);
    var pos = {x:LCD.getWidth()-(d[1]*256+d[2])*LCD.WI­DTH/0x8000,
               y:(d[3]*256+d[4])*LCD.getHeight()/0x8000­};
    touchCallback(pos.x, pos.y);
    lastPos = pos;
  } else lastPos = null;
}
function touchCallback(x,y) {
  if (lastPos!=null) {
    LCD.drawLine(x,y,lastPos.x,lastPos.y,0xF­FFF);
  }
}
var lastPos = null;
setInterval(touchFunc, 50);
SPI1.setup({"sck":A5,"miso":A6,"mosi":A7­});
=undefined
>SPI1
={"_options":{"sck":A5,"miso":A6,"mosi":­A7}}
>LCD
={}
> 

I suppose LCD should get initialised by boards/HYSTM32_28.py?
I would not exactly expect a empty object.
Is there any way how I can interactively check if the board specific variables are set right?

PS: Screen stays grey throughout. When I bought the board it ran a demo, that displayed fine in case it could be some analogue trimming issue.

Hi,

Have you just tried doing something on the LCD? LCD.drawLine(0,0,100,100)

Built-in objects are handled in a special way to save RAM, so if you query them from JavaScript they'll come up empty. You'll have to check on the reference: http://www.espruino.com/Reference

Is there no text displayed on the LCD at startup at all? Normally at startup Espruino should display some text in the top left. It's possible that the board has a different LCD to normal.

The 2.8 board is pretty useless really - it's got a surprisingly small processor given the LCD that it's got to drive. Given there's so little flash, code has to be left out to get Espruino (and the fonts/etc) in. Also, different batches of the same 'HY' boards seem to have different LCDs - the driver has to support several different controllers.

I think you've asked about compiling the software yourself? If so, you could try editing libs/graphics/lcd_fsmc.c and removing the '#ifndef SAVE_ON_FLASH' lines. This should add support for other LCD types and might make it start working.

I didn't really reflect too much on the hardware choice. I saw the demo and went onto eBay. :)
The 3.2" version would not fit very well into my espresso machine, so I went for 2.8" which looked more suitable. :)
I never noticed the CPU differences.

I must have a different LCD. The material on the CD is all Chinese, I found two .pdf for two different display controllers. A ILI9320 and a SSD1289. No idea which one it is.

I can rebuild. Once I removed the SAVE_ON_FLASH lines, will it auto-probe or do I need to tell it somehow what to try?

The board isn't too expensive to not buy a new one if it turns our to be useless.

Sorry this turns out to be a support nightmare.
It looks like there is code for the possible drivers.
But with them all enabled I get nothing. (I tried #undef SAVE_ON_FLASH and removing the #ifdef lines)

I had a look at the display board. The only chip I can find on that is the XPT2046 touchscreen controller.
The LCD controller must be buried somewhere on the actual LCD module. Probably somewhere on the Flat-Flex which is all gunked up with glue.
No other markings that appear useful.

PS: This one http://cgi.ebay.co.uk/ws/eBayISAPI.dll?V­iewItem&item=180819025871&ssPageName=ADM­E:L:OC:GB:3160

$ cat /media/cdrom/uCOS_DEMO_V3-5408/Source/uC­GUI/Config/LCDConf.h
#ifndef LCDCONF_H
#define LCDCONF_H
#define LCD_XSIZE (320)
#define LCD_YSIZE (240)
#define LCD_CONTROLLER (9320)
#define LCD_BITSPERPIXEL (16)
#define LCD_FIXEDPALETTE (565)
#define LCD_SWAP_RB (1)
//#define LCD_SWAP_XY (1)
#define LCD_INIT_CONTROLLER() ili9320_Initializtion();
#endif /* LCDCONF_H */

Sorry for spamming. I'm just going to dump a few hints here.
void ili9320_Initializtion()
{
/*****************************
** Ó²¼þÁ¬½Ó˵Ã÷ ** // Chinese comments THANK YOU!
** STM32 ili9320 **
** PE0~15 <----> DB0~15 **
** PD15 <----> nRD **
** PD14 <----> RS **
** PD13 <----> nWR **
** PD12 <----> nCS **
** PD11 <----> nReset **
** PC0 <----> BK_LED **
******************************/

Are you sure those comments are actually correct? Maybe check the PDF schematics that come with it...

Just a note for anyone else, but the following will give the LCD device codes if it is connected to FSMC. The 2.8" board doesn't have FSMC so it's useless for you though.

poke16(0x60000000, 0x00);peek16(0x60020000)
poke16(0x60000000, 0x67);peek16(0x60020000)

The board sure looks different to the 2.8" one I have. The SD card connector is on the rear, rather than on the LCD board - so it wouldn't surprise me if the LCD connections were different.

This is another reason for having 'the one true Espruino board' - while cheap, the HY boards seem to change randomly and without warning.

Potentially you could:

• Make your own file in boards/your_board.py - copied from HYSTM32_28.py
  
• Modify the makefile to craete a new target for your board
  
• Modify scripts/build_platform_config.py to actually output #defines for the pin LCD positions
  
• Modify lcd/graphics/lcd_fsmc.c to use those new #defines when ILI9325_BITBANG is defined (which it is for the 2.8" board)
  
  

Hope that helps - sorry I can't do it for you but I have my work cut out doing the KickStarter board.

edit: Having a way to define the pins used for the LCD would help everyone out, and might let us support more boards more easily in the future. In fact it'd be even better if the bit-banged LCD driver could be instantiated at runtime - and then it could be used directly from the Espruino board :)

Just a quick note that you could actually write a driver in JavaScript if you want to get it working quickly. As long as you can make a function that writes a pixel to it, you can use: http://www.espruino.com/Reference#l_Grap­hics_createCallback to create a graphics object that'll output direct to the LCD (it'll be quite slow though).

I understand.
I really liked the self contained nature of the system with display.
But I can wait for the proper board.

I will have a dig around and report back when or if I get it to work.
The board looks different indeed. I was hoping it's only a board design change.
The display board has a full size SD card slot. So it has two in total. Not sure how far any other changes go.

Thanks - I know, they're nice boards. Especially the 3.2".

I've updated the http://www.espruino.com/Other+Boards page in case anybody else falls into the same hole.

My guess is they've swapped everything around so they could use the whole of port B for the data - the other one was a pain (using half of port B and half of port C). While it'd be nice to get a solution that works for everything, you could actually just modify your version of lcd_fsmc.c to use the correct pins for your board. It should be pretty quick to do.

I have limited time right now to concentrate deeply on it myself (slacking at work)
But from what I can find in the Chinese PDF the display data lines are still on port B and C
Page 45 on http://ubuntuone.com/5SlQEe6epAYH8idhNCt­pg2
Screenshot http://ubuntuone.com/2MkSYPDfDGkEn5X3jNJ­nPk
Will do a 1:1 check later comparing to the HYSTM32_28.py pins

RS and CS seem swapped
CS=C9
RS=C8

Had a very quick check, and at the very least the pins CS and RS are swapped - RD/WR/data look fine!

It may be that you can just swap the following lines of code in lcd_fscmc.c and it will work:

[#define](https://forum.espruino.com/sea­rch/?q=%23define) LCD_CS  PCout(8)
[#define](https://forum.espruino.com/sea­rch/?q=%23define) LCD_RS  PCout(9)

to

[#define](https://forum.espruino.com/sea­rch/?q=%23define) LCD_CS  PCout(9)
[#define](https://forum.espruino.com/sea­rch/?q=%23define) LCD_RS  PCout(8)

Looked like we cracked it. But no such luck. Not yet.
Will have to look at it later again. Must get some work done first. :)

Thanks for your help so far. Very much appreciated.

I nearly forgot to mention. This might be relevant

  python ../stm32loader.py -p /dev/ttyUSB0 -e -v espruino_hystm32_28_rb.bin
  Reading data from espruino_hystm32_28_rb.bin
  Bootloader version 0x22
  Chip id 0x410, STM32F1, performance, medium-density
  Read 256 bytes at 0x8000000
  Read 256 bytes at 0x8000100
[...]
  Read 256 bytes at 0x8003000
  Read 256 bytes at 0x8003100
  Traceback (most recent call last):
    File "../stm32loader.py", line 516, in <module>
      verify = cmd.readMemory(conf['address'], len(data))
    File "../stm32loader.py", line 321, in readMemory
      data = data + self.cmdReadMemory(addr, 256)
    File "../stm32loader.py", line 184, in cmdReadMemory
      if self.cmdGeneric(0x11):
    File "../stm32loader.py", line 136, in cmdGeneric
      return self._wait_for_ack(hex(cmd))
    File "../stm32loader.py", line 87, in _wait_for_ack
      raise CmdException("No response to %s" % info)
  __main__.CmdException: No response to 0x11

I never thought much of it because writing went without error and Espruino seems to boot fine afterwards.

You're not ever specifying -w so it isn't writing anything onto the chip - you're just comparing what's on the chip with the file you have (and it is failing!)

Sorry, I lead you down the garden path there.
I did of course write the firmware with -w previously. (without any errors)
This was just to demonstrate that the validating part never works.
The firmware boots and shows no signs of missing any of it's memory.

No idea then - best bet would be to uncomment the jsiConsolePrintline at the top ofLCD_init_panel`, and see if by changing pins around you can get a sensible-looking device code out of the LCD.