Hi-Tech PIC và CCS C

[queduong]

Bạn có thể vào đây :
www.walla.com
username : htpicc
password : queduong

Đã nói là tế nhị

[linhnc308]

Mấy cái Link của anh Falleaf hay lắm đó, hồi tôi mới học VDK cũng là nhờ vào mấy cái link đó. Cảm ơn anh Falleaf nhiều về những bài viết của anh. Các bài viết của anh em cũng đã tập hợp lại thành một file PDF, nếu anh cho phép em se pót lên diễn đàn cho mọi người.

[falleaf]

Tất cả các tài liệu cung cấp trên mạng đều là các tài liệu miễn phí, và được phép phổ biến cho tất cả mọi người. Tuy nhiên, tài liệu được post lên, phải cung cấp tên tác giả, và đường dẫn chi tiết đến bài viết gốc.

Anh cũng sưu tầm rất nhiều bài viết hay của các diễn đàn, và đưa về picvietnam, và anh cũng cung cấp đầy đủ thông tin về tác giả, cũng như nguồn của bài viết được chép về.

Điều này là một nguyên tắc bất thành văn trong các diễn đàn, và cũng là một hình thức tôn trọng bản quyền tác giả mà tất cả chúng ta nên nghiêm túc thực hiện.

Chúc vui.

[txt]

khi mô phỏng CCS trong MPLAb , làm sao mô phỏng được 1 tín hiệu tác động vào 1 chân , hoặc 1 chuỗi xung tác động , để quan sát được chương trình tiến triển như thế nào? Không dùng ICD 2

[thaithutrang]

Nếu vậy bạn nhất thiết phải dùng bộ nạp có hỗ trợ debug trực tuyến+phần mềm. ICD2 là một trong số rât ít bộ nạp có hỗ trợ thì phải.
Còn nếu hỗ trợ debug offline thì có nhiều phần mềm lắm.

[HCL]

Các phần mềm cho Pic

Lang thang mãi mới kiếm được mấy cái link,gửi tặng các Pic Member.Chúc cho box Pic thêm nhộn nhịp,thấy dạo này trầm quá.Chúc mọi người ăn tết vui vẻ
1.Hi-Tech htPicc Ver 9.50
O day nha
2.Hi-Tech dsPicc Ver 9.50
Cho DSpic
3.Pic Basic Proffesional 2.46
Pic Basic Proffesional 2.46
4.MikroBasic 2.2.0.0.
MikroBasic 2.2.0.0.
5.Micro Code Studio Plus 2.3.0.0.
Micro Code Studio Plus 2.3.0.0.
6.PicSimulator 5.61
PicSimulator 5.61
7.CCS PCWH 3.242
CCS PCWH 3.242
Down nhanh kẻo hết

[falleaf]

Cái việc lấy các trình dịch và mô phỏng hoàn toàn không khó, chỉ cần một buổi tối là có đủ. F tôi bây giờ thậm chí có Source Booster đầy đủ, nhưng mà vẫn không cung cấp lên.

Mong rằng các bạn đừng hiểu là F giấu, thực ra F cũng chẳng học hành gì cái Source Booster đó, nhưng vấn đề là tôi không muốn mình phát triển theo hướng không tập trung.

Sau khi xem xét rất nhiều các đánh giá, và thử nghiệm một số cái, tôi và bác BA quyết định tập trung phổ biến CCS C và HT PIC mà thôi. Chúng ta làm việc chung trên hai cái này, sẽ có nhiều cơ hội để cùng nhau chuẩn hóa và phát triển.

Vì sao chọn 2 thằng này? Bởi vì nó mạnh, truyền thống lâu đời. Chuyên về trình dịch. Chưa có thằng nào mạnh bằng, thường thì chỉ có hai thằng này so sánh với nhau.

CCS C thì rât gần với MPASM, biên dịch tối ưu hơn HT PIC, nhưng HT PIC là là C chuẩn, có nhiều ưu thế khác trong việc lập trình.

