Tutorial thứ 3.:D

http://www.picvietnam.com/download/T...TCR.050306.pdf

Đây là bài viết về kĩ thuật bảng. Sau bài này, có thể nói ta đã trang bị được những cơ sở cơ bản nhất cho việc lập trình cho vi điều khiển PIC.
Có thể tham khảo thêm một số tutorial trong diễn đàn để xây dựng một số ứng dụng cho mình dựa trên các kĩ năng đã có được.
Bài thứ 4 mình định viết về một số ứng dụng, phần quan trọng nhất là các thao tác về chức năng input của các cổng của vi điều khiển, nhưng nghĩ lại thấy không cần, bạn có thể tham khảo rồi tự thực hiện các ứng dụng cũng được. Có gì thắc mắc thì hỏi vậy. Mọi người thấy thế nào.
Nếu không có gì thay đổi, bài tới mình dự định sẽ viết về LED 7 đoạn và các thao tác hiển thị cơ bản với LED 7 đoạn dùng vi điều khiển PIC.

Cho em hỏi là làm thế nào biết được 1 chương trình bắt đầu từ address nào? VD như trong tutor của ntc thì tất cả đều bắt đầu tại 0x000. Khi em đọc datasheet của con 16F877a thì địa chỉ 0x000 là "Reset vector", chứ đâu phải là "On-chip program memmory"???
Vậy thì em phải thể bắt đầu từ address 0x000 hay là 0005h?Em không hiểu rõ phần này.

0x000 là reset vector, có nghĩa là khi được reset, bộ đếm chương trình sẽ nhảy đến địa chỉ này và bắt đầu thực hiên lệnh tại đây.

0x004 là interrupt vector, có nghĩa là khi có ngắt xảy ra, bộ đếm chương trình sẽ quay về địa chỉ này để thực hiện lệnh từ đây.

Ví dụ ta có một đoạn code như sau:
ORG 0x000
GOTO start

Có nghĩa là lệnh "GOTO start" sẽ được đưa vào bô nhớ chương trình của vi điều khiển tại địa chỉ 0x000. Khi vi điều khiển được reset, bộ đếm chương trình quay về "reset vector" tại địa chỉ 0x000, ở đó nó đọc được lệnh "GOTO start" và nhảy đến label "start".

Còn việc label start nằm ở chỗ nào thì còn tùy thuộc vào việc ta đặt cái label "start" tại vị trí nào trong chương trình, hoặc ta có thể điều khiển địa chỉ đặt nó bằng cách sử dụng lệnh "ORG ....". Ví dụ ta viết như sau:

ORG 0x050
start
; đoạn chương trình start

Thì khi đó đoạn chương trình "start" sẽ được bắt đầu tại địa chỉ 0x050 của bộ nhớ chương trình.

Như vậy bạn có thể tổ chức bộ nhớ chương trình theo như mình mong muốn.

:D

Cho toi hoi tai sao khi khai bao:
#device PIC16F877 *=16 ADC=10

thi CCSC bao loi: "Can not change device type this far into the code"
Cach khac phuc

Bác port tiếp lên đi, chờ bác lâu quá. Giống như việc 1 bữa ăn ngon nhưng cứ vừa ăn vừa nghỉ vậy. Bác cố gắng vì anh em với!!!!
Trân thành,
Nam.

Hi!

CCS C báo lỗi tại vị trí câu lệnh này,nhưng bản thân nó hoàn toàn đúng đắn,vì bạn không post toàn bộ chương trình của bạn lên nên không thể biết chỉ độc mỗi tội bạn đã cố tình thay đổi device type,nên chương trình báo lỗi.
Tớ có post 1 bài ADC đơn giản ở luồng này :
http://www.picvietnam.com/forum/show...=2113#post2113

Hy vọng nó sẽ có ích cho bạn !

Tớ cũng đang nóng lòng đọc những module tiếp theo của mod Chính !
Nhưng thông cảm,hình như Chính đang thi giữa kì thì phải !:D

Hì hì. Không phải là bận thi giữa kì. Trường mình không thi giữa kì.

Mình đang bận phát triển một hai sản phẩm trên PICVIETNAM.

Nên mấy cái Tutorial, cho nợ lại vài bữa nghe!

Nợ hoài mang tiếng quá.

:D

các bác giải thích dùm em
list p=16f873A,r=dec ; list directive to define processor ; constantes syst?e d?imal
#include <p16f873A.inc>
#include <Delay.inc>

__CONFIG _CP_OFF & _WDT_OFF & _BODEN_ON & _PWRTE_ON & _HS_OSC & _CPD_OFF & _LVP_OFF


TRONG DOẠN #INCLUDE <DELAY.INC> CÓ NGHĨA LÀ GÌ

chú nào có tài liệu đầy đủ về asm của pic thì cho anh xin

nhất là các khai báo directive,khai baó hàm module....

