VisualApplets
User Manual

앱들 프로세스는 해당 프로세스의 모든 DMA가 시작된 후에만 하드웨어에서 사용할 수 있습니다. 그러나 프로세스에 DMA 채널이 포함되어 있지 않은 경우 앱들 초기화 직후에 즉시 시작됩니다. 이는 이미지 획득이 시작되기 전에 사용되는 트리거 및 신호 처리 응용 프로그램에 유용합니다.

하드웨어에서 VisualApplets 앱들의 초기화 및 사용에 대해 자세히 알아보려면 '하드웨어에서 앱들 실행하기' 섹션 및/또는 Framegrabber SDK 문서를 참조하세요.

프로세스 간 이미지 데이터는 상호 교환할 수 없습니다. 그러나 TxSignalLinks 및 RxSignalLinks 연산자를 사용하면 신호에 대한 프로세스 간 통신을 설정할 수 있습니다.

앱들 내 파이프라인의 대역폭은 연산자의 처리 속도와 연결된 링크에 따라 달라집니다. 링크에는 여러 개의 “링크 속성”('링크 속성' 참조)이 있습니다. 그중 하나가 대역폭을 정의하는 Parallelism입니다. Parallelism은 하나의 디자인 클록 주기 동안 두 연산자 사이에서 병렬로 전송되는 픽셀 수를 정의합니다. Parallelism이 높을수록 대역폭이 높아집니다. 연산자는 링크의 필수 대역폭을 충족하도록 자동으로 조정되며, 이것이 불가능한 경우 대역폭을 재정의합니다. Parallelism에 대한 실용적인 지침은 Parallelism 튜토리얼 항목을 참조하세요.

그림 34. 클록 주파수 125 MHz에서의 Parallelism

간단한 예를 가정해 보겠습니다. Parallelism이 4이면 4개의 픽셀이 병렬로 전송됩니다. 즉, 이미지의 처음 4개의 연속된 픽셀이 카메라 모듈에서 후속 모듈(이 경우 버퍼)로 병렬 전송됩니다. 다음으로, 다음 4개의 픽셀이 카메라 모듈에서 버퍼 모듈로 전송됩니다. 그 동안 처음 4개의 픽셀은 버퍼 모듈에서 처리되어 이미지 처리 체인의 다음 모듈로 전달됩니다.

앞서 언급했듯이 Parallelism은 디자인 클록 주파수의 한 클록 주기에서 병렬로 전송되는 픽셀 수를 정의합니다. 주파수는 사용되는 하드웨어 장치에 따라 다릅니다. 예를 들어, microEnable IV 시리즈의 프레임 그래버는 62.5MHz의 디자인 클록 주파수를 사용합니다.

	대역폭 계산
	링크의 대역폭 b는 Parallelism p와 주파수 f의 곱으로 결정됩니다.

따라서 4의 Parallelism은 다음과 같은 대역폭을 초래합니다. . 픽셀당 8 bit의 Bit Width를 가정하면 이는 250MB/s의 대역폭을 생성합니다. 모든 하드웨어 플랫폼의 기본 디자인 클럭 주파수 목록은 다음에서 확인할 수 있습니다. 장치 리소스.

오퍼레이터는 입력 링크와 출력 링크 간의 Parallelism을 변경할 수 있습니다. 따라서 대역폭은 디자인 전반에 걸쳐 일정하지 않습니다. 이는 필요한 대역폭이 변경될 수 있기 때문입니다. 오퍼레이터가 이미지 크기를 줄인다고 가정해 보겠습니다. 이 경우 필요한 출력 대역폭도 감소합니다.

위 공식으로 계산된 대역폭은 이론적인 값입니다. 실제 대역폭은 이론적 값보다 약간 낮습니다.

	중요
	일부 오퍼레이터는 입력 링크에서 제공되는 전체 대역폭을 처리할 수 없습니다. 관련 오퍼레이터에 대한 자세한 내용은 Operator Reference에서 확인할 수 있습니다.

대역폭과 지연 시간(latency)의 차이에 유의하십시오. 지연 시간은 각 오퍼레이터에 의해 개별적으로 정의되며 주로 알고리즘 구현에 따라 달라집니다.

	GUI에서의 시각화
	해당 링크 속성을 시각화하기 위해 VisualApplets은 프로그램 창의 툴바에 두 개의 GUI 버튼을 제공합니다. 링크 정보 표시 다이어그램의 모든 링크에 대한 bit width와 Parallelism을 표시합니다. 링크 처리량 표시 다이어그램의 모든 링크에 대한 초당 메가픽셀 단위의 최대 픽셀 처리량을 표시합니다.