Hơn nữa, khi đã phổ biến và phát triển, thì nếu ở VN, chúng ta cùng sử dụng và cùng chia sẻ một cơ sở thư viện, chúng ta sẽ có một cộng đồng mạnh. Đừng ham hố quá nhiều...

Chưa kể đến việc, nếu bạn dùng CCS C hoặc HT PIC mà gặp vấn đề gì, hỏi lên diễn đàn hoặc những người bạn, khi họ cũng dùng cái đó, thì hoàn toàn chúng ta có thể nhờ cậy được. Còn nếu chúng ta đi dùng một cái lạ đời, bạn không biết, diễn đàn không biết. Gặp vấn đề gì chịu chết.

Tính kế thừa trong các sản phẩm của một công ty cũng không cao, chính vì thế, các công ty làm sản phẩm, nên chọn cho mình bộ công cụ làm việc nhất quán. Lúc này, sinh viên đi học lập trình nào sẽ có lợi?

Đó là một vài ý của F, F có rất nhiều trình dịch và công cụ, nhưng F không đưa ra cũng vì F suy nghĩ như trên... Đừng ham hố, đó là lời khuyên của F.

Chúc vui

[thaithutrang]

Giữa CCS, HTPIC đều có thế mạnh riêng:
-CCS đơn giản, thư viện nhiều, học nhanh ... và đặc trưng kiểu mã là Macro cố định.
-HTPIC thư viện ít, học khó hơn nhưng có ưu điểm: chuẩn C, hiểu được PIC hơn và đặc trưng kiểu dịch động, nên mã tối ưu về mã và tốc độ hơn.

Vậy 2 kiểu dịch này khác nhau chỗ nào? tại sao dịch động lại tối ưu hơn dịch tĩnh?
-Dịch tĩnh: mỗi một câu lệnh thì tương đương với một tập hợp lệnh asm cố định. Bởi thế khó thể tối ưu giữa các lệnh liên tiếp nhau.
-Dịch động: mỗi một câu lệnh có thể được tối ưu hơn bởi kiểu dịch thông minh: tính kế thừa, rút các lệnh thừa... giữa các lệnh liên tiếp hay chuỗi các lệnh liên tiếp.
Ví dụ chương trình có 2 lệnh:
Với CCS
-Lệnh 1//10 lệnh asm
-Lệnh 2//12 lệnh asm
-Lệnh 3//13 lệnh asm
Nên CCS hết (10+12+13) lệnh asm
Còn với HTPIC
-Lệnh 1//10 lệnh asm
-Lệnh 2//12 lệnh asm
-Lệnh 3//13 lệnh asm
Nhưng khi dịch, nó sẽ tìm ra các lệnh chung cũng như về mặt logic của 2 lệnh này. Nên kết quả luôn <=(10+12+13) lệnh. Nhất là với PIC, chỉ riêng với sự tiết kiệm chuyển bank... đã làm cho HTPIC tối ưu đi khá nhiều.
Cũng chính sự tối ưu này dẫn tới một khả năng mở của nhà sản xuất trình dịch HTPIC khó hơn so với so với CCS.
Sự đầu tư về công sức này: khiến một chương trình khi sinh mã bằng CCS thì thường lớn hơn khoảng 1.1-1.3 lần so với HTPIC. Nhất là khi viết với một chương trình lớn, các bạn sẽ thấy rõ điều này. Cũng chính vì điều này mà HTPIC bán giá gấp nhiều lần CCS.

To PTH: bạn làm như vậy thì sẽ ko có lợi cho thế mạnh HTPIC đâu. Bởi khi bạn làm các Macro cố định sẽ biến HTPIC thành CCS(thiếu sự gắn kết tối ưu giữa các lệnh liên tiêp) Vậy sao ko dùng CCS để phát triển theo hướng của bạn sẽ hay hơn. Ko hiểu là tớ diễn giải như thế, bạn có hiểu ý tớ ko?

[nad]

Mình xin có vài ý kiến được không. Thứ nhất mình cũng nói ngay mình có rất ít kiến thức về PIC cũng như các IDE làm việc với PIC mà các bạn đang thảo luận là CCS và HTPIC


