Nowlog

혹시 외국에서 사시거나 잠깐 나가계시거나 외국계회사, 필요에따라 VPN 을 연결해서 외국에서 있는 경우가 있습니다.

이럴 때는 위치를 기반으로 Google 에서 검색 결과를 제공해 줍니다. 

때문에 해석을 해야한다던가 쉽게 알아보기 어려운 경우가 많아 우리나라 웹을 Google 에서 먼저 검색해보고 싶을 경우가 많습니다. 

2가지를 통해 사용할 수 있습니다. 

[ Google 설정을 통해 영구적 변경 ]

 1. Google 홈페이지를 들어갑니다. 

2. 아래 위치의 설정을 클릭합니다. 

3. 검색 설정 클릭

4. 검색 결과 -> 지역 설정 에서 본인의 지역을 설정합니다. 

[ 일시적 변경 ]

1. 검색을 합니다. 

2. 도구 --> 모든언어 에서 한국어 웹으로 변경합니다. 

typedef struct RTC_SR1 {
  union {
    struct {
      uint16_t reserved0  :  7;
      uint16_t WPNDCR0    :  1;  /**< Pending status of posted writes to RTC Control 0 Register */
      uint16_t WPNDSR0    :  1;  /**< Pending status of posted clearances of interrupt sources in RTC Status 0 Register */
      uint16_t WPNDCNT0   :  1;  /**< Pending status of posted writes to RTC Count 0 Register */
      uint16_t WPNDCNT1   :  1;  /**< Pending status of posted writes to RTC Count 1 Register */
      uint16_t WPNDALM0   :  1;  /**< Pending status of posted writes to RTC ALARM 0 Register */
      uint16_t WPNDALM1   :  1;  /**< Pending status of posted writes to RTC ALARM 1 Register */
      uint16_t WPNDTRM    :  1;  /**< Pending status of posted writes to RTC Trim Register */
      uint16_t reserved14 :  2;
    };
    uint16_t VALUE16;
  };
} RTC_SR1;

위의 코드는 4 byte 짜리 구조체를 선언하였습니다. 4 byte 구조체에서 8 번째 1 bit, 9번째 1 bit 를 사용하기 위해서는 위와 같이 union 으로 4 byte 를 공용해서 사용하면 사용이 매우 수월해지네요. 

RTC_SR1.WPNDCR0 = 0  과 같이 사용이 가능합니다. 

C# 에서 C 언어 처럼 pointer 개념을 사용할 수 있다. pointer 개념은 네트워크 패킷 보낼때 많이 사용한다.

 Marshal.StructureToPtr(this, (IntPtr)fixed_buffer, false);

unsafe 라고 compiler 에 지시자로 알려주어야 한다. 

        public void GetBuffer(byte[] outBuffer)
        {
            if (0 == outBuffer.Length)
                outBuffer = new byte[PACKET_MAX_LEN];

            unsafe
            {
                fixed(byte* fixed_buffer = outBuffer)
                {
                    Marshal.StructureToPtr(this, (IntPtr)fixed_buffer, false);
                }
            }
            
        }

하지만 unsafe 한 항목이어서 컴파일이 안되서 아래처럼  Allow unsafe code 옵션을 설정해 주면 컴파일이 된다. 

Visual Studio 의 자동 "//" 커멘트 단축키는 Ctrl + K, Ctrl + C 이다. 

하지만 Source Insight 나 다른 개발툴에서 익숙해져 왔던 단축키는 

Comment : Ctrl + Shift + /

Uncomment : Ctrl + Shift + \

여서 변경하였다. 

변경 방법

1. Main menu 의 Tool

2. Options

3. Environment

4. Keyboard

5. Show commands containing: 에서 "Comment" 로 검색

6. Edit.CommentSelection 에 Press shortcut keys 에 Ctrl + Shift + / 키를 직접 눌러서 설정 

7. Edit.UncommentSelection 에 Press shortcut keys에  Ctrl + Shift + \ 키를 직접 눌러서 설정 

*TouchGFX SPI LCD 사용시 반만 Display 되는 경우 *

TouchGFX 사용시 Serial 방식을 사용할 경우 FrameBuffer 를 한줄씩 보내는 코드입니다.

void TouchGFXHAL::copyFrameBufferBlockToLCD(const Rect& rect)
{
    __IO uint16_t* ptr;
    uint32_t height;

    // This can be accelerated using regular DMA hardware
    for (height = 0; height < rect.height ; height++)
    {
        ptr = getClientFrameBuffer() + rect.x + (height + rect.y)  * BSP_LCD_GetXSize();
        LCD_IO_WriteMultipleData((uint16_t*)ptr, rect.width);
    }
}

TouchGFX 의 공식 Support 홈페이지에 있는 코드인데 32bit 임베디드 시스템을 사용할 경우 생각대로 동작 안할 수 있습니다.

support.touchgfx.com/docs/development/touchgfx-hal-development/scenarios/scenarios-fmc

예를 들면,

