Most recent activity
-
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.
-
-
-
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/5SlQEe6epAYH8idhNCtpg2
Screenshot http://ubuntuone.com/2MkSYPDfDGkEn5X3jNJnPk
Will do a 1:1 check later comparing to the HYSTM32_28.py pins -
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. -
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 **
******************************/ -
$ cat /media/cdrom/uCOS_DEMO_V3-5408/Source/uCGUI/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 */ -
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?ViewItem&item=180819025871&ssPageName=ADME:L:OC:GB:3160
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.