đặc trưng kiểu mã là Macro cố định
Mình chưa hiểu lắm ý bạn Trang nói nhưng mình đoán ý bạn nói CCS sinh mã theo kiểu Macro - tức ví dụ khi dịch - tiền xử lí - thấy một hàm f(...) nó sẽ tìm doạn mã tương ứng và chèn vào : đúng ý nghĩa của Macro - Nhưng thực tế theo mình hiểu trình dịch sẽ không làm như thế ví dụ có đoạn mã
..
f(...)
...
f(...)
nếu như bạn sẽ sinh ra hai đoạn mã của hàm f (dúng kiểu macro) nhưng trình dịch theo mình đủ thông minh để không làm như thế
nó sẽ ghép doạn mã f ở một đâu đấy và thực hiện một lệnh call hay jump tới địa chỉ đoạn mã đó, việc truyền tham số có nhiều kiểu, thông thường theo mình thấy là push vào stack, cũng có thể là một cách khác cho nên mới gây hiện tượng phải dùng từ khóa reentrant, việc trả lại giá trị cũng được quy ước đặt ở một địa chỉ nào đó thường là một thang ghi công dụng chung


Dịch tĩnh và dịch động
He nghe hơi là lạ nhưng mình cũng không nghĩ là nó làm việc như bạn nghĩ đâu. Có thể đúng CCS thua HTPIC ở những điểm bạn nói nhưng nó thua không phải như bạn Trang nói : nó sẽ tìm ra các lệnh chung cũng như về mặt logic của 2 lệnh này. Nên kết quả luôn <=(10+12+13) lệnh. Nhất là với PIC, chỉ riêng với sự tiết kiệm chuyển bank... đã làm cho HTPIC tối ưu đi khá nhiều. hay như bạn Bằng : Còn HTPIC do có sự móc xích giữa các lệnh liền kề mà là sự tối ưu về mặt biên dịch hay sự thông minh của trình biên dịch - điều gây nên sự khác biệt giữa các trình biên dịch, nó thể hiện ở chỗ : biết lưu trữ, phân tích ngữ cảnh, cũng như phần hardware tương ứng mà cụ thể là laọi PIC được sử dụng-> tối ưu theo mã, theo tốc độ hay thời gian biên dịch

CCS rất dễ copy các thư viện lệnh bởi view asm là thấy ngay. Còn HTPIC do có sự móc xích giữa các lệnh liền kề nên khó copy hơn
Theo mình suy đoán thôi nhé thường có hai mode để làm việc là mode Debug và mode Release - mode debug thì viết thế nào view asm lên như ta viết (C) nhưng mode Release thì khác đấy . Cũng chú ý luôn các option tối ưu mà mình thấy hầu như IDE nào cũng có : tối ưu theo mã, theo tốc độ hay thời gian biên dịch,...

CCS rất dễ copy các thư viện lệnh bởi view asm là thấy ngay. Còn HTPIC do có sự móc xích giữa các lệnh liền kề nên khó copy hơn. Như vậy, bạn PTH hoàn toàn có thể "sáng chế" một CCS mới "CCS_PTH" he he.... chứ ngồi viết làn gì cho mệt
Không dễ như bác nói đâu - nói thế thì hàng loạt phần mềm bây giờ mình cứ disasm -> open source, đoanm mã mà ngắn thì còn chơi được chứ phức tạp là mệt đó, chưa kể bác phải nắm thật rõ trình biên dịch CCS

to phamthaihoa: Tui tính lười nên thấy bác có ý tưởng tạo thư viện là ủng hộ ngay để ăn sẵn nên ra sức ủng hộ cho ý tưởng của bác, mong bác sớm hoàn thiện cho bọn beginner như tui nhờ với

Mong học hỏi nhiều từ các bác

[falleaf]

http://www.ccsinfo.com/compare.shtml

[thaithutrang]

Trình dịch nào mà chẳng có những quy tắc chung như anh nói ở trên. Như các đoạn anh nói dươi đây:

