Search results for:

Ah, ok. I also had some strange effects when using the left side of the WebIDE and in the end had some kind of "pure serial line in the middle" on my mind after those issues with the 8266. Since the connection to the Pico is USB you should be right about the checksumming and the missing return channel/echo chars on the WebIDE are probably due to the same bug.

I guess I was also a bit burned by the transmission problems with the HY-MINISTM32V 3.2 I had last year and now when trying to flash the pico via the CLI instead of using the WebIDE (always resulted in several false values during verify) and didn't think about the actual connection type.

I used to just use screen on my mac, which now seemed even more tempting since i don't need a cable anymore. "Just talk to the chip", basically, seems really cool to me.

So far (a year ago) I just pasted the minified js code and saved it. Using addCached for the Modules. Worked fine. Saving is an
awesome feature, too.

However on the original Espruino pasting worked fine with flow control/buffering for me. The new one stops somewhere in the middle when pasting larger code pieces

since it's going via serial lines: Do we have/can we expect to have a functionality to send. Checksummed code, maybe in chunks, and join them on the board again? Or is there already something that works with the Web IDE that can be re-used? While it mostly worked fine there was always that bad feeling that something could have been changed during transfer. I could use echo to check each input, but that seems a bit to much feedback.

For the current problem, I have no idea. I ripped everything apart and talked to both sides vie USB-UART. Then reassembled. Then it worked. Bad wiring/breadboard, can't really say.

Something bordering on esotericism was to draw RST explicitely to Vcc. Of course it worked without that as well afterwards. So... At least the bug was expelled.

Works now, with a CIPSTART failed now and then.
But to return at least something to the forum I can report that the ESP8266-01 shipping from Watterott last week have the 0018000902-AI03 firmware and report a[Vendor:http://www.ai-thinker.com Version:0.9.2.4] on start-up.

Ok, now I am having problems with talking to the ESP8266 via serial, it seems.
I get the "no 'ready'" error and I am seemingly not able to talk to the chip via Serial.

For the capacitor, does it make a difference, where you add it and how long the cables are (breadboarding right now)?

Also, I am not sure about the Wifi-Enable pin. When I don't draw it to 3.3V I see a blink of the blue LED on the ESP8266 for serial activity, if I pull it up, I don't.

The funny thing of course is that I cannot ask the chip for its version without having it talking via serial...

BTW: pretty nice new HW. Thanks for keeping at it that much.

Hey,

Thanks. That's will be the reason. Should have just done the blinking LEDs for my first day back.

I usually used Espruino via the command line. Of course I had the modules on SD card on the "classic" one.

Will try again tomorrow using Module.addCached() or even use the IDE.

Will you be able to provide a binary with the Modules needed for the ESP8266? Would be great at least for my typical workflow, as pasting code on the Pico seems to fail more often than on the classic Espruino. Don't know if the CLI buffer is smaller or something? Also having the Wiznet or CC3000 flashed does not help anything with 8266. Don't know how many people run both.

Thanks again, will talk back, once it runs.

Hello again,

I spent some months with other things and I am now trying my new "ugly" Picos (from the Tindie sale). Blinking the LED does still work as expected, but WiFi.. also still has issues.

Even after updating to 1.79 and trying both binaries...

(BTW:Why do I have to choose between Wiznet and CC3000 binaries, if I actually want to use that cheap 8266 with my Picos?)

... I get an Module not found for the "ESP8266WiFi" and missing functions for "ESP8266" (which is how it's referred to inside the module code). Something I am missing? Is there a way to display the available modules (not the cached ones, but the built-ins)?

I hope it's some stupid mistake on my side and someone can show me where my weekend enthusiasm went wrong.

Cheers
Stev

Hm. Just asked as you mentioned that CC3000 successor when we discussed encryption some time
ago. And now it's there.

I would think that they focussed all their workforce on a new feature-complete and widely available chip instead of having a dedicated support team for the first incomlete one. Despite all the frustration that that brought to the early adopters. They might need a communications guy on the team, though.

Do you think Espuino could work on a CC3200 with ita M4 and the given specs?

-Stev

Hey,

Just looked up the CC3100 and CC3200 which seem affordable and of TI-ish quality and availability.

http://newscenter.ti.com/2014-06-16-Add-Wi-Fi-to-anything-with-TIs-Internet-on-a-chip

Any ideas (or plans) in which Espruino works with the 3100 (or better, on the 3200)?

-Stev

@Gordon: Will we get a standard 64-bit int/uint in addition to the standard type? Handy these days. Not that you hadn't enough cool features to fill the remaining ROM, just asking.

Or should we do our own classes, a module, is there anything to use?

Nite
Stev

@Gordon

>(7 >>> 2) << 1    
=2
>7 >>> 2 << 1  
ERROR: Got << expected EOF at line 1 col 8
7 >>> 2 << 1
        ^
>

Works fine in node ;) So, for lib compatibility...

Cheers
-Stev

@Gordon, I think it was a >>> followed by a << without bracketing that was problematic. Maybe typing some example using those might already show the problem.

I'll see if I can find the correct line and the minification (which might had a problem with it itself). Won't be able to look it up today, though, as I am away from my Espruino gear... (Edit: Now that a local make on OS X is so straight forward, lack of HW is not that much of a problem as ./espruino is quickly built...)

Definitively a good step to have 32-bit compatibility. Easy to trip over it when you start with the "easy Javascript-based microcontroller" and to get demotivated if you just want to use a lib that then just won't do the right bitshifts. Not always to easy to make complex library calculations 32bit-compatible by hand without missing one piece or another.

I had the problem with that md5 lib early on and fixed with some hacks but I could imagine beginners getting hit harder by a similar obstacle.

So. Cool.

Best
-Stev

BTW: I found a problem with chained bit shifts and minification back then. Only one of x minifyers would create the bracketed code that Espruino would need to work. Don't know if you changed something there, too (since 1v58). I could look it up, if it's of any use.

@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?

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

Found it in the makefile.
Which one is it? Sony 1 or 2?

Hi,

is there any place to lookup the commit hash for a certain build number?Github allows for version tags, but that seems not be used.
I tried the build date from the binaries, but pciking the correct commit is a bit fuzzy that way

Best
Stev

@mikewop
I added a comment in http://forum.espruino.com/conversations/1195/?offset=25. It's actually quite straight forward now. I can add a more thorough description if this might not be enough, or you can pm me.

I am transferring the executable using a self-hacked tool as the python script did not work for me. Takes ten to fifteen minutes each time though :/ (there still is optimization potential, though)

Not sure if it's actually a working build :)

I am using the GNU ARM Toolchain on OS X 10.9 combined with the make from Xcode and the gdu from MacPorts. It compiles the pure 1.64 without errors and it boots up on the HY32 including the LCD.

However, the board does not come back from reset() like yours does. And once I do a save, the LCD will not boot up and the whole system seems to hang in "loading from flash..."

I also did a custom build where I added USE_NET and changed the CC3000's pins to SPI2 plus B12,B8,B9. I also changed the optimization to -O2 or -Os to make the binary fit into flash. I changed the number of vars to 1843, which solves the recursion problem.

Still, the problem with save() and coming up after save() or reset() remain. So I only run once :)

