Search results for:

I tried the 'cutting edge build' and have verified that it is working with my 8uS pulse using

{repeat:true,edge:"falling",hispeed:true}

Thanks @Gordon and @allObjects

Thanks @Gordon! I'll flash the bleeding edge firmware and give it a go, and report back.

I thought the flip flop solution inventive, but certainly am not interested in the flying chip circus longer term :-}

Close enough; actually a positive 8uS pulse (see the earlier scope image). I think the nRF processor was triggering, but the additional processing with setWatch was too much. Per one of your earlier posts, I was getting stack overflow after a few cycles, so it wasn't keeping up potentially because it was triggering on both edges internally and logging time for each. I don't know enough about the internals, but from what you and Gordon have described it makes sense.

Since the toggle flip/flop only has the one edge each cycle, and there is a significant amount of time, it resolves the issue and Espruino can 'keep up'. I had J-K flip flops available since they are a general purpose 1-bit memory and easy to convert to lots of uses. A couple of connections and it becomes a toggle, for example. I don't keep standard logic gates around anymore, especially since I'd need a whole new family to do 1.8V logic work that has become the norm.

Thanks again!

@Gordon and @allObjects: solved! I used a J-K flip flop (74AC109) inline configured as a toggle. Then changed the setWatch to edge: 'both'. Pretty simple hardware solution.

Doing my SPI transfers in the setWatch with enough time, helps confirm that the issue was the narrow pulse.

The pulse is fine. That scope output is at the pin on the MDBD42Q module. That is the way this part works, and is just fine with microprocessors running native code.

@Gordon and @allObjects thanks for your assistance and advice. I tried the inline C (below) and had almost identical behavior. The 8uS pulse width just is not working. I'll take a look at the PPI function, but my guess is at this point it would be more reliable to go directly to nRF native coding.

var c = E.compiledC(`
// void press(bool)
// int get()
volatile int data;
void press(bool state){
  data++;
}
int get() {
 int r = data;
 data = 0;
 return r;
}
`);


setWatch(c.press, D16, {repeat: true, edge:'both', irq: true});
console.log("watch set");

Using the PWM method how; could you explain? Your idea of using a counter and resetting it on a timer would be completely asynchronous to the acquisition chip A/D; that's not going to work. I need to synchronize on the interrupt pulse and don't see how Espruino can be used in this way as a 'pulse stretcher' without additional hardware.

@allObjects sorry about that; used to typing the 'k'. If you look at that scope image, you'll see that it is actually 222 Hz. Plenty of time. I'd already run the numbers to make sure I had the time to do the SPI operations, even with Espruino timing on the SPI enable.

I think I either need to do a bit of pulse stretching hardware, or just ditch Espruino and head directly to C. I was hoping to avoid that since I'm just prototyping, but alas.

My other thought was whether it would be possible to so some inline C to trigger setWatch with a shorter pulse. Any thoughts on that?

Appreciate your insights!

No, I do not have control of the timing. This comes from an acquisition chip.

Thanks @allObjects. I'll also be interested to hear what @Gordon has to say, but I'm guessing that is indeed my issue.

No, I'm not measuring. I want to use the pulse to trigger other operations (SPI bus transactions), but if you read earlier, it wasn't working so in the debugging I pared it down to the code shown so as to isolate the issue.

Appreciate your insights! I guess I was expecting that since the chip I'm using (nRF) would have no issues with normal interrupts of this style, then this should work.

@allObjects close. It is an 8uS pulse. I've tried both the rising and falling edge in the watch with the same results. And yes, it is firing at a rate of approximately 222 kHz. Top trace on the image attached (channel 4).

Any thoughts would be appreciated, thanks!

@Gordon It seems that the watch isn't reliably triggering on the 8uS pulse. I've got it going at a rate of about 222 kHz and trimmed the setWatch down to the following. I've verified that the pulse is present at the pin D16. Note that I am running the module and all of the IO pins at 1.8V.

The setup code that uses SPI to communicate to the chip is operating properly (that sets up this signal), so I'm sure the supply voltage and IO is good.

I stripped out all the other code and have it isolated to the setWatch function below.

Could the issue be that the pulse on D16 is too short (8uS)?