#include <delay.inc> là một cái file đính kèm được tạo ra bởi người sử dụng. Thông thường các file này sẽ chứa các hàm asm được viết dưới dạng các macro để thuận tiện trong quá trình viết chương trình bằng asm.

Nguyên tắc hoạt động của nó đại khái giống như mấy cái header file vậy đó. Nó sử dụng chức năng thay thế của trình biên dịch để làm tăng thêm tính linh động và thân thiện cho một chương trình asm. Khác biệt ở chỗ mấy cái header file thì dùng để định nghĩa phần cứng cho một vi điều khiển, còn các file tạo bởi người lập trình thông thường là dùng để định nghĩa các hàm.

Ví dụ, trong cái header file "p16f877a.inc" của PIC6F877A nó có một lệnh define như sau:

#define PCLATH 0x0A

Lệnh này dùng để định nghĩa địa chỉ của thanh ghi PCLATH trong bộ nhớ chương trình của vi điều khiển.

Do đó trong chương trình chính, nếu ta có một lệnh nào đó liên quan tới thanh ghi PCLATH, ví dụ lệnh:

CLRF PCLATH (lệnh 1)

Thì trình biên dịch sẽ thay thế như sau:

CLRF 0x0A (lệnh 2)

Và trình biên dịch sẽ dựa vào lệnh này để tạo thành mã máy (file hex), chứ không phải là dựa vào lệnh 1.

Trong trường hợp ta không đính kèm file <p16f877a.inc> thì nếu viết chương trình như lệnh 1, thì trình biên dịch sẽ không hiểu, vì thực chất trình biên dịch sẽ không biết PCLATH là cái quái gì (do ta chưa định nghĩa). Việc định nghĩa các tham số phần cứng này có thể thông qua các file <... .inc> được tạo sẵn hoặc định nghĩa trực tiếp trong chương trình ứng dụng.

Tương tự như các file đính kèm khác, trong trường hợp này là file <delay.inc>. Thông thường nó bao gồm việc định nghĩa một số hàm asm được viết dưới dạng các macro. Khi macro đó được gọi trong chương trình ứng dụng, nó sẽ thay thế macro đó bằng đoạn code tương ứng với macro đó trong file đính kèm.

Thực ra ta vẫn có thể viết trực tiếp đoạn code đó trên chương trình ứng dụng mà không cần phải đính kèm hay gọi cho mất thời gian.

Tuy nhiên việc xây dựng các file đính kèm như vậy mang lại nhiều tác dụng:
- Thứ nhất, nó cho phép ta tạo các hàm bằng asm, giống như các module chương trình được viết sẵn, khi cần chỉ việc gọi nó ra.
- Thứ 2, chương trình asm viết bằng cách sử dụng các chức năng thay thế của trình biên dịch giúp cho ngôn ngữ asm trở nên thân thiện hơn, giống như một dạng ngôn ngữ lập trình cấp cao hơn.

Nếu để ý kĩ, thì các ngôn ngữ lập trình cấp cao khác, ví dụ như C cũng có cách xây dựng tương tự. Các hàm xử lí thuật toán được viết trong một file riêng, các hàm hiển thị được viết trong một file riêng, ... Khi cần sử dụng một hàm nào đó trong C, ta vẫn phải đính kèm cái file đó vào chương trình ứng dụng thông qua các lệnh "#include ...". Nếu không đính kèm thì trình biên dịch sẽ báo kỗi, vì nó sẽ không hiểu được hàm ta vừa viết.

Như vậy ta có thể hiểu chức năng thay thế của trình biên dịch là một trong những cơ sở để xây dựng các ngôn ngữ lập trình cấp cao .Thực chất các ngôn ngữ cấp cao khi biên dịch sẽ có giai đoạn nó thay thế các hàm của nó bằng các hàm của ngôn ngữ ...asm, rồi dựa trên đó để tạo ra mã máy (file hex). Mã máy là cái duy nhất mà vi điều khiển thực sự hiểu được để biết được nó cần phải làm gì.

Do việc lập trình bằng mã máy đối với con người là quá khó khăn, cho nên mới có chuyên ra đời các ngôn ngữ lập trình asm, cấp cao, cao hơn nữa, ..., Như vậy con người không phải thao tác trực tiếp với mã máy, mà công việc đó được chuyên giao cho các trình biên dịch.

Nói nhiều quá!

:D

Bạn download tài liệu sau đây của Microchip nhé.
http://ww1.microchip.com/downloads/e...Doc/33014J.pdf
Và tài liệu sau nếu muốn dùng các chip PIC16:
http://ww1.microchip.com/downloads/e...Doc/33023A.pdf
Tài liệu sau dành cho các chip PIC18:
http://ww1.microchip.com/downloads/e...Doc/39500a.pdf

Thân,

cảm ơn các bác rất nhiều . các bác viết càng nhiều càng tốt vì rất rễ hiểu cho người mới học ltr pic

cảm ơn các bạn đã share các đường link!