setWatch(function()

setWatch(function() {
LED4.set();
}, BTN1, {repeat:true});

It worked in ver. 1.41, but not in ver. 1.45.
Is there another way to write it now?

Which board do you have? It works on the Espruino board (although you have to change LED4 to LED3).

Sorry, I forgot that, it is a stm32f3discovery.

works fine on my stm32f4Discovery with nightly build from 13th of Jan

Yes, and mine is:
process.env
={"VERSION":"1v45","BUILD_DATE":"Jan 16 2014","BUILD_TIME":"11:24:26","BOARD":"S­TM32F3DISCOVERY","CHIP":"STM32F303VCT6",­"CHIP_FAMILY":"STM32F3","FLASH":262144,"­RAM":40960}

Although I have inserted a print ("asdf"); instead of LED4.set();, it does not work.

I found my old 1v41 and it works!

Hi Frida,

Thanks, it's a big help knowing it's setWatch that's broken on the F3.

I'm crazy busy at the moment so I don't know when I'll be able to fix it. I've created a bug for it (https://github.com/espruino/Espruino/iss­ues/183), and there's always the 'nightly' builds that you could try:

https://espruino-nightly.noda.se/

1v41 was released on 18th Oct, so it might be worth trying to narrow it down and see when it broke.

Please, take your time, I play with my F3 until I get my Espruino'.s.

I found out that the nightly build of 2013-12-09 works, but the nightly build of 2013-12-10 does not work. Inside it says 1v43.

If I make setWatch twice or more, I get the function double or more, when I hit the button.

>setWatch(function() {
:  if(digitalRead(BTN1)) {
:    print("did");
:  } else {
:    print("dad");  }
:}, BTN1, {repeat:true,debounce:10});
=1
>setWatch(function() {
:  if(digitalRead(BTN1)) {
:    print("did");
:  } else {
:    print("dad");  }
:}, BTN1, {repeat:true,debounce:10});
=2
did
did
dad
dad
> 

If I made it with this, I get a fault, because both pins, start with 1, but are different ports.

>setWatch(function() {
:  if(digitalRead(B1)) {
:    print("fif");
:  } else {
:    print("faf");  }
:}, B1, {repeat:true,debounce:10});
=3
>setWatch(function() {
:  if(digitalRead(B1)) {
:    print("eie");
:  } else {
:    print("eae");  }
:}, A1, {repeat:true,debounce:10});
WARNING: Unable to set watch on pin. You may already have a watch on a pin with the same number.
=undefined
> 

If I chance that line I get the error if I made 2 with the same pin nr. in jswrap_io.c
from:

if (!jsiIsWatchingPin(pin) && !jshCanWatch(pin)) {

to:

if (jsiIsWatchingPin(pin) && !jshCanWatch(pin)) {

But C is very difficult for me, so would it be possibly to check on the ports also?

It can wait to after the kickstarter is over.
It was on Espruino 1v72

I am still chasing the fault on my stm32f3discovery.
I am a big kickstarter fan of you.

Weird that same port same pin does not bother firmware, but same pin of different ports does. Multiple watches on the same pin - with different setups - could have some advantages. One watch could be the counting the changes, two others the rises and falls, and three more the first changes. To make that possible, all would have to be in the firmware. If the hardware has to be setup, then different setups are contradictory, and the last setup would win.

I think this is expected behaviour. The hardware only has 16 IRQ lines, for pins x0..x15, and it's not capable of watching A1 and B1 at the same time.

So if you're watching A1, that's fine. You can add multiple watches because the IRQ is being used already for that pin. But you can't watch both A1 and B1.

The hardware only has 16 IRQ lines, for pins x0..x15

explains a lot... and: No matter what power to the software, hardware shines trough!

@Gordon, are these 16 IRQ lines a) dedicated 16 interrupts? - or b) do they come out of a pool of interrupts?

They're kind of dedicated. Some have their own IRQ, but some of them share an IRQ. All 16 can be active.

You'd have to check the datasheet for exact details, but they shouldn't matter.

Well now I success. I found the error in:
Espruino-master/targets/stm32/jshardware­.c, downloaded today.
It say's espruino_1v72_stm32f3discovery.bin when compiled.

I have changed the following lines:

static ALWAYS_INLINE uint8_t pinToEVEXTI(Pin ipin) {
  JsvPinInfoPin pin = pinInfo[ipin].pin;
  return (uint8_t)(EV_EXTI0+pin); // PB
//  return (uint8_t)(EV_EXTI0+(pin-JSH_PIN0));

static ALWAYS_INLINE uint16_t stmPin(Pin ipin) {
  JsvPinInfoPin pin = pinInfo[ipin].pin;
  return (uint16_t)(1 << pin); // PB
//  return (uint16_t)(1 << (pin-JSH_PIN0));

static ALWAYS_INLINE uint32_t stmExtI(Pin ipin) {
  JsvPinInfoPin pin = pinInfo[ipin].pin;
  return (uint32_t)(pin); // PB
//  return (uint32_t)(1 << (pin-JSH_PIN0));

static ALWAYS_INLINE uint8_t stmPinSource(JsvPinInfoPin ipin) {
  JsvPinInfoPin pin = pinInfo[ipin].pin;
  return (uint8_t)(pin); // PB
//  return (uint8_t)(pin-JSH_PIN0);

The fault is in section 3: it vent 1,2,4 and should be 0,1,2.
At the same time I removed JSH_PIN0, because it is 0, and something - 0 gives something. That saved me 24 bytes.
I don't know what it else have influence on.

I hope you can integrate it in the next version.
C is difficult I must say.

Wow, thanks! I won't get this in today as I'm busy, but I'll try and get it in soon.

That saved me 24 bytes.

Really? Were you compiling with optimisation, as JSH_PIN0 should have got optimised out.

I don't know what it else have influence on.

It'll break everything that's not an F3-based part, but I'll #ifdef it in there for the STM32F3 :)

STM32F3DISCOVERY=1
RELEASE=1 # Force release-style compile (no asserts, etc)

I have only changed these two lines in Makefile.

I can wait till after I get the Pico's. Right now I have it running.
And I have tested it up to pin 7, but something seems to bother pin 2, but it don't matter, at the moment I only uses pin 0, that is the original usr button.

I've now updated GitHub with your changes - thanks!