Output:

setup complete
interrupt init complete
interval timer set
watch set
0
6
38
20
0
0
2
0
0
0
2
0
0
0

setInterval(function() {
  Bluetooth.println(readCount);
  readCount = 0;
 }, 1000);
console.log("interval timer set");


setWatch(function() {
    readCount++;
}, D16, {repeat: true, edge:'falling', debounce: 0});
console.log("watch set");

Thanks @Gordon, I'll give that a try and triple check my hardware connections. What I'm seeing on the scope is several series of SPI transactions with each falling edge of the watched signal.

I'll either post a resolution or scope images later today. Note that I am using the latest revision of firmware.

Hi,
I'm having trouble with a setWatch function. I'm monitoring a pulse that is 8uS wide and I want that to trigger the setWatch which contains and SPI write of 32 bits followed by 2 SPI reads of 32 bits. I'm using the MDBT42Q.
It seems to be triggering randomly and I'm stumped. Suggestions?

watchID = setWatch(function() {

    SPI1.write([READ_PTR, 0x00, 0x00, 0x00], nSEN);

    junk = SPI1.send([READ_FIFO, 0x00, 0x00, 0x00], nSEN);
    ecg = 256*(256*junk[1]+junk[2])+junk[3];

//      console.log(ecg);
  
    junk = SPI1.send([READ_LEAD_STATUS , 0x00, 0x00, 0x00], nSEN);

  readCount++;

}, ADC_RDY, {repeat: true, edge:'falling'});

Thanks @Gordon! I kept reading 0x18 in the documentation, but on closer look I do indeed have it at 0x19. Also appreciate your suggestions of using acc.r/w.

I'm now talking to the chip, but having issues getting the A/D turned on. I'll spend some more time on it, but right now I'm not getting any values out of the A/D register (after writing the enabling bits). I'll spend more time later today on this, but appreciate your guidance as always!

Bill

Hi All,
I'm wanting to use the LIS3DH analog inputs along with accelerometer. I'm getting totally lost on addressing, it would appear. When I set it up using the LIS3DH module using the default address and read the accelerometer, everything is fine. When I try the following setup, I2C1.read returns a timeout error.

Gotta be something very simple that I'm doing wrong; help?

Thanks!

I2C1.setup({sda:B7, scl:B6});

var addr = 0x18; //chip addr
read = function(reg, len) {
  I2C1.writeTo(addr, reg);
  return I2C1.readFrom(addr, len);
};
write = function(reg, data) {
  I2C1.writeTo(addr, [reg, data]);
};


console.log(read(0x08,2));

Does a plastic case for the Pico exist, either physically or 3D print model? I'd like one that can support an external cable connection.

Thanks in advance!
Billsalt

Really nice! It would be great to roll that into the standard build @Gordon. My humble opinion, of course.

Thanks Guys! I appreciate the follow up. I'm short on time to spend on this, and lack the expertise that you clearly have. I think it would be a good and intriguing feature to have in the Espruino toolkit.

Thanks @MaBe and @Gordon. I'll try to dig into it; this is a demo/idea so unfortunately back burner for me at best. If anyone in this group gets there first...

There was a thread some time ago about QR codes. I'd like to generate them on the Bangle. Did anyone get a port of the javascript QR code generator working? I could potentially use a barcode, but QR would be much better...

TIA!

Just ran across this issue today while doing a photoshoot. It would be nice to have the settings app...

Thanks @DuncanCragg! I'll see if I have time to replicate your work. I may/may not be a bit more familiar with the code loading process, so I'm not sure if I can add. I would like a uf2 way to do this if possible. We'll see if I find some spare time to look into it. Appreciate the info and your hard work!

Bill

Hi @DuncanCragg -- I've got a clue and just popped in here to see if someone had Espruino up on it yet. I read through the postings -- good work all!

Would you post a process summary and build files so that I can repeat your work?

Thanks!!

Thanks for the observation @Robin. There's a lot more going on with my project, including a custom flex circuit with a tag-connect JTAG port, so I'm good with what I've got going on.

I've ordered parts directly in the past and was very happy with that and support @Gordon and recommend the Espruino products quite often.

Thanks!
Bill