nó sẽ ghép doạn mã f ở một đâu đấy và thực hiện một lệnh call hay jump tới địa chỉ đoạn mã đó, việc truyền tham số có nhiều kiểu, thông thường theo mình thấy là push vào stack, cũng có thể là một cách khác cho nên mới gây hiện tượng phải dùng từ khóa reentrant, việc trả lại giá trị cũng được quy ước đặt ở một địa chỉ nào đó thường là một thanh ghi công dụng chung

Nên trình dịch nào cũng phải tuân thủ. Nếu ko code sẽ lớn ko một cách không lồ, và các khái niêm như hàm, rồi reentrant... sẽ ko còn chút ý nghĩa gì ngoài ý nghĩa "rõ ràng, ít lệnh" nhưng nhiều code. Ý em ko nói ở chỗ này.

Với một con uC thì tư tưởng "tủn mủn" câu lệnh phù hợp kiến trúc nó lại được đặt lên rất cao. Cái thể hiện rõ ràng nhất là sự chuyển tối ưu chuyển bank này, nếu bạn nào có thời gian thì thử view lên xem sự khác biệt này, vì rằng sự chuyển bank này gặp nhiều do kiên trúc của PIC. Những ai đã từng làm CCS và muốn copy các hàm của nó thì cực dễ, chương trình chỉ cần viết mỗi lệnh cần copy đó, compiler rồi view asm lên là thấy ngay, ví dụ dùng ICprog để view asm, hoặc dùng ngay trên CCS có chế độ view asm cũng đc.

[BienVanKhat]

Không chỉ có chuyện chọn bank, nếu thường xuyên sử dụng IO, CCSc cũng luôn tự động set tris tương ứng, mất khá nhiều code, nhưng cái này không quan trọng lắm vì có thể dùng asm thay thế hoặc sử dụng fast io.

Thật ra tôi thấy nếu chỉ viết những chương trình bình thường CCSc tiện lợi hơn nhiều (yêu cầu cao hơn thì không biết) đặc biệt theo tôi là hàm printf, nếu bạn nào xài KEIL chắc thấy hàm này ngốn trên 1000byte, kinh khủng.

[thaithutrang]

Không chỉ có chuyện chọn bank, nếu thường xuyên sử dụng IO, CCSc cũng luôn tự động set tris tương ứng, mất khá nhiều code, nhưng cái này không quan trọng lắm vì có thể dùng asm thay thế hoặc sử dụng fast io.

Thật ra tôi thấy nếu chỉ viết những chương trình bình thường CCSc tiện lợi hơn nhiều (yêu cầu cao hơn thì không biết) đặc biệt theo tôi là hàm printf, nếu bạn nào xài KEIL chắc thấy hàm này ngốn trên 1000byte, kinh khủng.

Bạn nói rất đúng, nếu dùng các lệnh có sẵn của CCS, thì nếu dùng outport, nó sẽ làm lại một loạt thủ tục như điều khiển hướng, chọn bank...Trong HTPIC ko có chuyện như vậy.
Bởi vậy, nếu dùng CCS nên hạn chế dùng các lệnh có sẵn của nó trong các bài toán cần tối ưu mà và tốc độ.

[lick]

Các bạn cho mình hỏi!
Mình dùng trình biên dịch CCS để lập trình cho PIC. Nhưng hình như...nó ko hỗ trợ việc chia > 8 bit thì phải. Chương trình của mình hiện số ra LED 7 đoạn theo kiểu " quét LED" hiện trăm, chục, đơn vị. Nhưng với những số <256 thì đúng. Còn lớn hơn thì xuất ra lung tung. Và chương trình có thể bị treo.

Có phải chăng đây là hạn chế của CCS-C. Mình dùng bản hơi cũ 3.211.
Nếu muốn hiển thị số lớn hơn mình phải tự viết--> khó , hoặc bản mới hơn có hỗ trợ ko? các bạn cho ý kiến nhé!

[Acmong]

CCS là trình dịch C vì vậy nó hỗ trợ các phép toán +-*/.
Bạn xem lại kiểu các biến xem,nếu không đúng kiểu thì sẽ thu được kết quả không đúng do chỉ chứa 1 phần kết quả(thường là phần thấp)