Fighting with computers

Computers are not always friendly.

Monday, January 29, 2018

More SAMD21 M0 weirdness

My assumption was that using Arduino IDE was the quickest and simplest way to venture into the world of 32 bit ARM processors, but I am starting to think otherwise. This post is the second about things not working as expected and time used to figure out what's wrong.

For a motor-controller project, I was testing Allegro's A4950 h-bridge when I realized that while varying motor speed using a PWM signal, sudden torque spikes were happening.

My first idea was that the power supply was to blame, so I replaced it, to obtain exactly the same result.

The code I was running was very simple and on close inspection, I could not find any reason for the observed glitch, that somehow had a periodic nature: one acceleration and deceleration period would work ok and the next one will show three or four torque spikes.

As I was using an Arduino-form M0 board (SAMD21-based) I decided to bring back my trusted Arduino UNO and to run exactly the same code. This time all worked nicely, no sudden accelerations on the motor while speed was going up and down.

So next stop was to grab the M0 PWM output and to look for possible anomalies that would explain the problem (or maybe the problem is with the h-bridge I am testing, after all, I have never used that chip before).

So this is a quick recap of the captured PWM signal:

This is the PWM cycle before the glitch where duty cycle was 75.75%

Suddenly the next cycle is ON 2.3ms while the former was only 1.034 milliseconds, to account for a duty cycle of 87%. That was totally undesired and unexpected.

And the next PWM cycle after the glitch goes back to normal, again 1.028 milliseconds of ON time to account for a duty cycle of 75.17%.

So there it was, it appears that some of the calls to analogWrite may cause some glitch in the PWM output. If I want to keep on using this board I will need to figure out how to change the PWM duty cycle without experiencing that problem, which means to use some time to learn how SAMD21 timer registers work.

That is why I am starting to think that I rather use 8-bit Arduinos for prototyping as they have quite a predictable behavior while the same seems not to be true for some of the new brethren. While this may look like some Arduino-bashing article it is not. It is more a warning call for people like me that want to save themselves the pain of ARM datasheet reading.

Tuesday, January 23, 2018

Guess who is coming home?

Have you ever wanted to know if someone is coming home even before they ring the bell? I do not have a dog (they have that kind of power too) so I have to look for a solution on another domain.

So last weekend I decided to see if I could use an ESP8266 for that purpose, given that my sample subjects, aka sons, are equipped with smartphones with a MAC address I am aware of.

But the point is that if I wait till I can detect their phones are joining the home wireless network, they are probably at the door already. I am looking for something else that can pick them up sooner, even if their phones cannot yet pick up the home network wifi signal.

Googling around I found this code. It is a basic sniffer of wifi control frames. In particular, it is looking for probe frames that wireless stations can emit from time to time to discover nearby wireless networks.

But be warned that while the trick seems to work fine for Android phones, it does not seem to work for iPhones as they use to use a random MAC for probe frames.

As my results, well, it just works. I guess your mileage may vary depending on many factors. I get a one-minute warning, most likely their signal is detected when they enter the building.

An alternative (or complementary) use could be an early warning for the postman, the UPS guy, etc. But for that purpose, you'll need to figure out their MAC addresses, which is not difficult as the ESP2866 code gives you the signal level (RSSI) of the probes received, so a new MAC with a power signal when you have a visitor is going to be noticed.

Tuesday, January 09, 2018

Wemos M0 PWM weirdness

One of the things I have received as Xmas gift is thus Arduino UNO form factor board with a Cortex-M0 processor running at 48 Mhz.

After getting some trouble with the Arduino IDE I managed to get it working as an Arduino M0 in 1.8.5 IDE. However, though I could upload code, analogWrite seem not so work for me.

I used Fade example code that should work with built-in LED on pin 13 but it did not.

I had to use my logic analyzer to check which pins work with PWM and which do not. I could see that Adafruit using a similar processor mentioned some trouble with some pins but my board was even worse than that. Only pins 12, 11, 10, 9, 8, 5, 4, 3, & 2 worked with PWM while others, like pin 13 should work but did not.

At least now I know which pins I can use for analogWrite. I am not sure what the root cause of the problem is though.