PER là phương thức biểu diễn dữ liệu ngắn gọn và xúc tích nhất có thể của ASN.1. Thay vì sử dụng TLV như BER, PER sử dụng Preamble (diễn cho nhiều hoặc trạng thái bị lược bỏ của một dữ liệu bên trong), giá trị kích thước(cũng có thể bị lược bỏ), giá trị (cũng có thể bị lược bỏ), hay gọi là PLV. Đơn vị biểu diễn của PER không phải Octet mà là Bit. Mỗi phần tử sẽ thuộc 1 trong 3 loại sau: ...
Khi sử dụng BER để hiện thực dữ liêu, ta thấy rằng có khá nhiều chỗ tùy ý. Tức là cùng một thông tin có nhiều cách biểu diễn khác nhau. Khi sử dụng với trường hợp chữ kí Số, phát sinh ra nhiều vấn đề. Để giải quyết những vấn đề đó, người ta thêm ràng buộc vào BER, và tạo ra CER và DER. Sự khác nhau chủ yếu giữa CER và DER là về biểu diễn trường độ dài. Length(L). Trong khi DER sử dụng một định dạng với độ dài cố định, thì CER sử dụng định dạng với độ dài không có định, ...
Tiếp tục về ASN.1. Như bài đầu tiên, ASN.1 tách biệt phần định nghĩa dữ liệu (các file định nghĩa) với phần hiện thực dữ liệu (mỗi trường được biểu diễn bằng mấy byte, mấy bit, etc) Ta sẽ tiếp tục nói về hiện thực dữ liệu. Các phương thức để hiện thực dữ liệu gồm có: BER, CER/DER, và PER. Trong đó: BER : Basic Encoding Rules CER/DER : Canonical Encoding Rules/Distinguished Encoding Rules PER : Packet Encoding Rules ...
Tiếp theo loạt bài về ASN.1, bài này sẽ “dịch” tài liệu của anh Isida So nói về cú pháp cơ bản của ASN.1. Việc đầu tiên khi ứng dụng ASN.1 hoặc thiết kế một giao thức mới là viết định nghĩa cho các kiểu dữ liệu có thể được sử dụng. ASN.1 là một ngôn ngữ vì thế, cũng giống với C, nó có các kiểu cơ bản và các cơ chế cho phép mở rộng để định nghĩa thêm các kiểu mới. ...
Mình thấy ASN.1 khá quan trọng nhất là trong thiết kế giao thức trao đổi dữ liệu giữa các thiết bị tính toán, đặc biệt là các thiết bị tài nguyên nhỏ. Google tiếng Việt thấy khá ít thông tin về ASN.1. Mình dự định sẽ tìm hiểu thêm một chút về ASN.1 và làm loại bài viết về nó. Nội dung bài này sẽ giới thiệu sơ qua về ASN.1. Bài viết tham khảo rất nhiều từ bài viết của anh Ishida So ...
Đây là một chủ đề hay, có rất nhiều resource bằng tiếng Việt khá dễ hiểu rồi. Bài này chỉ mô tả ngắn gọn một chút cùng với vài ví dụ thực nghiệm để hiểu các khái niệm về cơ bản về Data Structure Aligment. Giả sử ta có một cấu trúc sau: #include <stdint.h> typedef struct { uin8_t mem1; uin8_t mem2; uin32_t mem3; }ST_FOOL_1; typedef struct { uin8_t mem1; uin8_t mem2; uin8_t mem3; uin8_t mem4; uin8_t mem5; }ST_FOOL_2; Cấu trúc ST_FOOL_1 sẽ được miêu tả trong 6 byte? Cấu trúc ST_FOOL_2 sẽ được miêu tả trong 5 byte? Tùy theo tham số trong quá trình “Data structure alignment”, mà cấu trúc trên sẽ được chứa trong số bộ nhớ cần thiết khác nhau. ...
Trong bài số 02, ta đã nói đến những việc mà GDB có thể giúp chúng ta. Về cơ bản GDB, có thể chạy để debug mọi chương trình, tuy nhiên nếu không muốn càng debug càng rối thì ta nên sử dụng tham số -g khi biên dịch để giúp quá trình debug xác định được vị trí mỗi đoạn binary trong source ban đầu. 0. Source code Trong bài này, ta hãy cùng xem cách sử dụng thực tế sẽ như thế nào. Giả sử ta có một source Hello world như sau: ...
Khi sử dụng GDB để debug 1 chương trình thì chương trình đó gọi là target program. Khi nói về vị trí của GDB dùng để debug và target program, ta sẽ có 2 cách trường hợp sử dụng sau: GDB và target program cùng ở 1 máy : Thường sử dụng với chính các chương trình được dev, rồi build, rồi chạy trên máy đó. Đây là trường hợp chúng ta hay thấy nhất, đó là khi phát triển các app desktop. GDB và target program không cùng trên 1 máy : Tức là GDB sẽ chạy trên 1 máy để debug 1 chương trình chạy trên máy khác thông qua Serial hoặc Network. Cái này hay thấy khi phát triển ứng dụng nhúng. Xem thêm tại đây. Một số distro khi được cài đặt, đã bao gồm GDB rồi. Có thể kiểm tra bằng command dưới đây: ...
Trước khi nói về chủ đề chính là “GDB có thể làm gì”. GDB hay những phần mềm như GDB được viết ra để giải quyết vấn đề gì. 1. Phầm mềm Debugger sinh ra giải quyết cái gì? Phần mềm thực sự được tạo ra ở bước implementation, nó hiện thực những nội dung được mô tả trong thiết kế. Vì con người viết code tạo ra phần mềm, mà con người không phải lúc nào cũng luôn làm đúng như những gì họ đã nghĩ, đã ý định, đã thiết kế. Những cái đó người ta gọi là BUG. ...
Đợt này ngồi Unit Test nhiều quá, mệt!!!. Mà đã mệt, sinh ra chán để tiếp tục được thì nhất phải có gì hay ho thỉnh thoảng ngó sang tí cho đỡ chán. それはアカン！！！！ Cách đặt mục tiêu để viết, dịch khá hiệu quả đối với “siêu lười” như mình, loạt về USB Basic dù nội dung chắc nhiều lỗi những ít ra nó cũng hoàn thành. Vâng, mục tiêu lần này sẽ viết một loạt bài về cách sử dụng GDB (GNU Debugger) từ cài đặt, cách sử dụng dòng lệnh đến các IDE (Eclipse hoặc VS Studio). ...