-
• #2
Hi Sven,
I've been planning Wiznet 5500 support... The chips look good and the company is very helpful. However I honestly don't know when I'll get that done. I think if there's any way I can increase reliability of the CC3000 then that takes priority.
-
• #3
Just to add that I've been playing around with the W5500 (the WIZX550io module) and I now have Espruino working with it. Sadly every other HTTP GET fails and there is no DNS/DHCP yet, but hopefully that will be fixed soon.
It does look significantly faster/more reliable than CC3000 though...
-
• #4
HI Gordon, very good info. Thx a lot. I have to correct my info on the CC3000 to some degree BTW. I just had a longer break and left the computer running. Without failing, I had 79+ successful post requests and counting. There seems to be sometimes very large waiting time between the requests, but so far it has not failed with an exception.
-
• #5
OK, seems to have stalled at 79 :-) Waiting for a few minutes now.
-
• #6
Can you try going to firmware update and copy/pasting the following link: http://www.espruino.com/binaries/git/commits/671a77276f713331975b9e5f77c6da6ab8fe6c70/espruino_1v52_espruino_1r3.bin
See how that works - it should be better at recovering from errors.
-
• #7
Big improvement, 208+ and still counting. I'm gonna let it run. If I figure out Xively will run it standalone over night and we can watcht the xively graph to see how long it worked over night. Thx a lot!
-
• #8
It stopped now, this time with an exception:
Success Counter: 319
0000000000000000
ERROR: Timeout in CC3000 driver (4103)
ERROR: Connect failed (err -1)
Looks like CC3000 has died again. Power cycling...
ERROR: Timeout in CC3000 driver (16384)
at line 23 col 13req.end(); ^
in function called from system
Execution Interrupted during event processing - clearing all timers and watches.BTW I am about to figure out xively - I need to make PUT request to a HTTPS url, also need to set a header - so knowing about the headers comes handy. I assume I can use HTTPS - e.g. via "scheme:'https' ?
-
• #9
Hmm, that's unfortunate. I'm not sure what we can do if the CC3000 doesn't even initialise. I guess I could just get it to try again.
There's no HTTPS by the way, but a lot of these things will still accept HTTP.
-
• #10
My understanding was that doing the crypto required for HTTPS is beyond the capability of relatively low power microcontrollers like the one in the Espruino. Is this accurate?
I would also be very interested in support for a wired ethernet adapter. I have one project for the Espruino that will definitely need WiFi, but most of my projects would be fine with wired ethernet, and wired ethernet is just so much more reliable. WiFi is only barely acceptable on a proper computer or mobile device (don't get me started)...
Is there a way to make the Espruino not clear all watches and timeouts when something errors out?
-
• #11
I'm not 100% sure on HTTPS's requirements. Perhaps someone who knows more about it could weigh in...
As far as clearing watches/timeouts, at the moment there isn't a way. It could be an option I guess. I think 1v52 (out now) will be a huge amount better at not doing this on CC3000 failure though.
As far as wired ethernet - there is now support. See http://www.espruino.com/WIZnet
It's still a little glitchy (every 2nd HTTP request fails) but even now it looks very reliable. -
• #12
Regarding HTTPS, doing ssl/tsl libs on a small mcu (like stm32 mid-level) would definitely not be feasible imho. One of the problems being the shear no. standards that need to be implemented as well as the performance of software AES. Some mcu's, like the Atmel AT32UC3A3256S, does sport a hefty AES crypto module that could come in handy here though.
@Gordon, super excited to hear about the WIZnet support.
-
• #13
I think the problem with supporting HTTPS is that you need to be able to handle SSL encryption. There is an open source SSL library for embedded platforms, MatrixSSL that was mentioned in one discussion, but I'm not sure if even that will fit into the RAM available to the Espruino.
Excited to hear about the WIZ550IO support. Hope to order one soon - they currently seem to be out of stock at one of the few vendors selling them.
-
• #14
Great that wiznet is now supported. I just ordered a espruino board.
Is it possible to use low level socket function as i can use in node.js ?something like:
var net = require('net');
var cs=new net.Socket();
cs.connect(port,host, function() { });Many thanks
Sacha
-
• #16
Thanks Gordon for your answer. Hmmm. In my application i have to deal with a telnet server. As a workaround i will implement a proxy http/telnet gateway. Direct socket support would be very nice.
Sacha
-
• #17
Has anyone had any success getting a WIZ550IO shipped to them in the US?
Shopwiznet.com was out of stock last week, then it was down at the start of this week, now they say they have it in stock, but the order process fails at the last step. And the bastards only ship via fedex - Ten bucks on a $18 item! Seriously, I don't know how Fedex/UPS can quote their prices while keeping a straight face, when I can get individual items shipped literally from the opposite side of the world for $0.89 with shipping included - but that's a different matter)
There seem to be no other vendors except one that wants me to buy 40 (and at almost no discount - if they were cheaper in lots of 40, i'd have half a mind to buy a lot of 40 and try to flip em on ebay)...
Edit: Their website finally seems to work, and I've got my WIZ550IO on the way...
-
• #18
The STM32F1xx should be capable of doing some forms of TLS.
There're a number of commercial TLS products that include this chip, although they're obviously C or C++ linker libraries.
There're also a number of Javascript projects which could be "gutted" to run on Espruino and either provide ad-hoc encryption over HTTP, or possibly even a lightweight, barebones TLS implementation (pick the most popular/least taxing cipher, for example):
- CryptoJS
- Forge
- Stanford Javascript Crypto Library
I may have a crack at this, time depending.
-m
- CryptoJS
-
• #19
I was talking to the Electric Imp guys yesterday, and they use: https://gitorious.org/tropicssl
Their processor is a bit bigger, but is still an STM32F2. It'd be interesting to see if it could all be crammed in...
Having said all that, it looks like the next-gen networking chips will have SSL built in, so I wonder how much effort it's really worth putting in.
-
• #21
I don't know about WIZnet, but I've heard that TI are doing it for the CC3100 (or whatever it's called)
-
• #22
WizNet will apparently have an SSL stack for ARM Cortex shortly. However, it sounds like you'll have to license it on a per-device basis and no word on if it'll be available gratis to hobbyists.
-m
-
• #23
Hmm - interesting. The problem for me is you can bet that WIZnet's implementation only works with their chips, and I'd have to support CC3000 too.
I'd be interested if there was an HTTPS library for Arduino CC3000? It doesn't look like it though.
-
• #24
Gordon,
For reference Cyassl on the mbed takes 3 kb ram and 63 kb flash.I skimmed the github of espruino , and it does have some mbed support, what is that about ?
Thanks,
jack -
• #25
mbed support is extremely beta - as in, about a year ago I had it running on mbed without any peripheral support. It'll need a lot more work to be useful.
Thanks for the info on cyassl - sadly there's not much hope of that fitting in a standard Espruino board unless it could be cut down quite a bit :(
I am experiencing issues with the CC3000 in chatty environments, the TI CC3000 seems to be unstable and not able to connect, lose the connection, etc.
I love espruino and the coding style with javascript, but the CC3000 / WiFi might simply be too unstable. In the end I am building prototypes with it that might get presented at conferences and if the wifi is not rock-solid, it is a ticket to fail.
I read the only way to use the internet right now on an Espruino is the CC3000 - but apparently some other options are under way. Will there be a Ethernet option? I know from the experience on Arduino, that Ethernet is typically pretty stable.
@Gordon could you let us know if something is in the works and maybe include a rough timeline? I need some rough outlook as I need to make the decision if espruino can be used for more solid prototypes including HTTP requests in the short/mid/long term.
Thx!
Sven