#define FRAME_BUF_ADDR   0xD0000000
#define WIDTH            320
#define COLOR_DEPTH      3

__IO uint16_t* ptr;
ptr = FRAME_BUF_ADDR;
ptr = ptr + (WIDTH * COLOR_DEPTH);

0xD0000000 + (320 * 3) = 0xD00003C0 을 예상합니다.

하지만, 0xD00000780 이 나옵니다.

void TouchGFXHAL::copyFrameBufferBlockToLCD(const Rect& rect)
{
    __IO uint8_t* ptr;
    uint32_t height;

    // This can be accelerated using regular DMA hardware
    for (height = 0; height < rect.height ; height++)
    {
        ptr = getClientFrameBuffer() + rect.x + (height + rect.y)  * BSP_LCD_GetXSize();
        LCD_IO_WriteMultipleData((uint8_t*)ptr, rect.width);
    }
}

0xD0000000 + (320 * 3) = 0xD00003C0 이 나옵니다.

기존 제품에 사용하던 SDRAM 이 단종이 되었다. 

새로운 SDRAM을 사용하려는데, CAS 가 다르다. 이게 과연 사용할 수 있는 것일까? 

이를 위해 기초 파라미터를 확인하고 왜 가능한지 확인해 보았다. 

현재 -7E 모델이 단종이 되고 -6A 모델은 생산을 한단다, 즉 7E 에서 6A 로 바꾸면 Firmware 수정없이 그대로 사용할 수 있는지 확인해야 한다. 

이론은 램타이밍의 tRAS, tRP, tRCD, CL, Refresh Time, RFC 를 일단 공부했다. 

일단 CL이 몇 Cycle 이 각각의 타이밍 마다 필요한지를 알아야 한다.

- 현재 SDRAM 에 동작하는 속도는 48MHz 이다.

- CL이 18ns 이고 Clock 이 48 MHz 이면 CL 의 소요cycle 은 18ns/(1/48MHz) = 0.864 cycle

(1 cycle 안에 끝나는 것이다. )

- CL이 20ns 이고 Clock 이 48 MHz 이면 CL의 소요 cycle 은 20ns/(1/48MHz) = 0.96 cycle

( 역시 1 cycle 안에 끝난다. )

--> 결론은 CAS 가 1 이상이면 모두 OK 이다. 

이와 같은 계산법으로 풀어보면 아래와 같은 표를 얻었다. 

--> 즉, Cycle 이 표보다 더 여유롭게 책정 되어 있다면 software 수정없이 사용해도 됨 

첨부 : 

일단 Study 를 해보면 아래와 같다. 출처는 남기고 퍼옴 (혹시 문제되면 삭제 하겠습니다. ) 

1. 램타이밍 항목 : Command Rate, tRAS, tRP, tRCD, CL

메모리는 메모리 컨트롤러로부터 명령을 받아 읽기/쓰기를 수행합니다. 한편 메모리 칩을 구성하는 셀은 마치 스프레드시트처럼 행(Raw)와 열(Column)로 구성되어 있습니다. 메모리컨트롤러가 무언가를 읽거나 쓰기 위해 셀에 접근하려면, 행 주소를 찾아낸 후 그행 안에서 열 주소를 찾아 최종적으로 목적지인 셀에 도착하게 됩니다. 이 과정을 도식화하면 아래와 같습니다.

Row Address Strobe Time : 줄여서 tRAS. 셀에 액세스되는 동안 그 셀이 속한 행은 반드시 액티브 상태로 유지되어야 하는데, 이를 위해 (액세스 전) 미리 Precharge 된 행이 액티브 상태를 유지해야만 하는 최소한의 시간을 규정한 것입니다. 다시 말해 Precharge 와  Precharge 사이의 주기를 규정한 값이고, 재차 다시 말하자면 이 시간 이내에 셀 액세스가 끝날 수 있도록 나머지 램 타이밍 값이 설정되어 있어야 합니다. 따라서 보통 CL + tRCD + tRP의 합보다 넉넉히 크게 주어지고, CL + tRCD + tRP와 조화를 이룰 경우 성능에 미치는 영향이 드러나지 않으나 지나치게 크면 성능이 떨어집니다. CR과 마찬가지로 사이클 단위로 매겨집니다.

RAS Precharge Time : 줄여서 tRP 라 불리는 값입니다. 앞서 tRAS 값을 주기로 하여 행 Precharge (Row Address Strobe Precharge)가 수행된다고 했는데 그 소요시간을 의미합니다. 역시 사이클 단위로 표기되며 작을수록 성능이 좋습니다.

Row Address to Column Address Delay Time : 줄여서 tRCD 라 불리는 값입니다. 위에서 그림으로 설명할 당시 메모리컨트롤러는 셀을 액세스하기 위해 행 주소를 찾고, 그 후 열 주소를 찾는다고 했었죠. 여기에 소요되는 딜레이를 의미합니다. 역시 사이클 단위로 표기되며 작을수록 성능이 좋습니다.

