Hi, care to open an issue on Github for this? This sounds very much like a bug in RIOT.
Could you also provide the board details. If you're using an out of tree board, especially the clock configuration would be of interest. Kind regards, Marian On Tue, 1 Sep 2020 21:58:32 +0200 Wouter Symons <wo...@airsantelmo.com> wrote: > Thanks for the quick response Marian! > > > So, double check that you are using PWM_LEFT. > The servo driver uses PWM_LEFT hardcoded. > > > Do you have an logic analyzer at hand to confirm the PWM output is correct? > > > Great idea! I had already tried checking the output with an oscilloscope > I had laying on my desk yesterday, and also tried to hook up a small > buzzer, and both more or less indicated that the output was fine. > However... I checked with a logic analyzer now, as per your suggestion, > and indeed... something is off: if I apply a PWM decoder to the output, > it gives me a duty cycle of 0.390221%. It varies slightly, but not by > much, and it is not sweeping like it should. > > > Does the serve has any > > requirements on the PWM frequency? > I tried an SG90 and an MG995 servo. Both require a 50Hz frequency > according to the datasheet. I adjusted this in the servo driver. > > > this is because currently only the 8 bit timers are used for PWM. There are > > also 16 bit timers that can be used for PWM, but those are not yet > > implemented. > > I heard that @benpicco's avr-rss2 boards have an on-board LED connected to > > the > > 16 bit PWM output - so he might jump on this and implement the missing 16 > > bit > > support ;-) > I might have a look myself if I can find some time to spare. However, > the project I'm working on also has its deadlines, so I might also just > cheat by ordering a I2C PWM controller breakout board instead. > > > But I still find it a bit strange though. I quote @smlng on #10498: > "/Please note, that this finally brings in the missing PWM periph for > the atmega-based Arduinos/". It sounds like PWM should work just fine on > this board (unless RIOT handles arduino boards differently than > non-arduino boards with the same cpu, but that sounds unlikely). Why > would it suddenly not work anymore? > > > Kind regards, > > Wouter > > > On 9/1/20 8:39 PM, Marian Buschsieweke wrote: > > Hi, > > > >> I was wondering if it is even possible at all. The current version of > >> the PWM peripheral has its resolution limited to 256. > > this is because currently only the 8 bit timers are used for PWM. There are > > also 16 bit timers that can be used for PWM, but those are not yet > > implemented. > > I heard that @benpicco's avr-rss2 boards have an on-board LED connected to > > the > > 16 bit PWM output - so he might jump on this and implement the missing 16 > > bit > > support ;-) > > > > Not that for ATmegas currently only PWM_LEFT is implemented, PWM_RIGHT and > > PWM_CENTER won't work. So, double check that you are using PWM_LEFT. > > > > Do you have an logic analyzer at hand to confirm the PWM output is correct? > > Otherwise, the brightness of an LED connected to the PWM output should also > > be > > good indicator. (Don't forget to take into account that most ATmegas > > operate at > > 5 V when choosing the resistor for the LED ;-)) Does the serve has any > > requirements on the PWM frequency? > > > > Kind regards, > > Marian > > > > On Tue, 1 Sep 2020 20:00:09 +0200 > > Wouter Symons <wo...@airsantelmo.com> wrote: > > > >> Hello all, > >> > >> I spent quite some time yesterday trying to get a servo working on an > >> atmega1284p, unfortunately to no avail. > >> > >> I was wondering if it is even possible at all. The current version of > >> the PWM peripheral has its resolution limited to 256. I think this > >> limitation is probably the cause for it not working. > >> > >> I tried removing the asserts that enforce this limitation, and this > >> caused the servo to rotate into one direction, but then stop moving > >> again (I could not get it to rotate in the other direction). > >> > >> I tried the same servo on a nucleo-board and this worked just fine. > >> However... only with a resolution way higher than 256. (Because STM32 > >> does not have this limitation) > >> > >> So I wonder... should atmega be blacklisted for this test, since it > >> cannot work? And would there maybe be a workaround to this problem? I'm > >> not that experienced on this matter, so I'm not really sure why the > >> limitation on this resolution was put in place, but is it possible to > >> make changes to the peripheral driver so we can increase it? > >> > >> It's also possible that I'm simply doing something very wrong, and that > >> it should work without any changes. (hence the reason I asked on this > >> mailing list instead of opening an issue straight away) > >> > >> Kind regards, > >> > >> Wouter > >> > >> _______________________________________________ > >> devel mailing list > >> devel@riot-os.org > >> https://lists.riot-os.org/mailman/listinfo/devel > > > > _______________________________________________ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel
pgp8QO9QM21YR.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
