Search results for:

Ugh.

> SPI1.setup({baud:3200000,mosi:A7}); // OK

// First one blue, then almost white, blue-ish white, yellow/amber
> SPI1.send4bit([255,255,255,128,128,128,255,128,255],0b0001,0b0011);

// First becomes white, purple/pink, off, red
SPI1.send4bit([255,000,255,255,0,0,0,0,255],0b0001,0b0011);

// First becomes green, turquoise, off, red
> SPI1.send4bit([0,255,0,255,0,0,0,0,255],0b0001,0b0011);

={
      "VERSION":"1v62",
      "BUILD_DATE":"Apr 22 2014",
      "BUILD_TIME":"16:28:21",
      "BOARD":"ESPRUINOBOARD",
      "CHIP":"STM32F103RFT6",
      "CHIP_FAMILY":"STM32F1",
      "FLASH":786432,"RAM":98304,
      "SERIAL":"3000d805-41413XXX-33481XXX",
      "CONSOLE":"USB"
    }
> 

It never works correctly on A7-SPI1 even when you just enter the code via the console. It does indeed work on B15-SPI2.

I am not using Wifi during the console testing; and unfortunately, the CC3000 has been soldered onto the board (and works). Hmm, tho our expert engineers did the work, perhaps the CC3000 is causing an issue?