Column Access Strobe Latency : 줄여서 CAS Latency, 더욱 줄여 "CL"이라 부르는 값으로 한 행 내에서 첫 열부터 마지막 열까지를 액세스하는 데 소요되는 총 시간을 의미합니다. 역시 사이클 단위로 표기되며 작을수록 성능이 좋습니다. CR과 함께 성능에 영향을 크게 미치는 항목 중 하나입니다. 아래 표는 시중에서 흔히 구할 수 있는 DDR3/4 규격별 클럭/CL 값 조합에 따른 CL의 시간값을 나타낸 것입니다. 같은 색으로 칠해진 것들을 비교해 보면 더 높은 클릭_더느슨한 CL값을 갖는 제품이 낮은 클럭+타이트한 CL값을 갖는 것보다 CL의 시간값 자체는 오히려 더 타이트하기도 하다는 점을 보여주고 있습니다.

2. 램타이밍 항목 : Refresh Time, tRFC

위 그림을 말로 풀어 설명하면 메모리컨트롤러가 셀 액세스 명령을 발행하고 / 행 주소를 찾고 / 열 주소를 찾아서 / 해당 셀을 액세스하는 일련의 과정입니다. 보통 램 타이밍을 대표하는 항목은 위에서 살펴본 것의 역순인 CL-tRCD-tRP-tRAS-CR 순으로 나타내어 지는 경우가 많습니다. 예컨대 CL9-10-10-27-1T 따위로 나타내어지는 양식은 그러한 순서를 반영한 것입니다.

전체 작동 시나리오를 통틀어 보면 어쨌든 CL이 등장하는 횟수가 가장 많습니다. 버스트 모드에서마저 CL은 꼬박꼬박 사용되기 때문이죠. 반면 tRCD는 한 행 안에서 액세스될 때에는 생략 가능하고, tRP는 행이 다르더라도 페이지가 같으면 재차 생략 가능합니다. 따라서 CL에 의한 영향이 가장 크고, tRCD와 tRP가 차례로 그 뒤를 이음을 알 수 있습니다. 먼저 지적한 바 있듯 tRAS는 직접 성능에 관여하지는 않습니다. 따라서 메모리 스펙표에 CL-tRCD-tRP-tRAS 순으로 표기되는 것은 성능에 가장 영향을 많이 주는 것 순으로 나열한 합리적인 표기 순서라 할 수 있겠습니다.

3. 램타이밍 항목 : Refresh Time, tRFC

JEDEC이 규정한 바에 따르면 메모리 셀은 적어도 수십~수백 ms에 한번씩은 덧쓰기를 수행해 주어야만 합니다. 하지만 메모리를 구성하는 수십억개의 셀 (메모리의 용량을 비트로 환산하면 그대로 셀의 갯수입니다) 을 단번에 충전하는 것은 엄청난 전력 소비를 동반하는데다 인터페이스 자체에도 무리를 줍니다. 따라서 SDRAM은 '페이지'를 한 단위로 하여, 보다 짧은 주기 (μs, ns 단위) 로 개별 페이지를 순회하며 덧쓰는 정책을 사용하고 있습니다.

램타이밍 항목 중 Refresh Time 또는 tREF라는 이름을 가진 것은 바로 이 주기 (개별 페이지를 순회하며 덧쓰는 주기) 를 정하는 변수입니다. 덧쓰는 주기가 짧을수록 데이터 안정성은 올라가지만 (=자주 덧써 주므로) 작동속도가 느려집니다. (=자주 덧써야 하므로) 다른 램타이밍 항목이 소요되는 클럭사이클 갯수를 단위로 삼은 것과 달리 이 값은 직접 시간값을 단위로 사용한다는 점, 그리고 값이 작을수록 성능이 떨어진다는 점을 기억하시기 바랍니다. 여타의 램타이밍 항목들과는 반대되는 성질이죠.

만약 셀의 충전주기 상한이 64ms이고 메모리 모듈 내에 존재하는 총 페이지 수가 16,384개라면 64(ms) ÷ 16,384 = 0.0039(ms), 즉 매 3.9μs마다 페이지를 순회하며 덧쓰기를 수행해야 합니다. 실제로 대부분의 메인보드는 3.9μs의 배수가 되게끔 tREF를 설정할 수 있도록 옵션을 제공하고 있습니다. 바이오스 표기상 ms로 나타나는 경우가 더러 있는데, 밀리초가 아니라 마이크로초 단위라는 점 유념해야겠습니다.

tREF는 보통 직접 시간값으로 나타내어지므로, 다른 램타이밍 항목값이나 메모리의 유효클럭이 어떻게 설정되든 관계없이 절대적으로 적용되는 일종의 '쿨타임' 주기에 비유할 수 있습니다. 쿨타임이 자주 돌아올수록 작업 수행이 중단되니 성능이 저하되는 것이 당연하고, 쿨타임의 지속시간은 tRFC 만큼입니다. 메모리가 정상적으로 작동되는 시간은 이 쿨타임을 제외한 나머지 시간 동안입니다.

Reference :

https://udteam.tistory.com/808