connection problems with HY-MINISTM32V 3.2 #3834
Replies: 1 comment
-
Posted at 2014-04-23 by @gfwilliams I think there are some problems with new Espruino versions on the HY board I'm afraid (it only boots up sometimes). You could try Espruino 1v44. Some people were trying to fix this, but it all went a bit quiet. Posted at 2014-04-24 by alexrlopez86 Hello Gordon and changed the source of code and it works. and changed the following files: line 76 usb_conf.h and changed jswrap_json.c/h vesion 22.4.2014 . a greeting Posted at 2014-04-30 by alexrlopez86 Hello again here I put the changes in detail
functional today Posted at 2014-04-30 by Stev Guess that was me. Some false assumption about the time on hand. Then again, if waiting works that well... Posted at 2014-04-30 by Stev Would be nice to have that fix in the next build and maybe your 23.4. build somewhere where it actually downloads (I know, complains... But still, I seem to get only single bits from that link above) Thanks for looking into into fixing that USB thing. Posted at 2014-05-01 by @gfwilliams I'm not sure those changes will really help - are you sure it works reliably after applying them?
Posted at 2014-05-01 by Stev hey gordon, There's a http://www.espruino.com/files/espruino_hystm32_32_vc_1v43_beta.zip though. Posted at 2014-05-02 by @gfwilliams Thanks - sorry, I'm not sure what happened there. 1v45 might work ok? Posted at 2014-05-02 by Stev Whitelit my both boards yesterday anyway, when trying to reflash them using my macbook. Don't even know what to try next nor why it failed :/ So erase seems to have worked... Despite the script saying otherwise. Would "stlink" do the task instead of that python script? What can we do to have all the processes becoming more stable and maybe even supported? Posted at 2014-05-02 by @gfwilliams Whitelit? st-link is for the discovery boards that have a programmer on-board, not for the HY-STM32... The python script is very reliable usually - are you sure you've got it plugged in the right USB connector and have reset into bootloader mode properly? I really don't know what to suggest. This is why we have the Espruino board. All the boards are the same, they're tested, and I can develop software that works reliably with them. Posted at 2014-05-02 by Stev Gordon, I agree that your board is fun and reliable, especially cool with the HM-10, and I recommend it to anybody I meet. But since I needed that touch screen instead of the power saving and battery features (which are amazing) right now... Whitelit meaning the display just being white and lit when plugging in a USB cable. Before it played the colorful touch screen demo the board comes preinstalled with. USB ist the correct one, as its the only one that shows up as a usb serial port. (and that's only if you install the PL2303 drivers for Mac OS X. Not sure if that was mentioned anywhere.) And of course it erased the flash successfully, so... I coded a quick tool to see what's going on on the Serial Port, and it seems that some responses by the board are coming in too slow. Not sure if it's the board or the driver or some weird flow control issue that's the problem here. From what I saw, I would guess that the Python script might get confused when it gets incomplete input or the last bytes from an earlier command. I also get additional zero values at the end when reading board memory in larger chunks. Very weird. I'll see if I can make the tool write something to the board and have the board flashed using the tool, now that have most of the talking to the board in place. If anybody has an alternative driver (I have the PL2303_MacOSX_v1.5.1.pkg running under Mavericks), please let me know. Frankly I see the HY3.2 as an interesting board, and I'd love to pay a licence fee for Espruino (and read your disclaimer in the readme) if Espruino would be supported on this useful board that doesn't seem to come with any those "not for product development" licences if I understand it correctly. Posted at 2014-05-05 by Stev Short update: I managed to flash my board from my mac using the mentioned tinker tool. However, i found: The boot button on one of the boards being defective. The CRC seed (Bootloader version 0x22) seems different from that in the python script. The Serial device having "late" bytes coming in, filling the buffer but not triggering a "data available" event. (Have to determine on what level that bug occurs) Zeros being added to memory readouts for readout chunks sizes close to 256 Bytes (sometimrs resulting in some 400 Bytes instead of the expected 256) I used a very controlled (and unoptimized approach) for flashing the data onto the board which took 2h or so because of all the waits and checks, but the board now boots into 1.45. I'll see what i can take from that, test it on another machine and do some profiling on the delays to get a more optimized version . Still hope that it's something stupid that can be fixex easily, however. Will switch the boot0 switch, too ... Posted at 2014-05-06 by @gfwilliams @stev - it sounds to me like you may have some other software using that serial port? Have you tried on a different computer? The serial bootloader itself is built into the STM32 in read-only memory, so either the STM32 chip is defective (seems unlikely) or something else is padding those bytes out. Of course I guess it could be a hardware fault - maybe the connections between the STM32 and the PL2303 are a bit flaky? Posted at 2014-05-06 by Stev @gfwilliams I will look into that serial issue in more detail later on, and maybe get the original script to work reliably with the board. I have collected a few alternative serial drivers for OS X and might also look into Xojo's serial handling (which I used to be cross platform, but it seems to have its own "characteristics" and best practices that need to be obeyed). Still, I now can confirm that in your builds/files 1.48 is the last working version (the ones after don't react to any of the USB serial ports and don't display anything on boot) and that alexrlopez86's build of 1.62 boots up the board, displays the bootup text on screen and allows access via both USB serial ports. Perfect. For now. I haven't had the time to look at his code, so I can't say right now, whether it's his changes to the USB flags, or just his own build that make it work. But it boots up the board, so I can finally come back to the actual usecase :) So, maybe you can incorporate the changes? Or just do a build with your tool chain?He seems to have archived the complete checkout with changes, so it might not be that much of a task. Thanks again for all your responses to the weird serial port probs. Kept me looking at the issue. And thanks again to alexrlopez86, keep the builds coming :) (Have you tried whether a build on your toolchain without any changes would create a running build?). Cheers Posted at 2014-05-06 by Stev BTW, I am not so enthusiastic about that display anymore, now that I have it running :) Cheers Posted at 2014-05-06 by @gfwilliams That's great! @alexrlopez86 can you just try a built without any changes as @stev suggests? It is possible it's the compiler I'm using that is causing the issues. Sadly I can't pull in the changes unless I #ifdef them out for the Espruino board - each of the two changes breaks something :( Why not so enthusiastic about the display now? I have to say I haven't tested in a while, but I didn't think it was too bad. While it shouldn't be a big deal to have those kinds of displays working with Espruino, I think any 16 bit colour touchscreen displays that you can buy for this kind of task will all be very similar quality... Posted at 2014-05-06 by Stev Hm. The colors and brightness change a lot depending on the angle and the greys, or partially lit colors (e.g. when you draw a gradient) tend to create line flicker. Full colors and black are ok though. But you're probably right, when you say that this is what you get for the price (unfortunately the next quality step comes with a big jump in price). Still I wonder if there might be some good kickstarter/community projects coming up that might be as useful as the cc3000 and wiznet. It's an important part of interaction with the world. So, just a wish for now :) Posted at 2014-05-16 by Urri Hi, I would recommend to try this It's IPS and it is really different. I own both this one and HY32 Posted at 2014-05-16 by Stev Hey, Cool. Cheers Posted at 2014-05-17 by DrAzzy Nope, definitely not pin compatible, they use a different controller. The one linked uses ILI9481, and there is no module for it (yet), though it's probably similar to the 9341-.-for which we do have a module Posted at 2014-05-19 by @gfwilliams Internally there's support for the chips used in the HY boards (but not the 9481), they're all amazingly similar though so modifying the 9481 driver should be easy. It just depends whether it can be put into SPI mode (which is likely) - trying to wire up 16 bits + the rest is no fun at all :) Posted at 2014-05-19 by Urri Sorry, no. They aren't pin compatible. I just use a bunch of jumper wires And I also use FMSC to drive the bus. Gordon's board contains chip from medium-density series, so it does not have FMSC. But it's not really a problem. It can be driven by bit banging (if you have enough free pins) Let's count. You need WR, RD, CS, A0 and either 8 or 16 data bits for display and CS, MCK, MISO and MOSI for touch Posted at 2014-05-19 by Urri ILI9481's are slightly different in how you setup registers to access controller memory Using of SPI is possible but slow. The maximum SPI clock you can have from STM32F103 is 18MHz, which is 2MB/s. The maximum not yet exeeding spec FMSC speed is 8MB/s. There's compromise solution - use 8 bit mode Posted at 2014-05-19 by Stev Ok, there goes the convenience :) The connector looked so promising similar to the one of the HY board. Still, there should be enough pins on the HY board due to its original display's need and even the original Espruino might just have enough pins left, as I only need two SPI sets plus those data lines right now. Would be nice if it would run with the original Espruino board. 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. Posted at 2014-05-19 by DrAzzy
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. Posted at 2014-05-20 by @gfwilliams 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. Posted at 2014-05-20 by Urri 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: You choose :) Posted at 2014-05-20 by @gfwilliams 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. Posted at 2014-05-22 by Urri 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: Hey Gordon, I can share my VirtualBox image. Just give me a link where I can upload ~900MB Posted at 2014-05-23 by Stev 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 Posted at 2014-05-23 by @gfwilliams 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 Posted at 2014-05-23 by Urri 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. Posted at 2014-05-23 by @gfwilliams @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. Posted at 2014-05-23 by Urri 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. Posted at 2014-05-23 by @gfwilliams Up to you - if it's small you can put it here, or a pull request means you're credited in the commit log :) Posted at 2014-05-23 by Stev
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 Posted at 2014-05-28 by Urri Hi Gordon, I can't currently 'git push'. Could you please add me into the list of contributors on github? User name: utemkin Posted at 2014-06-02 by @gfwilliams @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 Posted at 2014-06-02 by Stev @gfwilliams. 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? Posted at 2014-06-02 by Urri 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... Posted at 2014-06-02 by @gfwilliams 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 Having said that, you may be able to change the |
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-04-22 by alexrlopez86
connection problems with HY-MINISTM32V 3.2" only works in Windows 7 and Linux with the HY - MINISTM32V firmware 2.4". Windows with the HY - MINISTM32V firmware 3.2 "detects the plate but not connected and Linux mint does not detect it
tested 22.4.2014
Greetings I hope to be of help
Beta Was this translation helpful? Give feedback.
All reactions