Grabbed the latest in git (1v62) and the problem still persists. (Verified I'm running 1v62 by confirming some latest fixes.)

It occurs with an array of values on SPI1 pin A7. Works fine on SPI2 pin B15.

If I discard the first two bytes in the array (and effectively don't use the G and R colors in the first LED), all other LEDs work as expected.

This may be the culprit. I pulled 1v61, but before the SPI fix was applied. I'll get latest and build again. I'll post the results here. Thank you!

Thx for taking the time. Most appreciated if you could try accessing the first LED in the string.

The data sheet did state GRB, which was my experience.
http://www.adafruit.com/datasheets/WS2812.pdf

But putting that aside; the real issue was the first two bytes in a data array being ignored. So in short, on pin A7 with SPI1, I can only set the first LED to intensities of blue (being that the G and R bytes were ignored). All other LEDs were fine (LED 2, 3, etc.)

On pin B15 with SPI2, everything was fine. But I need the SD; and the fun part here is accessing the SD generates an inadvertent light show. Lol.

It would be awesome if you could share you findings / code samples when you have a moment (with some WS2812B's in your possession).

Thank you!

So I'm using SP1 on pin A7 and here's what I'm observing.

Just using the code from the examples:

SPI1.setup({baud:3200000, mosi:A7}); // All good here

// Per the tutorial, the following should make LED1 red;
// but our WS2812 string is addressed GRB, not RGB, so it should be GREEN.
// Oddly it becomes BLUE.
SPI1.send4bit([255, 0, 0], 0b0001, 0b0011);

// As noted above, our LED string is addressed as GRB when on B15 (this works fine).
// Below it gets weird in that this line makes LED2 GREEN (not LED1 RED).
// In other words, I've discovered on SPI1 A7 we cannot set the first two bytes.
// Everything is shifted two bytes over.
SPI1.send4bit([0, 255, 0], 0b0001, 0b0011); // Should be LED1 RED, but it's not!

// So the above is really functioning as
SPI1.send4bit([x, x, 0, 255, 0, 0], 0b0001, 0b0011); // Where x are the untouchable bytes.

Thx for replying DrAzzy.

I'll go back to this approach (using A7). I did it earlier and got some strange results.

Glad I ran across this. We're trying to use WiFi, the SD, and drive a string of WS2812's. Having a bit of trouble. Any tips?

I'm looking into using the new software SPI class on another pin, such as A8; but having trouble getting it configured right. Help?

Chip auto-detection would be awesome!

The new chip on our boards has been incredible. With uglify magnification, we're currently at about 12KB of JS and growing. And the Espruino platform has been performing like a champ.

We still pay very close attention to number of objects, concise well-organized code, etc. to utilize every bit of additional RAM. Just because we have double the size, we aren't wasteful.

Still, it really demonstrates the power and coolness of this platform.

Also note that we're employing some techniques with the SD and eval() to "swap-in/out" JS functions/objects. I'm sure something similar could be accomplished with the module cache; be we needed a custom implementation. This technique has really maximized the RAM and capability.

Also very interested in this, and ran across the same code.

Since there is no HTTPS, I'm interested in HMAC SHA1 to sign HTTP requests to our REST API. Similar to how Amazon does it here: http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

I've done this in the past and it works real well if you cannot implement HTTPS; and given that your data is not sensitive. Just a little measure to keep any private API less public.

Would love if this was opened up to a class or function we can use.

This was extremely helpful Gordon. Thank you!

It really helps to thoroughly understand the build scripts, make file, and build process. I have a much better understanding and was successful in one pass. I ran the script (against your latest release), then used the Python script and everything was perfect with no kludge.

The new processor works!!!

Now for my really stupid question/issue. When I do a process.memory(); I don't see much of a change. It outputs:

{"free":1781,"usage":19,"total":1800,"history":11,"stackEndAddress":536909496,"flash_start":134217728,"flash_binary_end":134458912,"flash_code_start":134967296,"flash_length":786432}

Here are the changes I made to ESPRUINOBOARD.py. Notice the doubled RAM, flash, and part number mods.

chip = {
'part' : "STM32F103RFT6",
'family' : "STM32F1",
'package' : "LQFP64",
'ram' : 96,
'flash' : 768,
'speed' : 72,
'usart' : 5,
'spi' : 3,
'i2c' : 2,
'adc' : 3,
'dac' : 2,
};

I noticed there is a "variables" setting under the info hash assigned to 1800. Should I change this to increase the number of available jsVars? Am I barking up the wrong tree here? What's a good number?

1. Just wanted say thank you Gordon for your help thus far.
   
2. Below is our progress, along with an issue I encountered near the end. So I need a bit of help.
   ---
   Remember that our goal was to have an Espruino board with more RAM. In summary, we mod an Espruino board to replace the MCU, modify ESPRUINOBOARD.py to specify the correct values, build the firmware, then install it via the serial bootloader.
   ---
   a. We have the STM32F103RFT6 chip with 96kB RAM on the Espruino board. This results in a board with no firmware.
   
   

b. We had to remove the bluetooth module to allow our TTL interface to work on USART1 A9/A10.

c. We setup the board with pins and jumpers so that we can enable the serial bootloader.

d. I put the board into bootloader mode and used the ST Flash Loader Demonstrator via VirtualBox to write the original firmware version 1v58; just to ensure that everything worked as before. I had better results with the Demonstrator and not with the stm32loader.py script.

e. One caveat was that afterwards, I had to use the USB-TTL setup to connect to the Web IDE, then issue a reset();. At this point, everything started to work normally and I could connect via the onboard USB port to run programs and flash firmware. Basically, the blue and red LEDs stayed dimly lit and the board remained "stuck" until I connected the Web IDE via the chip's USART interface and entered a reset(); command.

f. I pulled the 'cutting edge' latest firmware from Github, and modified ESPRUINOBOARD.py, along with a Makefile tweak to ensure that everything builds on my Vagrant/VirtualBox/linux instance. (Thx Forums for that setup!)

g. With my new binary, I used the stm32loader.py script to flash the modded firmware that has the new memory settings. Sadly, I get Verification FAILED after the writes. I can easily restore version 1v58 and it works; but the modded firmware won't install. Any ideas why the verification is failing? Do the nightly builds typically install fine; or do they just build?

Any help is appreciated. We're so close!!!
Thx!

Once again, thank you Gordon. You rock! This all makes perfect sense. Should have news in a few days on how it all went (everyone's gone for the weekend).

Okay, that was me being stupid. There are two pages on the Espruino site about using the serial bootloader, which I assume is required since we swapped the chip out. Still curious about how to restore the Espruino boatloader after we're done. I gather this from the statement "Note: Espruino boards have a USB implementation of the STM32 bootloader protocol built in."

Our group is experimenting with an extreme hack to increase the RAM on one of our Espruino boards. One of our engineers replaced the pre-installed Cortex chip with a pin-compatible one with more RAM. Being a software person myself, I'm looking for advice on how to reinstall the interpreter on such a board. Any input is appreciated. Thx!

Thank you Gordon. I'll look into your options; and we may even look into a properly designed network chip (if you have any suggestions, we would be happy to hear them). With your feedback, we have enough to move along. If you don't mind, we may come back here to share our findings and progress.

We're developing an application that requires fast sampling of pins, say every 20ms via setInterval; while "concurrently" we need to do an HTTP PUT every second or so. With some simple demos we've learned that Espruino tends to be a bit choppy and drops readings while performing the queued network requests.

I managed to trace this to two things (and please correct me if I'm wrong):

1. The HTTP request is handled whenever Espruino is idle (good).
   
2. When the HTTP networking code handles a queued request, it never yields along the way to the main event loop; hence, it takes priority over timer intervals and your own processing (bad).
   
   

Please shed some light on this, and correct me if any of my observations are invalid.

We would love to get more perceived "concurrency" while network request are being handled, and we're even willing to throw some dev resources at the problem to improve this for others.

Any feedback is appreciated.
Thx!