Learned a lot about the codebase though. Not sure if all the pins in the tables are right, though. There's also one half way empty line for C11 (first column) which stands out. And the mentioned SPI3 thing that does not match the borad description and is mapped onto the same pins as SPI1 anyway.

Cheers
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
Stev

Hey,

I've got a new problem.
While the MD5 code I am using worked fine on the original espruino board, it triggers this stack overflow warning when running on the HY32.

Since both boards seem to have the same amount of ram and I have plenty of vars left, I assume that it uses some ram to support the build-in display?

Should I try to lower the number of VARs in a custom build (which I can now do virtuously, as I got that toolchain working on my Mac ;) or is there a fancier way to get rid of that error?

So... I managed to connect the CC3000 to the HY32. But it would only accept SPI2 and crashes deep (Display backlight and USB led go dark) when trying to use SPI1. Also the Reference image shows SPI3 on the same pins as SPI1, however, the board's config says it only has 2 SPIs, anyway. So SPI3 is actually not defined. Maybe the pin info for the board is not clear/clean on some details?

I now reconfigured the cc3000 to use SPI2 (B13, B14, B15) with B12, B8 and B9 for the additional Pins, which worked right away.

I also saw that the pin reference shows USB as a function for three pins. Can that be used for anything right now? It's probably for OTG/Host mode?

I have now a new problem, "too many recursions" when doing the MD5 on the HY32. I'll open a new thread for that one.

Cheers
Stev

Ok, just wondered if there were any magic performed on the lower level to fix the stabilty issues or whatever and whether I had to "wisely" choose pins.

Is there a list what pins might work for what? SPI is a bit picky about what it accepts and I haven't found out exactly what the criteria was. (Then again, I haven't looked into the pin features yet, as I am mostly using the platform as a less complex - than RasPi - software environment right now)
-Stev

Hey Gordon,

Thanks. At least I don't feel that stupid when blindly deleting lines :)

I guess, I would keep ctrl-C for the interactive part and add a "system" key shortcut to kill the rest. Ctrl-S/R/Q or something (therby totally ignoring what traditional bindings might exist in another geek's world).

Oh, that's very cool, indeed. Thanks for sharing that work.
Hadn't looked at that particular thread for some time now.
So, now I'll be on Amazon cloud to get that damn board working :)
(Ideally with a new credit card that allows for some free test time...)

Nice. Thanks again.