동바리의 공부방

 최근 로컬 사용자명을 한글에서 영어로 바뀐뒤 wsl2 내용이 모두 삭제되는등의 문제가 발생했습니다.

그러던 중 제목과 같은 에러가 발생했는데 아래와 같이 해결합니다.

1. wsl2 쉘에서 vscode를 삭제합니다

sudo apt purge vscode

2. shell:~$ code
-bash: /usr/bin/code: No such file or directory

위와 같은 에러 로그 확인합니다.

3. vscode의 remote-wsl 확장팩을 삭제했다가 다시 설치합니다.

4. wsl2 쉘에서 code . 입력합니다.

만일 그래도 안된다면 아래와 같이 추가적으로 조치합니다. (제 경우가 이랬습니다.)

https://code.visualstudio.com/download# 에서 windows 버전 system installer를 선택해 설치합니다.

그리고 설치 도중 PATH는 꼭 잡게끔 선택해줍니다. (사실 설치하는 도중 아무것도 수정하지 않고 계속 next만 눌러주면 됩니다.)

그럼 정상 설치 완료됩니다. 그리고 다시 wsl2 쉘에서 code . 입력합니다.

위 사진과 같이 정상 실행되면서 처음의 에러가 발생하지 않는 것을 확인할 수 있습니다.

 업무상 1계층에서 4계층까지 다루는 업무가 많다보니 포스팅합니다.

 osi 1계층에서의 통신은 하드웨어 통신이죠. 예시로 rs-232 또는 u(s)art가 있습니다. 그리고 rs232는 아래와 같이 통신합니다.

 우선 송신 <-> 수신 이렇게 셋팅돼있습니다.

 이들이 rs232로 통신하기 위해서는 10비트가 필요합니다. 

 10비트의 내용은 다음과 같습니다.

 1 비트 : 통신을 시작하겠다는 시작 비트입니다.

 2~9비트 : 보내려는 데이터입니다. 총 2,3,4,5,6,7,8,9 번째 비트로, 1바이트 크기입니다.

 10 비트 : 통신을 종료하겠다는 종료 비트입니다.

 평상시에는 신호 레벨 1을 유지하고 있습니다. 그러다가 1에서 0으로 바뀐다면 통신을 시작합니다. 그리고 1 cycle을 기준으로 1비트씩 보냅니다. 그러다가 8비트 즉, 1바이트의 데이터 전송을 끝내기 위해서 신호레벨을 1로 고정시킵니다.

 데이터 전송 'A'를 생각해보겠습니다. 'A'의 아스키값은 65입니다. 그리고 65의 바이너리는 0100 0001입니다. rs232는 LSB부터 전송합니다. 즉 가장 우측 1부터 전송한다는 것이지요. 그러다가 마지막으로 가장 왼쪽에 있는 0을 보낼것이고, 전송을 종료하기 위해 신호레벨을 1로 유지할 것입니다.

아래 링크에 비동기 통신에 대해 설명이 잘돼있습니다. 

링크 : 

https://www.youtube.com/watch?v=NLIpEJjsGoA 

프로토콜의 스택을 어떻게 이해해야 하나 포스팅하겠습니다.

이해하기 쉽게 두 개를 비교해가며 알아볼게요. Thread 프로토콜과 Zigbee 프로토콜 알아보겠습니다.

두 프로토콜의 스택은 다음과 같습니다.

위 스택을 이해하기 위해서는 osi 7계층을 알고 계셔야해요. 

물리 계층인 1계층인 IEEE (아이 트리플 이) 802.15.4 phy를 확인할 수 있습니다. thread나 zigbee 모두 해당 phy 기반입니다. 2계층인 802.15.4 mac도 공통 기반입니다. 이것은 다음을 의미합니다. 일단 phy와 mac은 하드웨어 레벨을 의미하며, 특정 하드웨어 칩이 802.15.4 mac과 phy를 지원한다면 하나의 chip으로 Thread, zigbee를 모두 이용할 수 있다는 것을 의미합니다. 

그 위 계층으로, thread의 경우 6LowPAN(식스로우팬)과 ip routing, udp가 있습니다. 이것은 6LoWPAN (저전력 IPv6) 기반에서 ip routing과 udp를 이용할 수 있다는 것을 의미합니다.

반면 zigbee의 경우 network와 APS인것을 확인할 수 있습니다. zigbee는 일반적으로 우리가 아는 IPv4 또는 IPv6 기반의 ip 주소 체계를 이용하지 않는다는것을 의미합니다. 따라서 전송 계층도 UDP 또는 TCP가 아닌 zigbee 프로토콜이 정의하는 APS 전송계층을 이용하는 것이지요. 그렇기에 zigbee만의 네트워크가 아닌 외부 네트워크(IPv4 기반 또는 IPv6)와 통신을 하려면 별도의 게이트웨이가 있어야 합니다. 

가장 위 계층인 애플리케이션을 보면 Thread는 그 계층까지 정의하지않는것을 확인할 수 있습니다. 반면 zigbee는 애플리케이션 계층까지 정의하고 있죠. 여기서 두 프로토콜이 정의하는 범위의 차이를 알 수 있습니다. 이에 따라 Thread 애플리케이션 개발자는 훨씬 수월하게 애플리케이션을 만들 수 있습니다. 심지어 Thread는 IP 지정이 애플리케이션 레벨에서 가능합니다. Zigbee 애플리케이션 개발자는 좀 더 신경쓸 게 많겠죠. 다만 엄격하게 정의된 애플리케이션을 만드는 것이기에, zigbee 디바이스들간의 통신에 있어서 훨씬 안정적입니다. 

1) https://www.telink-semi.com/zigbee-vs-thread-smart-home-applications/

2) https://e2e.ti.com/blogs_/b/process/posts/thread-vs-zigbee-what-s-the-difference

다음 포스팅에서는 stm32wb55 보드를 가지고 thread 프로토콜 스택에 대해 더 깊게 알아보겠습니다!

 저는 컴퓨터 재부팅을 수시로 하는 편인데요, 그럴때마다 크롬에 펼쳐놨던 창을 복구하기가 무척 난감했습니다. 그래서 알아보니 해결법이 있더군요. 

 실수로 창을 내리더라도 크롬 창 하나 새로 띄우고 ctrl + shift + t 누르면 최근 창들을 복구할 수 있습니다. 몇개까지 복구할 수 있는지는 잘 모르겠습니다. 하지만 엄청 유용한것 같습니다!