Search results for:

At the moment I can't get it working with Espruino, but hopefully we will sort that out soon.

There is no reason why it shouldn't work but for some reason, even with the same firmware, the Adafruit module works and this one doesn't.

the modules do work in other MCUs and with other software though.

Hi Andrey, One thought is that using SPI1.send(0x00,A4); will lower A4 and raise it for each byte. You may also find that the SPI 'mode' is wrong (CPOL/CPHA). You're better off doing:

SPI1.send([SPI_OPERATION_WRITE,0x00,0x05,0x00],A4);

(or actually doing the raising and lowering of A4 manually, and not specifying it for SPI.send at all)

The code that I have been using (different pins) is:

var EN = B7;
var IRQ = B8;
var CS = B6;       
SPI1.setup({sck:B3,miso:B4, mosi:B5,mode:1/*Mode 1   CPOL= 0  CPHA= 1*/, baud: 1000000});

digitalWrite(CS,1);
digitalWrite(EN,0);
while (!digitalRead(IRQ)); // wait for IRQ high
digitalWrite(EN,1);  
while (digitalRead(IRQ)); // wait for IRQ low

digitalWrite(CS,1); 

// 1 = command 
SPI1.send([1,0,5,0]); 
// IRQ goes high after this
SPI1.send([0,1,0,0x40,1,1]); // last digit should be 1 according to EmbeddedAdventures  
digitalWrite(CS,0); 

However I haven't had much luck with the Embedded Adventures module. I'm in contact with them and hopefully we'll figure out what the problem is.

There is CC3000 support in Espruino itself though (which works with the Adafruit module) - see http://www.espruino.com/CC3000

Until the Espruino board comes out you'll have to compile your image with USE_CC3000=1 and USE_NET=1 in the Makefile though (I've been developing using the F4DISCOVERY board and it works well).

Thanks! Do you know what the difference is between the DS1820 and the DS18B20? I'm just wondering if it's possible to make a new library that does both (as my library only reads the first 2 bytes)...

I don't think you're doing anything wrong at all - that's just what the OneWire object looks like.

You can then just call methods on it - see the DS18B20 library for an example:

http://www.espruino.com/modules/DS18B20.js

Just tap USD on the pull-down box in the top-right and click GBP. It's £16.99 (+vat + shipping iirc)

Not sure what you mean about the prototyping space? It's designed as an enthusiast board - if you were making something professional you'd probably just use the CC3000 directly as placing a few extra SMD components won't be the end of the world.

Hi Martin,

The module itself is actually a total pain. It's surface mount and has pads on the underside. Most importantly though it has no aerial built-in which means that you actually need to solder it down (probably in an oven) to quite a specialised board design with a ceramic aerial if you want it to work well.

Realistically, once you've bought the module, PCB, aerial, capacitors and resistors you've probably spent more than one of the pre-assembled boards costs.

So for pre-assembled boards it looks like Embedded Adventures is a good bet. They have a UK office and also have the cheapest modules I have found so far: http://www.embeddedadventures.com/cc3000_wifi_module_wrl-3000.html

Note that the prices on their site are ex-vat. They also sell the modules on eBay if you'd rather not hand out your card details to a random website.

I'm not sure I'm afraid - I was pretty sure that 1v41 worked ok on the Olimexino. You could try connecting to the USB-TTL port that you'd plugged in to flash (at 9600 baud) and see if anything happens when you reset the board without USB plugged in (Espruino uses USART1 if USB isn't in).

Hi,

I'm afraid Espruino is now too large to fit in flash alongside the bootloader so you'll have to overwrite it. All you need to do that is a USB-TTL converter though... http://www.espruino.com/Serial+Bootloader

hope that helps! I'll update the website.

Hi,

Yes, it is. It was only added within the last month or two though. I've just discovered that prefix increment isn't in there yet (and I think you have a typo after 'i=0'), however the following code works fine:

function add() {
  var i, len, result = 0;
  for (i = 0, len = arguments.length; i < len; i++) {
  result += arguments[i];
  }
  return result;
}
add(3, 7, 4, 6);  //result = 20

Glad it's working...

Yes, reset();save(); is the best way to clear out any stored software... it's a good point about the Web IDE and resetting - to be honest it makes sense that it does a full reset every time you upload by default.

I'm not sure about when the module support will arrive - I've been putting it off as it's in the Web IDE so isn't as hard to update later on as the firmware. It is something I'll be looking at soon though as I'd like to encourage more modules to be developed.

