Menu

Reduce Buffersize in PPMOut

Bugs
Linkmar
2013-08-19
2013-08-20
  • Linkmar

    Linkmar - 2013-08-19

    Imagine 5Channels PMM --> Your Code needs 34Byte for g_work, where 24byte should suffice! A lot of Slots have the same content (m_pulseLength) --> Space is very rare on the µC. The supplied Code works like a charm and replaces the old 1:1.

    First Change in PMMOut.h:

    #define PPMOUT_WORK_SIZE(channels) ((2*channels + 2)*2)
    

    Second Change is in PMMOut.cpp:

    void PPMOut::updateTimings()
    {
        uint16_t* scratch = m_timings;
    
        *scratch = m_pulseLength;
        ++scratch;
    
        // copy all pre-calculated timings
        for (uint8_t i = 0; i < m_channelCount; ++i)
        {
    
            // set timing
            *scratch = m_channelTimings[i] - m_pulseLength;
            ++scratch;
        }
    
        // set pause length
        *scratch = m_pauseLength - m_pulseLength;
    
        // update number of timings
        m_timingCount = (m_channelCount + 1) * 2;
    }
    
    void PPMOut::isr()
    {
        // set the compare register with the next value
        if (m_timingPos & 1) {
            OCR1A += m_timings[(m_timingPos>>1)+1]
        } else {
            OCR1A += m_timings[0];
        }
    
        // toggle pin, pins 9 and 10 will toggle themselves
        if (m_port != 0)
        {
            *m_port |= m_mask;
        }
    
        // update position
        ++m_timingPos;
        if (m_timingPos >= m_timingCount)
        {
            m_timingPos = 0;
    
            // we're at the end of frame here, so there's plenty of time to update
            updateTimings();
        }
    }
    
     

    Last edit: dvdouden 2013-08-20
    • dvdouden

      dvdouden - 2013-08-20

      Thanks for the contribution Linkmar! The reason a few bytes of RAM were sacrificed is to ensure a constant number of clock cycles between the start of the interrupt and the toggling of the output pin. Not that it matters much, your approach makes the pause a few clock cycles longer and the pulse a bit shorter (for software toggled pins). Still this is no problem since only the time between two pulses is important, not the duration of the pulse itself.

      The following might even be a bit faster/shorter:

      OCR1A += m_timings[m_timingPos & 1 ? ((m_timingPos >> 1) + 1) : 0];
      

      Created ticket [#60]

       

      Related

      Tickets: #60

Anonymous
Anonymous

Add attachments
Cancel





Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.