-
Hey all, I've put Espruino on a smartwatch (SN80-Y from Yfit) and have figured out most of the pins and components (lcd, accel, touch) but am having trouble getting the XTX XT25F32B (4MB flash) chip to be reliable. Verified the following pins using multimeter: CS=D19, SO=D18, SI=D17, CLK=D20. Doing a wakeup, followed by getting vendor ID and capacity seems fine:
> spif = new SPI(); =SPI: { } > spif.setup({sck: CLK, miso: SO, mosi: SI, mode:0, baud: 8000000}); =undefined > spif.send([0xab], CS); =new Uint8Array([255]) > print(spif.send([0x90,0,0,1,0,0], CS)); new Uint8Array([255, 255, 255, 255, 21, 11]) =undefined > print(spif.send([0x9f,0,0,0], CS)); new Uint8Array([254, 11, 64, 22]) =undefined
That seems fine:22 at the end should mean 2^22 bits, or 4MB. So i've included it in my board file. In the devices section I have:
'SPIFLASH' : { 'pin_sck' : 'D20', 'pin_mosi' : 'D17', 'pin_miso' : 'D18', 'pin_cs' : 'D19', 'size' : 4096*1024, # 4MB 'memmap_base' : 0x60000000 # map into the address space (in software) }
And when flashed I see:
>require("Storage").getFree() =4194304
I then use this test script just to read the first few blocks of 256 bytes:
CS=D19, SO=D18; SI=D17; CLK=D20; setTimeout(()=>{ spif = new SPI(); spif.setup({sck: CLK, miso: SO, mosi: SI, mode:0, baud: 8000000}); spif.send([0xab], CS); print(spif.send([0x90,0,0,1,0,0], CS)); print(spif.send([0x9f,0,0,0], CS)); let hex = (d) => { return ('0'+d.toString(16)).slice(-2);}; let buf = new Uint8Array(256); // 3 byte address: 0x7f 0xff 0xff (0x7f = 8MB, 0x3f = 4MB, 0x1f = 2MB) for(let b1=0; b1 < 1; b1++) { for(let b2=0; b2 < 5; b2++) { let bufstr = ''; for(let b3 = 0; b3 < 256; b3++) { res = spif.send([0x03, b1, b2, b3, 0], CS); buf[b3] = res[4]; bufstr += ("0"+buf[b3].toString(16)).slice(-2)+" "; } print(`${hex(b1)} ${hex(b2)} ${hex(b3)}: ${bufstr}`); //${btoa(buf)}`); } } }, 1000);
The timeout was added because I was running into issues without it. This seems to work if I save it to RAM, as I get data (remnants from previous attempts to write):
new Uint8Array([255, 255, 255, 255, 21, 11]) new Uint8Array([254, 11, 64, 22]) 00 00 00: 04 04 00 00 54 45 53 54 ... 00 01 00: 64 65 65 70 20 73 6c 65 ... 00 02 00: 4c 4b 7d 20 20 41 42 3d ... 00 03 00: 70 69 66 2e 73 65 6e 64 ...
In the first line you can see the ASCII for "TEST" which was the name of the file I attempted to write in the IDE.
So the problem is when I try to save the test code to Storage (or Flash):| __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |____|___| _|_| |___|_|_|_|___| |_| espruino.com 2v12.925 (c) 2021 G.Williams Espruino is Open Source. Our work is supported only by sales of official boards and donations: http://espruino.com/Donate > FW addr 0x00000000 fail Status 0 Uncaught Error: File already written with different data at line 1 col 1106 ...{\n for(let b2=0",0,1349); ^ Uncaught Error: Too much data for file size at line 2 col 380 ... }\n }\n}, 1000);",1024); ^ ____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |____|___| _|_| |___|_|_|_|___| |_| espruino.com 2v12.925 (c) 2021 G.Williams Espruino is Open Source. Our work is supported only by sales of official boards and donations: http://espruino.com/Donate new Uint8Array([112, 105, 102, 46, 115, 101]) new Uint8Array([32, 104, 101, 120]) Uncaught SyntaxError: Unexpected end of Input at line 42 col 18 in TEST for(let b3 = ^ >
The other notable thing is that the CLK and SI lines are shared with the LCD (also SPI) and the accelerometer (I2C). However, I have not initialized either of those. In other tests, LCD works fine as does the accel, but I'm trying to leave out any issues with line sharing.
Any pointers greatly appreciated!
-
-
@fanoush figured out the issue. The display driver uses D9, which is an NFC pin for the nrf52832. Solution was covered in another conversation as a temporary measure, and to compile the firmware with the special tag (
'DEFINES += -DCONFIG_NFCT_PINS_AS_GPIOS',
) to let the NFC tags be treated as normal GPIOs. -
I'm hoping some folks here with more experience can give me some direction here. I have an nrf52832 smartwatch that I have ported Espruino to, and the core runs fine. I used some Espruino tools and a multimeter to figure out what pins are used on the display cable. I verified those by checking the GPIO setup and state while running the original firmware (using openocd to dump 0x50000700 and SPIM2). I believe I have CLK,MOSI,DC,CS,RST correct, and I am 99% sure it's a GC9A01 since my test code lights up both the SN80 and GW32 watches (both GC9A01). But my code does not work on this board. I figured there may be an ENable pin, so i walked through EVERY remaining pin: setting, resetting, pulling up/down before initializing and still get nothing. The backlight is on but I get no other visuals (even on other boards, if you get the pins right you see something: static, blurred pixels...).
My question: is there anything else a GC9A01 (or any small display controller) may need just to fire up? Something like special timings for the RST (right now I'm pulsing it with 50ms in between, then waiting 120ms before initialization).?
Any input or direction would be greatly appreciated... it would be nice to have Espruino fully running on this. Thanks.
-
-
-
-
I've narrowed down a bug to when I use Esprima's Mangle to shorten variable names (other minification options don't generate the error).
I'm seeing an error in the Bangle emulator when I execute this:
// works fine g.clear(); function dothis() { g.clear(); } function test(one, two, three, four, five) { let arrTmp = 0; //new Uint8Array(12); for(let i=0; i<1; i++) {} // fails g.clear(); dothis(); } test();
I'm getting this error:
>Uncaught Error: Function "clear" not found! at line 1 col 23 let a=0;for(let g=0;g<1;g++);g.clear(),dothis() ^ in function "test" called from line 1 col 92 ...(),dothis()}g.clear(),test() ^
You can see that it changed the loop variable to 'g' , which should still be a local variable, but it clearly affects Bangle's 'g'.
However, if you do any one of the following, the error goes away and the Bangle 'g' is fine:
- if you comment out g.clear() and use the "dothis()" function instead
- if you comment out the "let arrTmp" assignment
- if you comment out the empty for loop
- if you reduce the argument list to 4 items
Just thought I'd share; not sure whether this is an Esprima bug, or an interpreter bug (a "let g=" within a for loop should be its own scope and not interfere with global context?)
- if you comment out g.clear() and use the "dothis()" function instead
-
you'll need a buffer for each moving part (which could eat a lot of memory on Bangle1), set timeouts to loop through each "frame", calculating coordinates to copy from buffer to the lcd, and you may see some lag & jitter as you're asking the little cpu to do a lot of work (assuming Bangle1 again).
Bangle2 is more capable of this and could probably handle the ones you've shared fine. which watch are you targeting?
-
you flashed a hex file intended for a different board. The Rock is an nrf52840, which has more SRAM, flash and thus different addresses for DFU entry points, etc. So your board is in an unknown state, you'll need a full build of Magic3 with bootloader and soft device as a .hex file. Are you set up to do your own builds?
BTW: the Rock is not an officially supported Espruino board, you won't find any firmware for it here.
-
-
with a combination of online meeting tools / screen sharing, and the Web IDE relay, you can probably still teach them remotely?
-
A survey would indeed help shape JS3 into what most current users would like to see. And having the older alternatives is good for those who want the specialty items (like the barometer, or full color LCD). It depends on what Bangle's intended use really is.. a smart watch for hackers, or a hackable smart watch (they sound similar, but they're different!)
Myself, I am into the visual, and would enjoy the screen to be physically larger, hopefully without making the case TOO much larger. That would help touch screen behaviour as well. With more pixels (240x240 or greater) one can forgive the lack of colors (as anti-aliasing would be less necessary). I found the 64 color screen on the DK08 to be fantastic, if a tad too small and (sadly) low contrast (watches must be visible INDOORS on cloudy, dark Canadian "days"!)
That said, I also want to thank Gordon (and team!) for the fantastic work they've done and continue to do. I will certainly be a Kickstarter when the BJ3 is ready.
-
https://drive.google.com/file/d/1hldJC7VxSTJEAsg58bTm_5uf5vYUMxqG/view?usp=drivesdk
Up at the top under some foam, you'll see the 4 pins. from left to right: IO, CLK, 3.3, GND. Good to test them first though. If you leave the battery connected, you don't need to use the 3.3v. -
https://drive.google.com/file/d/1XsxoQC_5yIpBad0jxVS1WACeJpYWmc6P/view?usp=sharing
sorry should have warned you about the fake screws....
-
-
That's some nice work there, thank you for that! I have a hopefully easy Q. I am simply trying to identify the display that I have, a round 1.3" (probably a GC9A01) but I don't think I've got the read part of spi correct. I'm trying to ure spi.send:
let c = new Uint8Array([4,0,0,0]); JSON.stringify(SPI1.send(c,CS));
assuming SPI1 and CS are initialized correctly, should that code return the manufacturer information (command is 0x4, returns 4 bytes)?
I've tried it on a known GC9A01 and it doesn't work. Bad syntax? Do I need to lower DC? any help appreciated! -
-
-
Just for any who are interested... it does work! Of course, that's what it's intended for but I'm always concerned I'll fry something.
And for anyone searching, the W5500 Lite module (shown above) has different pin arrangements than the Wiznet board, so it's a little different than the Espruino doc but easy enough to follow. For the Espruino original, connect:
W5500 Lite Espruino J2 G GND J2 V 3.3 J2 MI B4 J1 MO B5 J1 SCK B3 J1 CS B2
Thanks to the Espruino team for making all those modules (ethernet, SD reader). Makes it so easy to get started!
-
Robust answer, thank you! All the pins fit fine in the prototype area, just wanted to make sure that I didn't accidentally put one in a hole tied to some distant pin! I've seen your images, really clever! But in the pictures above, I just have a handful of (standard) pins and I should only have to solder wire to about six of them. I guess there's only one way to prove it out... ;-)
-
-
https://www.aliexpress.com/item/1005002580402657.html?spm=a2g0o.9042311.0.0.27424c4djbKa9K
I also got the 44mm version and put that on my B2, but it's too big. 42 should be just right.
-
Maybe 'sweeping' was a poor choice... just a second hand would do. (Perhaps an 52840 could handle the former?...) what I've noticed is that the YFit firmware (for the SN80-Y) has a few watch faces with a second hand that updates pretty darn well -- likely uses an optimized algorithm to determine what part of the screen to update.
Thanks, Gordon. I rebuilt with that, and erased the flash (.eraseAll()) and it seems to work better, but it still seems to choke on larger files (5k or so). A file that works when sent to RAM will throw an error like:
as if the keyword "return" were incomplete; but as I said, it IS complete, and works when sent to RAM.
After this point, trying to list files shows an empty list; but if I "reset()", the file list is restored.
It's like it goes to sleep and can't wake up at some point! Insomniac flash.