Re: [Amforth] TIMER1 input capture with noop vs 1ms
On 08Jun18 14:57, Matthias Trute wrote: > Am Donnerstag, den 07.06.2018, 21:05 +0100 schrieb Tristan Williams: > > Hello, > > > > I am clearly not understanding how something works, and would be > > grateful for any help. > > > > I am decoding infrared remote control codes using the input capture > > mode of TIMER1 on an ATmega328P (UNO). This works successfully. > > > > Then I decided to buffer the codes received, so that should the MCU > > be > > busy, the codes be collected by the isr will still be available for > > when the MCU is ready. > > > > To test this, I have been using these three "busy" words > > > > : busy1 10 0 ?do $ 0 ?do noop loop loop ; > > > > : busy2 5000 0 ?do 1ms loop ; > > > > : busy3 5000 0 ?do pause 1ms loop ; > > I can only guess, but it seems that the 1ms delay is way too > long. Interrupts are handled inside the inner interpreter and > 1ms does not get aborted when an interrupt occurs. That may > lead to lost bytes in your input buffer. > > Matthias > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel > Matthias, Thank you. Yes, this helps a lot. I had not appreciated that 1ms would not be interrupted. Having read http://amforth.sourceforge.net/TG/AVR8.html more carefully, I now understand why busy1 works, but busy2 does not. Many thanks, Tristan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] TIMER1 input capture with noop vs 1ms
Am Donnerstag, den 07.06.2018, 21:05 +0100 schrieb Tristan Williams: > Hello, > > I am clearly not understanding how something works, and would be > grateful for any help. > > I am decoding infrared remote control codes using the input capture > mode of TIMER1 on an ATmega328P (UNO). This works successfully. > > Then I decided to buffer the codes received, so that should the MCU > be > busy, the codes be collected by the isr will still be available for > when the MCU is ready. > > To test this, I have been using these three "busy" words > > : busy1 10 0 ?do $ 0 ?do noop loop loop ; > > : busy2 5000 0 ?do 1ms loop ; > > : busy3 5000 0 ?do pause 1ms loop ; I can only guess, but it seems that the 1ms delay is way too long. Interrupts are handled inside the inner interpreter and 1ms does not get aborted when an interrupt occurs. That may lead to lost bytes in your input buffer. Matthias -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
[Amforth] TIMER1 input capture with noop vs 1ms
Hello, I am clearly not understanding how something works, and would be grateful for any help. I am decoding infrared remote control codes using the input capture mode of TIMER1 on an ATmega328P (UNO). This works successfully. Then I decided to buffer the codes received, so that should the MCU be busy, the codes be collected by the isr will still be available for when the MCU is ready. To test this, I have been using these three "busy" words : busy1 10 0 ?do $ 0 ?do noop loop loop ; : busy2 5000 0 ?do 1ms loop ; : busy3 5000 0 ?do pause 1ms loop ; With busy1, IR codes transmitted whilst the busy word is executing are correctly captured, decoded and buffered. With busy2 and busy3 they are not. Turning on a LED when the isr detects the start pulse, and turning it off when a complete code (or a repeat) has been received shows for the isr calls busy1 - entry and exit and valid code (always, it seems) busy2, busy3 - enters, but often seems to get stuck, the LED is not turned off (and the code buffered invalid) I am puzzled as to why it works with busy1, but not with busy2 and busy3. All clues gratefully received. Tristan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
