-
1) I'd start off without FAT, Graphics, CC3000, etc. You'll see from the Makefile how easy it is to disable them. Still, they shouldn't be big problems to enable afterwards.
2) 8kB is the minimum for it to be sensible. You could get a bit less (especially with the recent ram usage branch), but you'd be very limited with what you can do.
3) Not really. I'd make a point of porting Serial first, as that's your key to talking to Espruino. Once that's going, debugging the rest should be much easier.
-
-
Thanks - yes, it'd be cool.
Espruino is all open source, and is about as easy as possible to port to new platforms - so anyone is welcome to pick it up and try to port it.
Unfortunately real life gets in the way for me - I don't have much free time, and it'd be suicide to spend time porting to a platform that would then effectively cut off my only source of income :(
-
I was going to suggest this, but @JumJum's already there :) The ability to specify the project directory for modules/etc is really handy.
@user7114 the modules all come from GitHub so you can actually just link to specific revisions on there if you have a real need, or you can check back and see what changed.
The issue really is that stuff that's more than skin deep doesn't really get used at the moment... If I'd spend months writing a proper package management website, and provided the ability to choose specific revisions, would you have actually read about it and used it, when you didn't even look in settings to see the checkbox marked 'allows you to use files on your local disk'.
-
@FyberChris I actually had some luck with this on wednesday... I'll update GitHub with it at some point soon.
-
-
-
-
I'm not sure about the ack - I only know enough about the module to implement data I'm afraid.
There must be an official solution to the crashes... Surely they can't sell a chip that has this problem?
All I can suggest about trying to stop it breaking is to attach the power line to a GPIO rather than to 3.3v. You can then totally power off the module between sends, so even if it breaks, it should work the next time.
-
When you plug the LCD in, do you get a black bar before you use any code? That should be the default state if it's wired up right. If not, check power and the contract pin.
Also, you can actually use any pins at all to drive the HD44780, so don't worry about getting the exact same ones that the Espruino board uses.
The communication with Espruino is one-way, so Espruino will do what you tell it, but won't have any idea if there's any problem talking to the display.
-
@possmann: I think it might have been a mistake :)
-
-
I've just fired off an e-mail to WIZnet and we'll see if they can think of anything.
@possmann it's a shame you're having problems, but you are trying to do something quite advanced with it. I guess if you were just using normal SPI/Serial/etc you wouldn't be having a great deal of trouble.
Unfortunately if WIZnet change the way their board works and don't tell me there's very little I can do until I know about it :(
-
Hi,
The pins are hard-coded at the moment, but I'm afraid you're unlikely to have any luck with the Maple. The chip on it has only half the flash of the Espruino Board so some things have been left out to make room - one of those is CC3000 support.
If you compiled your own image and removed stuff you didn't need (Graphics, FAT) then there might be space (and you could specify your own pins) but I can't guarantee that it would fit in even then.
-
Just to add - looks a lot like the rev 1.1 : http://www.wiznet.co.kr/Sub_Modules/en/product/Product_Detail.asp?cate1=&cate2=&cate3=&pid=1196
@DrAzzy, which one do you have? I wonder if WIZnet have changed something between revisions :(
-
-
Cool! What kind of speed does it update? Do you have a video?
Not sure, but you might find that the
drawImage
functionality (with 1 bit graphics) is relatively speedy for stuff like the PacMan icon.It's a shame the bandwidth is so limited. Speed could definitely be improved if the driver wasn't written in pure JS, but even so it's never going to be amazing.
-
-
I've just wired this up and tried again with 1v69. Everything still works perfectly for me - DHCP, http get, server, etc.
What exactly fails when you do
eth.setIP()
? What does it say?And does
eth.getIP()
work for you? what does that say? It might be that the module is wired up wrong.What is the IP range on your network? The chip automatically sets its IP to 192.168.1.2 on bootup, and I wonder whether if you're outside of the 192.168 range, the netmask might stop DHCP from working properly.
You could try manually setting the IP to something in your range with something like
eth.setIP({ip:"10.0.0.2"})
, and then you could kick off DHCP witheth.setIP()
. -
Have you updated the SPI initialisation code to initialise B4 to miso? In the original code you gave, you don't do that.
If you specify some SPI pins but not others, only the SPI pins that you specify get set up - and if you don't specify an input then it'll probably just read 1s in - regardless of what the actual input is doing.
In the graph you sent, I don't see any data coming from the chip. Is that intentional?
-
-
-
-
Hi,
Yes, that's intentional. Normal Javascript has a date class that we implement, and it works just like that.
It's strange I know - but it would be worse if we behaved totally different to normal javascript.