Now in order to do that automatically I'm using an Arduino Nano and I connected that wire to an analog pin "d1" set its mode to Output and connected the grounds of both Arduino and drive together. Pick a goddamn standard and stick to it, will you? And when you do, please make it a consistent standard.So I need to automaically eject a CD from a Blu-Ray drive, I have a wire welded on the drive's card that if manually connected for a split second (pulse) to the ground of that same card on the drive, will eject the CD. The issue is further muddied by the fact that some cores work the way one would expect, and some do not. ![]() Or - if the magic shouldn't be there - remove the magic from both functions. If you're going to have a noob layer, then have it be a noob layer and do the damn magic. Arduino is a noob-friendly layer on top of the Atmel hardware registers. The reason analogWrite() does all this housekeeping is to save you - the programmer - from doing it by hand. analogWrite() configures the pin for analog, but digitalWrite() doesn't configure it for digital. The problem here, is that digitalWrite() - on some cores - doesn't behave like this. So you clearly don't have a problem with inefficient repetition of tests per se - you just have a problem with them being inside digitalWrite(). And therefore, if I call analogWrite() in a loop, these tests will be performed repeatedly, without regard to efficiency. And why not? Because analogWrite() contains code that configures the pin for PWM output. analogWrite() magically configures the environment, so why not digitalWrite()?Ĭalls to analogWrite() do not first require a call to pinMode(pin, ANALOGOUT) do they? No. The one, and only, time you can safely skip pinMode is when doing digitalRead following a hardware reset, as all digital I/Os are automatically configured as inputs by a reset. In embedded systems, using hardware features ALWAYS requires first setting up the hardware to operate in the mode you require. Any other time, it is foolish to NOT do a pinMode if there is ANY doubt about the current pin configuration. SOLUTION: Before attempting to use a pin for digitalWrite, ALWAYS make sure that pin has been configured as a digital output, by calling pinMode. So why would you expect it to work following an analogWrite? In embedded systems, using hardware features ALWAYS requires first setting up the hardware to operate in the mode you require. Would you expect digitalWrite to work immediately following a reset, WITHOUT first doing a pinMode? Of course not. If it did, there would be no reason to have the pinMode function. NO! The solution is to use BOTH analogWrite and digitalWrite PROPERLY! digitalWrite obviously DOES NOT configure the pin appropriately. It's bad practice and will cause you major headaches down the road!!! SOLUTION: Always use only analogWrite or only digitalWrite in your code when controlling a single pin. So basically even boards created by the same company, Adafruit in this example, don't always perform the same with the same code. I CAN mix analogWrite and digitalWrite):Īdafruit Feather ESP8266 which uses as you might have guessed the ESP8266 chip and Adafruit's own libraries for talking to it ![]() I CANNOT mix analogWrite and digitalWrite):Īdafruit Feather nRF52832 which uses as you might have guessed the nRF52832 chip and Adafruit's own libraries for talking to it ![]() Then when I tried to upload my code to a different board I was dumbfounded as to why the LED wouldn't function as I thought I had told it to function. The very interesting thing is, I wrote all my code for one board, and the LED functioned normally. For what it's worth, I just ran into this same issue as I was trying to use analogWrite to pulse an LED and subsequently trying to use digitalWrite to turn it off.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |