2017-10-17 7 views
0

ファームウェアの一部として、グラフィックまたはグラフィックスをMCUのEEPROMに保存します。スペースはそれほど大きくはありませんが、プログラムのスペースを節約できます。そして、グラフィックスのグリフをスペースを節約するために分離することはできますが、管理が容易ではなく、より適切なコードを表示する必要があります。グラフィックをEEPROMに保存し、フィルタを使ってグラフィックを圧縮し、スペースを節約するために0x00と0xFFを繰り返す[解決]

ほとんどのモノクロのGUIグラフィックスは画面全体を満たさず、空き領域や繰り返しピクセルを含んでいます。画像はすでに圧縮されており、1バイトの各ビットは8ピクセルを表します。

128x32ピクセルの小さなディスプレイにグラフィックを表示します。それを表示して、関係のない部分を消去し、完璧に細かく効率的に動作させます。

私は、これらのリピートをフィルタリングして少し圧縮するというアイデアを考え出しました。成功すると、このようなビットマップ(以下を参照)は496バイトで、私のメソッドは401バイト以下の '圧縮'されます。しかし、あまり鳴らない


enter image description here


利用できる唯一の1Kのストレージがある場合には本当に素晴らしい合計サイズが20%減少、です。バイト配列の

例:

PROGMEM const uint8_t TEP_DISPLAY [] = { /* 496 bytes */ 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x80, 0x00, 0x00, 0x00, 0x00, 
0x06, 0x00, 0x80, 0x90, 0x00, 0x3E, 0x01, 0x80, 0x03, 0xC0, 0x01, 0x80, 0x00, 0x47, 0x0F, 0xFE, 
0x17, 0x01, 0xC0, 0x90, 0x00, 0x30, 0x00, 0x00, 0x03, 0x60, 0x01, 0x80, 0x01, 0x87, 0x10, 0x02, 
0x30, 0x83, 0xE3, 0xFC, 0x00, 0x61, 0xE7, 0x39, 0xB6, 0x6F, 0x0F, 0x00, 0x03, 0x07, 0x36, 0xDA, 
0x7F, 0xF0, 0x83, 0xFC, 0x7C, 0x7D, 0xB3, 0x6D, 0xB6, 0x61, 0x9B, 0x1F, 0x03, 0x87, 0x36, 0xDA, 
0x30, 0x43, 0xE1, 0xF8, 0x00, 0x61, 0xB3, 0x6D, 0xA7, 0xCF, 0xB3, 0x00, 0x01, 0x80, 0x36, 0xDA, 
0x13, 0x81, 0xC0, 0x60, 0x00, 0xC3, 0x66, 0x6D, 0xCC, 0x1B, 0x36, 0x00, 0x01, 0x07, 0x10, 0x02, 
0x03, 0x00, 0x80, 0x60, 0x00, 0xFB, 0x66, 0x39, 0x8C, 0x0F, 0x1E, 0x00, 0x02, 0x07, 0x0F, 0xFE, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06, 0x01, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x1C, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x2A, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xA2, 0xD5, 0x54, 
0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x14, 0x00, 0x02, 
0x00, 0xC0, 0x22, 0x00, 0x08, 0x00, 0x02, 0x20, 0x00, 0x82, 0x48, 0x20, 0x00, 0x08, 0x00, 0x00, 
0x40, 0xC0, 0x01, 0xE0, 0x00, 0x01, 0xC0, 0x1E, 0x00, 0x01, 0x50, 0x00, 0xFE, 0x00, 0x0C, 0x02, 
0x00, 0xC0, 0x20, 0x10, 0x08, 0x07, 0xC2, 0x01, 0x00, 0x80, 0x00, 0x21, 0x01, 0x08, 0x0E, 0x00, 
0x4F, 0xFC, 0x00, 0xFE, 0x00, 0x0F, 0x40, 0x3F, 0xF8, 0x03, 0xF8, 0x03, 0x01, 0x80, 0x0B, 0x02, 
0x1C, 0xC2, 0x21, 0x11, 0x08, 0x1C, 0x42, 0x40, 0x04, 0x84, 0x04, 0x21, 0x11, 0x08, 0x69, 0x80, 
0x59, 0xE2, 0x01, 0x11, 0x00, 0x18, 0x40, 0x55, 0x54, 0x05, 0x54, 0x03, 0x39, 0x80, 0x3B, 0x02, 
0x12, 0xD2, 0x21, 0x11, 0x08, 0x10, 0x42, 0x40, 0x04, 0x84, 0x04, 0x21, 0x7D, 0x08, 0x1E, 0x00, 
0x54, 0xCA, 0x01, 0x83, 0x00, 0x10, 0x40, 0x55, 0x54, 0x05, 0x54, 0x03, 0x11, 0x80, 0x3E, 0x02, 
0x12, 0x12, 0x21, 0x01, 0x08, 0x11, 0xC2, 0x40, 0x04, 0x84, 0x04, 0x21, 0x11, 0x08, 0x6B, 0x00, 
0x51, 0xE2, 0x01, 0x01, 0x00, 0x13, 0xC0, 0x47, 0xC4, 0x04, 0x44, 0x01, 0x11, 0x00, 0x09, 0x82, 
0x10, 0x02, 0x21, 0x01, 0x08, 0x71, 0x82, 0x40, 0x04, 0x84, 0x04, 0x23, 0x01, 0x88, 0x0B, 0x00, 
0x4F, 0xFC, 0x01, 0xFF, 0x00, 0xF0, 0x00, 0x3F, 0xF8, 0x05, 0x54, 0x01, 0x01, 0x00, 0x0E, 0x02, 
0x0F, 0xFC, 0x20, 0xFE, 0x08, 0x60, 0x02, 0x1F, 0xF0, 0x84, 0x04, 0x20, 0xFE, 0x08, 0x0C, 0x00, 
0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02 
}; 

まだ一つの問題であり、私はそれがコード内の小さな誤りだと思うと考えるようにそれに数日を過ごすので、私は(それを検出することはできませんそれをいくらか小さくする方法)。多分、問題を解決するために私を正しい方向に向けることができる人がいるでしょう。そのような空のスペースを繰り返す線または0x00の繰り返し0xFFの多くと同様の255回のを超える反復が、similartiesの割り当てるある場合

問題

問題が発生します。私のコードでは、バイトオーバーフローを避けるためにいくつかの予防措置を講じていますが、失敗する(そして今はなぜか分かりません)。私がやろうとしているのは、オーバーフローがあり、それを記録し、数えてもう一度始めることです。私はそれが読取り機能または書込み機能の問題であることを理解できません。

これは、ストレージここ

At start address: 
----------------- 
<byte width> 
<byte heigth> 
<uint16 dataSize> 
<data> 
    <if data=0xFF> 
    <0xFF> 
    <repeat count> 
    </if> 
    <if data=0x00> 
    <0x00> 
    <repeat count> 
    </if> 
<else data> 
</data> 

のレイアウトである私のコードです:

<cut, see answer below> 

任意のアイデアは?


注:

私はプログラム空間の96%がすでに使用中であると、私の方法は、正常に動作するようだが、と、高価な圧縮方法を使用したくありませんいくつかのエラーと私はエラーを、代替圧縮方法を知る必要があります。これはすでにいくつかの圧縮を持っていますが、8ビットを表現するバイトのビットはちょっと薄くしたいだけです(バイトオーバフロー時にエラーが発生することが証明されています)。


EDIT 18 OKT 2017

は私の答えと、以下の新しいコードを参照してください。

+0

Bad hairday guys?あなたがdownvoteとき-1理由を説明します。 – Codebeat

答えて

0

少し眠った後、私はずっと良い結果と少ないコードでそれをやり直しました。そのようなことをあまりにも複雑すぎました。

私は印象的な結果を得て、最も多く繰り返すバイトを選択してこれをEEPROMの 'ファイル'に記録することで、最良の圧縮を見つけるための検査方法でそれを洗練することを考えています。

とにかく、これは私のコードで、最初のものと比べるとはるかに優れています。おそらく他の人に役立つかもしれません。いくつかのバイトを節約するための非常に軽量なソリューションです。

たとえば、128x32ピクセルの解像度を持つ空白の画面またはフルスクリーンでは、半分だけが17バイトで、9バイトしか表示されません。私が前に質問したスクリーンは405バイトにコンパイルされ、約100バイトの節約となりました。ここで


私のリニューアルコードです:

uint8_t TOLEDdisplay::getCacheRawBits(uint16_t iAddress) 
{ 
    if(iAddress < cacheSize) 
    { return displayCache[ iAddress ]; } 

    return 0x00; 
} 

bool TOLEDdisplay::setCacheRawBits(uint16_t iAddress, uint8_t iBitByte) 
{ 
    if(iAddress < cacheSize) 
    { 
    displayCache[ iAddress ]=iBitByte; 
    return true; 
    } 

    return false; 
} 

