Instant crashing on connection of some signal wires seems more likely to be a hardware issue than a software problem.
Are you able to draw up a diagram and/or send a photo of how you’ve got everything connected up? In particular make sure the 5V → 3.3V connections on the level shifter are in the correct direction.
Given it works fine on an Arduino I don’t expect there to be issues there with the code logic or with a memory leak or similar. I haven’t used the M0 Feather, so perhaps it just has insufficient memory for the messages you’re trying to use, although I expect that’s unlikely.
Out of interest, are you running an example (if so, which one?), and if not, what code are you trying to run? I’d recommend starting with the ping1d-simple.ino example, because all it does is request the distance estimate, which should have minimal memory overhead, and can hopefully display at least the base functionality.
I unfortunately haven’t yet gotten around to testing the boards I bought last year. I may be able to test with an M4 Feather board towards the end of this week (I don’t have an M0 one), but that would only show whether Feather boards may work, since it’s a higher specced board than the M0 so is less likely to run into any performance issues there may be.
I first thought that it is a hardware issue as well. However as I am using the bi-directional level shifter it is hard to get it wrong.
Now I tested the arduino ping library with Adafruit’s M4 feather board and NRF52 feather board (Bluesesnse) and I can confirm that they are both working without any problems.
I assume that on M0 stack crashes as entire library allocates memory and functions on the stack dynamically. In my M0 case I got it to almost work (it stopped crashing) after I commented out the validation of checksum in the library.
In all cases I used hardware serial and fixed 9600 baud rate.
Unfortunately, the library crashes on both M4 and NRF52 when I request ping.request(Ping1DNamespace::Profile). Is there a way to fix this as we planned to use your Ping sensor in our product because of the access to profile?
Than I have two more issues that I managed to solve to report:
-When I downloaded PingView from your Github, the firmaware uploader function did not work. I am not sure why, but it looks like stm32flasher.exe that comes in zip was broken. After I downloaded and replaced a broken file with a fresh file from stm32 repository it worked right away.
-Arduino library on your git-hub return an error while complaining (it complains about undefined Ping1D namespace entry). An old version works. It also work if I install library through Arduino IDE directly.
Curious if this change could be helpful. We haven’t made a new release since that fix was added to master.
I’ll have to see how I go with testing. If you’re able to it’s likely better to use ping-cpp than ping-arduino, because it’s being properly kept up to date (we’re planning to migrate ping-arduino to use ping-cpp to avoid writing the same functionality multiple times, so ping-arduino has been somewhat neglected).
That’s definitely not expected. Can you give some more information on the operating system and Ping Viewer versions you were using, so we can try to replicate and fix the issue?
It definitely seems to be defined, so not sure what’s going wrong there. The one that’s accessible via Arduino IDE is the latest release, which is a few commits behind the current master branch state. Releases are expected to be more stable, although they may contain bugs that are fixed in commits that haven’t yet been added to a release.
