Search results for:

Well your changes were a 'bit' cleaner than the ones I made last night! I downloaded your files and tested it, fully expecting it to work. However, the result is the same so the date isn't getting from fattime to the SD card. I'll explore today and see what I find.
THANKS for the FAST response! Excellent!
BTW, I also changed my board settings to include 3 SPI as supported by the nRF52832 (and as needed by my project board). The MDBT42Q has set only 1 SPI. I'm using more than one because, in the past, I've found that SD cards can get 'cranky' about sharing SPI bus and also, for route-ability on my board, it was easier to wire 3 independent SPI to the 4 SPI devices I have.

I'll let you know what I find on setting the date code.
Thanks again, Tom

What are you making her?

Well, she may make it into a product so I'm not sure it's ready for disclosure yet. But, it is a fun project and she is comfortable programming in js.

Since jshDelayMicroseconds() uses the nrf_delay_us() function then that should be good enough. The key is to make sure that interrupts are absolutely stopped, including softdevice, during the window. This probably means new interrupt_off & on functions that turn off everything but won't be used indiscriminately. I'll work on it at some point, it's just the important thing for me at thing point.

Last night's build was successful and FILESYSTEM is now running on the MDBT42Q. Besides the libraries selections, I had to modify two things in the new BOARDNAME.py file:

1. I had to modify the binary name to distinguish it from the Official MDBT42Q binaries,
   
2. I modified BLUETOOTH_NAME_PREFIX to distinguish it as well (not sure if I needed to do this).
   
   

I did get a LOT of warnings about unable to 'inline' some functions. The build works, but it would be nice to know if this is 'normal'.

However, it's great to confirm that I can build a new image. I gives me an awesome sense of power! Bwahaha!

I have set the IDE communications option to set the time on the device and confirm the correct date typing Date() on the console. However, when I create a file on an SD Card, the timestamp is some constant value (Jan 1, 2077 12:00AM).

Is there something I need to do to have the filesystem keep track of modification times?

I'm now thinking that it was a very crappy breadboard knockoff giving me unreliable connections. I've moved the MDBT42Q to an 'old reliable' breadboard and haven't had this issue since. My breakout is working as well so now I have two devices to compare. Good infrastructure and LOTS of effort went into Espruino, Good Job! I hope that I can get my app working on it. My 'customer'** will appreciate it!

** 'customer' == youngest daughter ;-)

When I get a chance I'll look into modifying the base code to see if I can improve the reliability on this device. I do have applications where DS18B20s are useful. The only real critical timing is during a bit read or bit write which require reliable timing within 15uS-60uS windows. Spacing between bits is not critical so turning of ALL interrupts during the narrow window and leaving them on at other times seems safe.

NEOPIXEL? I don't think so...
Stuff like that doesn't take up much memory so it's not such a big deal to leave it in.
I probably shouldn't have sounded so snobbish on NEOPIXEL, but, for me two things stand out with this device. Earlier ones, at least, the timing of the bit stream was very tight and long - something OneWire has proven difficult to do on my platform. The other thing is the power consumption of each device. It's not practical for a battery operated device, IMO.

Thanks for adding FILESYSTEM to the base. I'll test my 'tweak' today and use it for a learning experience, if nothing else...

I've used DS18B20s at 3.3V with 4.7K without issue before. I think it's a timing issue. It seems as if the master (the MDBT42Q) sometimes drives the one wire signal low for longer than spec and/or doesn't sample the slave device response in time to get accurate data and, consequently, gives up during the search. The same issues would render the data reads unreliable. But this code doesn't even bother with that issue. Doing a search and getting a reliable response is fundamental to a reliable OW interface.
However, having said all that, I will try a 3.3K just 'because'. :-)
Also, to answer your question, reliability didn't seem to be affected by whether there was one probe or two plugged in.
Also, I noticed when looking at the traces, that the search code does a Reset as well, so the one I have in this code is redundant. I don't think it would cause issues with the search but I'll remove it.
Tom

My device uses the MDBT42Q module with a different set of IO devices than the Espruino MDBT42Q module. I don't have the LEDs or switch, but I do have: SD card, 6DOF accel/gyro, 3 axis magnetometer, and 64Mb Flash memory. The Espruino module is a good starting point, but, obviously, I need to change the libraries (NEOPIXEL? I don't think so...).
Thanks for the info on Crypto. Looks like everything will fit with it, but I might remove it in a later version when I start adding libraries for the other stuff. Right now I'm testing performance to see if this platform can handle my needs. I haven't had much success with OneWire, but that's tricky timing. Hopefully the rest of this will be ok...
I've built an image that I'll test tomorrow. Hopefully the learning curve is not too steep for my diminished capabilities ;-)

I sadly discovered today that the build for MDBT42Q does not include FILESYSTEM. I looked at the MDBT42Q.py file and it appears that I can build a new version with FILESYSTEM and can also get rid of some stuff I don't need (GRAPHICS, NFC, NEOPIXEL). The thing I'm not certain about is whether I need the CRYPTO or AES set of libraries. Are these needed for some base security functions or can I dump these as well?

If I understand the process (which I am definitely NOT sure of), I simply create a new version of the file, changing the file name to something like MDBT42Q_tiny.py and build it... But which occurrences of 'MDBT42Q' do I change within the file and, on the make command, do I use BOARD=MDBT42Q_tiny?

Thanks in advance,
Tom

I'm getting very random results using DS18B20 one wire probes on two MDBT42Q boards. I'm using the latest firmware (as of March 2) but even simple searches for probes turns up unreliable results.
I'm using pin D11, have two DS18B20 probes that I've used reliably with other hardware (not Espruino), the probes' VDD pin is hard wired to VDD and I have a 4.7K pullup resistor.

Here is the code:

var ds = new OneWire(D11);
var sensors;
digitalWrite(D3,0);
function searchFor() {
  digitalWrite(D3,1);     // pulse trigger
  ds.reset();
  digitalWrite(D3,0);     // pulse trigger
  sensors = ds.search();

if (sensors.length >= 1) {
  console.log("Found "+sensors.length+" probes!");
  console.log(sensors);
  
} else
  console.log("No One Wire probes found!");
} 

setInterval(searchFor, 20000);   // search every 20 seconds

Attached is a snap of the IDE output.

Never mind, I got my answer here: http://forum.espruino.com/conversations/328182/
I've downloaded the 2v00 hex file and it is advertising as MDBT42Q xxxx. Now, on to try the Espruino IDE...

I purchased an MDBT42Q Espruino board, but I believe the board has some failed solder joints - it randomly lights up the red LED if I move the board slightly and I'm getting random results from basic code running on it.
I want to compare with an MDBT42Q Breakout board I have, but to load the identical software, I need to know which DFU bootloader the original has. I have the nRF52 SDK (version 15.2.0) and J-Link so loading the Softdevice and app is not a problem. However, the SDK has three different DFU bootloaders and I don't know which one the board requires.