uint16_t TOLEDdisplay::writeToEeprom(uint16_t iAddress) 
{ 
    if(cacheSize == 0 || width == 0 || height == 0) 
    { return 0; } 

    uint8_t iBits;    // Pixel * 8 = byte 
    uint8_t iFoundBits;   // 'Type' of detected 
    uint16_t iByteSize = 0;  // Total byte size of stream 
    uint8_t iCount = 0;  // Count of repeats found 
    bool  bSame;    // Boolean to evaluate repeats 

    // Write screen bounds, when read it back with readFromEeprom, 
    // these bounds need to match with current screen bounds. 
    EEPROM.write(iAddress++, width); 
    EEPROM.write(iAddress++, height); 

    // Reserve two bytes for stream size 
    uint16_t iSizeAddress = iAddress; 
    iAddress+=2; 

    // Write the cache content to the EEPROM 
    uint16_t i = 0; 
    while(i < cacheSize) 
    { 
    // Get a byte with bits 
    iBits = getCacheRawBits(i); 
    ++i; 

    // Find repeating lines or empty lines 
    if(iBits == 0xFF || iBits == 0x00) 
    { 
     iFoundBits = iBits; // Set found bits to detect changes 
     bSame  = true; // Set to true to able to start loop 
     iCount=1;   // Count this found one 

     // Loop to find duplicates 
     while(bSame && (iCount < 0xFF) && (i < cacheSize)) 
     { 
      iBits = getCacheRawBits(i); // Get next byte with bits 
      bSame = (iBits == iFoundBits); // Determine is repeat, the same 
      iCount+=bSame;     // Increment count when same is found 
      i+=bSame; 
     }  

     // Finally write result to EEPROM 
     EEPROM.write(iAddress++, iFoundBits); // type 
     // Write the amount 
     EEPROM.write(iAddress++, iCount); // count 

     // Goto main loop and find next if any 
    } 
    else { 
      // Write found value normally to EEPROM 
      EEPROM.write(iAddress++, iBits); 
     } 
    } 

    // Final EOF address is one pos back 
    --iAddress; 

    // Calculate stream size 
    iByteSize=iAddress-iSizeAddress; 
    uint8_t* pByteSize = (uint8_t*)&iByteSize; 

    // Write size of stream 
    EEPROM.write(iSizeAddress , *pByteSize++); 
    EEPROM.write(iSizeAddress+1, *pByteSize); 

    // return bytes written including width and height bytes (+2 bytes) 
    return iByteSize+2; 
} 

bool TOLEDdisplay::readFromEeprom(uint16_t iAddress) 
{ 
    uint8_t iBits; 
    uint8_t iRepeats; 
    uint16_t i  = 0; 
    uint8_t* pI  = (uint8_t*)&i; 

    uint8_t iWidth = EEPROM.read(iAddress++); 
    uint8_t iHeight = EEPROM.read(iAddress++); 

    // Read stream size, read two bytes 
    *pI = EEPROM.read(iAddress++); 
    *pI++; 
    *pI = EEPROM.read(iAddress++); 

    // Clear the screen 
    clear(); 

    // If an error (no image on EEPROM address) or screen bounds 
    // doesn't match, skip to continue 
    if(i == 0 || iWidth != width || iHeight != height) 
    { 

    update(true); // Set screen to blank 
    return false; 
    } 

    uint16_t iCacheAddress = 0; 

    while(i--) 
    { 
     // Get a byte with bits 
    iBits = EEPROM.read(iAddress++);  

     // Explode repeats if detected 
    if(iBits == 0xFF || iBits == 0x00) 
    { 
     // read amount of repeats 
     iRepeats = EEPROM.read(iAddress++); 

     // Explode it into cache 
     while(iRepeats--) 
     { setCacheRawBits(iCacheAddress++, iBits); } 
    } 
    else { 
      // Put value normally into cache 
      setCacheRawBits(iCacheAddress++, iBits); 
      } 
    } 

    // Done, update the screen 
    update(true); 

    // Return success 
    return true; 
} 

たぶん私はいくつかのEEPROM boundryチェックを追加する必要がありますが、今のところ、それは正常に動作します。

2

ループを初めて実行すると、bFFOverflowbZeroOverflowは初期化されずにアクセスされます。

しかし、主な問題は、255 0または0xFFバイトを記録した後に、それ以上ある場合はカウントを1に設定することです。ただし、そのバイトの255番目のコピーを数えた後にオーバーフローを検出するので、これはゼロになるはずです。

したがって、常にbFFOverflowbZeroOverflowを0に設定すると、カウントが書き込まれます。

+0

こんにちは、ありがとうございました。あなたは正しいのではない、条件を確認する前にブール値を初期化する。そして、私はあなたが数えることになると、あなたも正しくないと信じています。オーバーフローが発生した場合、0x00または0xFFの両方の条件のいずれかであった場合、1つも残っています。しかし、それを見てみましょう;-)ありがとう – Codebeat

+0

ちょうどそれが偽に初期化部分のブール値を変更するテストは、意味をなさない。 – Codebeat

関連する問題