No idea then - best bet would be to uncomment the jsiConsolePrintline at the top ofLCD_init_panel`, and see if by changing pins around you can get a sensible-looking device code out of the LCD.

You're not ever specifying -w so it isn't writing anything onto the chip - you're just comparing what's on the chip with the file you have (and it is failing!)

Had a very quick check, and at the very least the pins CS and RS are swapped - RD/WR/data look fine!

It may be that you can just swap the following lines of code in lcd_fscmc.c and it will work:

[#define](https://forum.espruino.com/search/?q=%23define) LCD_CS  PCout(8)
[#define](https://forum.espruino.com/search/?q=%23define) LCD_RS  PCout(9)

to

[#define](https://forum.espruino.com/search/?q=%23define) LCD_CS  PCout(9)
[#define](https://forum.espruino.com/search/?q=%23define) LCD_RS  PCout(8)

Thanks - I know, they're nice boards. Especially the 3.2".

I've updated the http://www.espruino.com/Other+Boards page in case anybody else falls into the same hole.

My guess is they've swapped everything around so they could use the whole of port B for the data - the other one was a pain (using half of port B and half of port C). While it'd be nice to get a solution that works for everything, you could actually just modify your version of lcd_fsmc.c to use the correct pins for your board. It should be pretty quick to do.

Just a quick note that you could actually write a driver in JavaScript if you want to get it working quickly. As long as you can make a function that writes a pixel to it, you can use: http://www.espruino.com/Reference#l_Graphics_createCallback to create a graphics object that'll output direct to the LCD (it'll be quite slow though).

Are you sure those comments are actually correct? Maybe check the PDF schematics that come with it...

Just a note for anyone else, but the following will give the LCD device codes if it is connected to FSMC. The 2.8" board doesn't have FSMC so it's useless for you though.

poke16(0x60000000, 0x00);peek16(0x60020000)
poke16(0x60000000, 0x67);peek16(0x60020000)

The board sure looks different to the 2.8" one I have. The SD card connector is on the rear, rather than on the LCD board - so it wouldn't surprise me if the LCD connections were different.

This is another reason for having 'the one true Espruino board' - while cheap, the HY boards seem to change randomly and without warning.

Potentially you could:

• Make your own file in boards/your_board.py - copied from HYSTM32_28.py
  
• Modify the makefile to craete a new target for your board
  
• Modify scripts/build_platform_config.py to actually output #defines for the pin LCD positions
  
• Modify lcd/graphics/lcd_fsmc.c to use those new #defines when ILI9325_BITBANG is defined (which it is for the 2.8" board)
  
  

Hope that helps - sorry I can't do it for you but I have my work cut out doing the KickStarter board.

edit: Having a way to define the pins used for the LCD would help everyone out, and might let us support more boards more easily in the future. In fact it'd be even better if the bit-banged LCD driver could be instantiated at runtime - and then it could be used directly from the Espruino board :)

Hi,

Have you just tried doing something on the LCD? LCD.drawLine(0,0,100,100)

Built-in objects are handled in a special way to save RAM, so if you query them from JavaScript they'll come up empty. You'll have to check on the reference: http://www.espruino.com/Reference

Is there no text displayed on the LCD at startup at all? Normally at startup Espruino should display some text in the top left. It's possible that the board has a different LCD to normal.

The 2.8 board is pretty useless really - it's got a surprisingly small processor given the LCD that it's got to drive. Given there's so little flash, code has to be left out to get Espruino (and the fonts/etc) in. Also, different batches of the same 'HY' boards seem to have different LCDs - the driver has to support several different controllers.

I think you've asked about compiling the software yourself? If so, you could try editing libs/graphics/lcd_fsmc.c and removing the '#ifndef SAVE_ON_FLASH' lines. This should add support for other LCD types and might make it start working.

Hi JumJum,

Thanks - this is really awesome! I've hacked around with jslint (js/codemirror/addon/jshint/jshint.js) so that it now allows binary numbers, and have uploaded it to:

https://github.com/espruino/EspruinoWebIDE/tree/jumjum

If you use git then you might find it easier to keep track of changes. I'll try and get your changes into a 'proper' release when I get a few free moments - and I'll see if I can dump out the documentation in json format too (but that might be a way off!).

At the moment, I think having the buttons to select different bits of code (while cool) is a bit daunting to new users. I think maybe I should have a directory in EspruinoDocs called 'examples' which contains properly curated bits of example code (the stuff in 'code' is a mess and was basically only for my own testing :)

I'm loving the minify + send to Espruino. It works amazingly well - it's staggering what 'advanced' does to your Blinker snippet! Perhaps a simple regular expression replace (something like /0b([01]+)/parseInt("\1")/) could be applied before sending the code to minify to fix the binary number issue. I should just change the example code though :)

There's some touchscreen code here:

http://www.espruino.com/Touchscreen

I'm in the process of redoing the projects for the Espruino board at the moment though. There's always this one:

http://www.espruino.com/Project+2

Hi,

It should be available already. What happens if you type:

LCD.drawLine(0,0,100,100);

Hi,

Thanks! This looks really interesting. I love the underlining and code completion.

Chrome does seem to have some issues with CPU load for Serial ports (but only when connected). Even if this can't be sorted, the Web IDE could be modified to connect, write code, then disconnect, all in one go.

The Web IDE already uses CodeMirror - rather than making your own Web IDE so that we have two competing ones, do you think you might be able to improve the existing one? https://github.com/espruino/EspruinoWebIDE

I think it could be modified quite easily so that it would work inside a normal web browser too (without needing to be a Chrome Web App).

• console.log takes logs one parameter only: This should be fixed in 'nightly' builds: https://espruino-nightly.noda.se/
  
• arguments keyword is not supported: again, fixed already :)
  
• lint finds a lot of minor problems like missing ";": Finding problems where? in the 'code' folder, or elsewhere? The 'code' folder was really just a dumping ground for random bits of JavaScript (mainly for me) so it's very likely there are huge issues in it
  
• binary format is often unknown in the big world of javascript: Yes - this was added because it's just really handy for embedded software. I wonder if jslint could be modified to accept it as valid?
  
• minify my snippet for stepper with SIMPLE_OPTGIMIZATION does not work on Espruino. Syntax looks very strange to me, but all browsers took it. Just looked at this and there are at least two issues that I have filed bugs for
  
• example for stepper does not work with Microstepping, I had to use a different port. Espruino gave helpful error message. Somewhere in the background Espruino seems to have helpful information about ports. Yes, it knows what pins can do what. If you look at scripts/build_board_docs.py (which builds http://www.espruino.com/ReferenceSTM32F4DISCOVERY) you can get an idea of the data that is available. You could even add print(json.dumps(pins)) to dump everything to JSON
  
  

Potentially I could dump that information to JSON files on the Espruino site. Note that for code competion/documentation there is already: http://www.espruino.com/js/keywords.js

I notice you link to the files on EspruinoDocs. Did you know that these are used to generate pages on the Espruino site? For instance https://github.com/espruino/EspruinoDocs/blob/master/devices/Stepper%20Motors.md -> http://www.espruino.com/Stepper+Motors

As well as build_board_docs.py, there's also build_docs.py which builds the whole Reference document up. This could export to JSON quite easily as well - and I wonder if the code completion could be extended with all the built-in functionality.

Hi,

Thanks for letting us know - case sensitivity is actually an issue, so that code is wrong and I'll correct it. My guess is that when I wrote the code, the NRF24 was on the 'default' pins, so as MOSI/MISO/SCK would have been undefined, Espruino chose the correct (default) pins for SPI1 automatically.

SPI is connected 'straight' - it's actually got a really nice naming convention. MOSI = Master Out Slave In, and obviously MISO is the opposite. Espruino is the Master and the NRF module is the slave.

One way to help test is to make sure that you can communicate with the module over SPI. You could try asking it for its status, so you could do:

var nrf = new NRF( D13, D12, D11, D1, D0, 4 ); 
nrf.init([0,0,0,0,1], [0,0,0,0,2]); 
nrf.getAddr(nrf.C.RX_ADDR_P1);

and it should return an array representing the address - which should be [0,0,0,0,1] - the address that was given to the module in the init() function.

Hope that helps!

Hi Andrey,

Yes, CC3000 support is coming! We're almost there with it now, but TI's drivers are particularly poor so it's taking a while.

Hi,

Yes, this sounds like it could be a great project...

By PPM, do you mean the usual mechanism for controlling Analog model aircraft servos? If so, Espruino already does this quite well.

For OSD, there are chips such as this one that would work pretty well: https://www.sparkfun.com/products/9168

I'm unsure if they do graphics, but you'd think that there would be one that does.

No problem - glad to see you got it working!