앞서 설명한 바와 같이 VisualApplets에서는 픽셀이 파이프라인을 통해 차례대로 전송됩니다. 링크 Parallelism이 1보다 크면 여러 픽셀이 병렬로 전송됩니다. 이미지나 라인에서 픽셀 전송 순서는 다음과 같습니다. 일반적으로 프레임(2차원 이미지)의 픽셀은 카메라에서 왼쪽 상단 모서리의 첫 번째 픽셀부터 시작하여 오른쪽 하단 모서리의 마지막 픽셀로 끝나는 순서로 전송됩니다. VisualApplets 오퍼레이터가 처리를 위해 픽셀 위치를 필요로 하는 경우 왼쪽 -> 오른쪽, 위쪽 -> 아래쪽과 같은 동일한 순서가 예상됩니다. 다음 그림은 이 순서를 보여줍니다.

그림 35. 픽셀 순서

그러나 카메라와 같은 일부 소스는 이 순서를 따르지 않습니다. 이러한 경우 VisualApplets 오퍼레이터와 디자인을 사용하여 픽셀 순서를 수정할 수 있습니다. 이렇게 하려면 픽셀 전송 프로토콜에 대한 약간의 지식이 있어야 합니다. 관련 정보는 'Image Protocols, Image Dimensions and Data Structure' 섹션에서 확인할 수 있습니다.

Image Protocol은 전송된 픽셀 및 데이터의 이미지 차원과 데이터 구조를 정의합니다. Image Protocol은 앞서 언급한 링크 속성인 Parallelism 외에 또 다른 링크 속성입니다.

이미지 프로토콜에는 세 가지 유형이 있습니다.

이미지 프로토콜은 링크 Property입니다. 각 오퍼레이터는 입력에서 허용되고 출력에서 사용 가능한 링크 Property를 개별적으로 결정합니다. 링크 매개변수화에 대한 자세한 내용은 'Link Properties'를 참조하십시오.

이 이전 섹션에서는 VisualApplets 디자인의 파이프라인 구조에 대해 설명했습니다. 앞서 언급했듯이 데이터는 링크를 통해 프로젝트의 모듈 간에 전송됩니다. 모듈이 입력 픽셀을 처리하고 출력 값 계산을 마치면 결과가 출력 링크로 출력됩니다. 그러나 다음 모듈이 여전히 다른 픽셀을 처리 중이어서 데이터를 처리할 수 없는 경우가 있습니다. 이 경우 VisualApplets의 흐름 제어가 적용되고 파이프라인이 차단됩니다. 따라서 모듈은 입력을 차단할 수 있습니다. 이 경우 이전 모듈은 결과를 출력하지 않고 파이프라인에서 차단 상태를 역방향으로 전파합니다.

그림 33, '간단한 VisualApplets 디자인'에 표시된 간단한 예제를 살펴보겠습니다. 카메라에서 생성된 대역폭을 처리할 수 없는 느린 PC가 사용된다고 가정해 보겠습니다. 이 경우 DmaToPC 모듈은 호스트 PC로 데이터를 전송할 수 없습니다. 따라서 수시로 입력을 차단합니다. 차단 신호는 디자인 내에서 이미지 버퍼 모듈까지 전파됩니다. 이제 이미지 버퍼는 차단이 활성화되어 있는 동안 데이터를 출력하지 않습니다. ImageBuffer 모듈은 버퍼이므로 들어오는 모든 추가 데이터가 버퍼링되고 버퍼의 Fill 수준이 증가합니다. 카메라가 데이터 전송을 중지하면 새 입력 데이터가 버퍼로 전송되지 않고 버퍼가 빌 때까지 데이터가 출력됩니다.

	팁
	다시 말하지만, 흐름 제어는 물 파이프라인에 비유할 수 있습니다. 밸브가 닫히면 더 이상 물을 운반할 수 없습니다. 버퍼 오퍼레이터는 배출구가 입력 스트림을 소모할 수 없는 경우 물이 채워지는 저수지와 같습니다.

중단 가능한 데이터 스트림 및 중단 불가능한 데이터 스트림 튜토리얼 항목도 참조하십시오.