Trình dịch C nào tối ưu nhất. (Anh em tư vấn gấp)

[VNarmy]

Hiện nay mình đang dùng Code Vision và Attiny2313 (bộ nhớ 2K). Tuy nhiên mới chỉ viết được vài câu lệnh mà đã tràn code (mình không dùng thư viện nào của CV ngoài tiny2313.h). Vậy không biết còn trình biên dịch nào tối ưu hơn nữa không? Mong các anh em tư vấn giúp. Thanks in advance.

[tui]

Pác hạn chế sử dụng các thư viện xuất nhập của nó như print, getch... Tốt nhất nên dùng WinAVR free, sử dụng nhiều mã nguồn mở.

[VNarmy]

Pác hạn chế sử dụng các thư viện xuất nhập của nó như print, getch... Tốt nhất nên dùng WinAVR free, sử dụng nhiều mã nguồn mở.

Nào có giám dùng cái thư viện nào của nó đâu.

[Hunget]

Có lẽ các hàm trên tính đến quá nhiều trường hợp phụ nên cần many bộ nhớ. Em dùng avrstudo thấy khi dùng một hàm vớ vẩn như hàm delay_ms trong thư viện delay mà mất tới hơn 3KB bộ nhớ. Chắc mỗi trình dịch có một điểm tối ưu riêng. Khó so sánh lắm

[smartthought]

Xin lỗi chen ngang tí
VNArmy à, chỗ cậu có con LM12 và L165 không?
ST đang cần gấp.

"lần sau post vào luồng của bác VNArmy nhé, ở chữ kí ấy"

[nghoang]

bác nào yếu thì dùng cv bác nào khỏe tài dùng winavr

[hpl2008]

mình thấy hình như cái thằng WinAVR nó gần với ASM nên chắc khó dùng ? nhưng TUT về nó khá nhiều

[sphinx]

không phải vấn đề khó dùng hay không! Đơn giản vì nó là nguồn mở, do đó số lượng người sử dụng là cực kì đông đảo, vì thế các ví dụ mẫu có rất nhiều. Cũng như có những thư viện đồ sộ (AVRlib) viết trên WinAVR chứ không phải là CodeVisionAVR

[CuongQuay]

Hiện nay mình đang dùng Code Vision và Attiny2313 (bộ nhớ 2K). Tuy nhiên mới chỉ viết được vài câu lệnh mà đã tràn code (mình không dùng thư viện nào của CV ngoài tiny2313.h). Vậy không biết còn trình biên dịch nào tối ưu hơn nữa không? Mong các anh em tư vấn giúp. Thanks in advance.

codevision AVR là trình dịch C tối ưu nhất dùng cho AVR rồi. Không tin thử xem mã ASM của nó. Viết vài dòng đầy do include các thư viện vào nhưng chỉ dùng 1,2 hàm con như thư viện <stdio.h>. Các trình dịch cho VDK khi include là nó chèn nguyên cả cái thư viện đó vào nên mới nhanh hết bộ nhớ. Chứ viết code không thì 2K viết nhòe

[nvt2]

WinAVR thì đông người xài thiệt vì nó miễn phí mà, nhưng mà nó khá phức tạp về mặt cú pháp.Còn open soure ah, thì đó, cho hết đó, nhưng mà đem về dịch ra có chạy không thì còn tùy... .Trình dịch WinAVR quá " thông minh" thành ra "bất trị", muốn trị được nó thì cũng phải bị nó làm mất ăn mất ngủ vài lần! Anh em nào quen lập trình C trên UNIX mà chơi cái này thì ngon quá, viết C mà chẵng thua gì ASM cả !

Viết C thên WinAVR thì thật ra cũng không quá phức tạp nếu bạn sữ dụng nó với các thao tác IO cơ bản, tính toán sơ sơ...chạy tốt và khá nhanh. Nếu chỉnh mức optimization lên cao nhất thì tốn code ngang ngữa CodeVison.
Chú ý đừng dùng thư viện delay của WinAVR.

Còn CodeVison thì quá tốt rồi, hỗ trợ người dùng rất nhiều, các bạn mới làm quen AVR thì nên xài cái này.

[VNarmy]

Thực ra vụ này em giải quyết được roài. Chẳng qua em ko đọc kỹ datasheet. Em phang 1 cái lệnh nhân, 1 cái lệnh chia. Riêng thằng lệnh chia nó làm của em 500 bytes. Vãi linh hồn.

[nvt2]

Thực ra vụ này em giải quyết được roài. Chẳng qua em ko đọc kỹ datasheet. Em phang 1 cái lệnh nhân, 1 cái lệnh chia. Riêng thằng lệnh chia nó làm của em 500 bytes. Vãi linh hồn.

Ngộ quá, NVT2 dồn 1 phép "+", 1 phép "*" và một phép "/" vào một dòng lệnh mà nó tốn hơn chục chục lệnh thôi ( khoảng 20 byte).

NVT2

[hpl2008]

khi sử sung các thuật toán như PID, Fuzzy thi nên sai C nao cho tiện nhỉ AE ?Mình chủ yếu dùng ASM nhưng cái phần + ,-, *,\ viết khá mệt còn mấy cái khác thì mình thấy ASM viết rất tốt.

[queduong]

bác nào yếu thì dùng cv bác nào khỏe tài dùng winavr

Không phải là yếu hay khỏe mà người ta cần biết " khỏe ' cái lúc nào

trong các chương trình tôi thấy CV rất ổn ,nó không có mã nguồn mở thì có khó khăn cho mấy người mới đầu tiếp xúc không có nhiều ví dụ ... nhưng nếu đã từng làm thì thấy nó rất hiệu quả bởi các Thư viện thiết kế khá là tối ưu .

Và khả năng dịch của nó cũng rất tối ưu đó chứ .

Những phép toán loằng ngoằng thì nên chèn ASM vào ... tôi thường làm như vậy bởi một câu lệnh C bao gồm nhiều hàm ý hơn là ASM .
Thằng viết trình dịch thực chất cũng chỉ là 1 PROGRAMMER và sinh mã không tối ưu của C là có . Đó là sự thật và nếu là người lập trình chuyên thì rõ ràng cái chỗ này phải dùng " ASM " để đảm bảo độ nghiêm ngặt về thời gian xử lý , tính toán ( Nhất là đối với bài toán có liên quan đến thời gian ).


--- Với tốc độ phát triển mạnh dung lượng bộ nhớ trong các IC lập trình hiện nay thì việc chọn phần mềm biên dịch lập trình phải nên chọn cái nào có khả năng ứng dụng thư viện , hàm có sẵn lớn .


--- Trước đây khi sử dụng PIC tôi dùng HTPIC vì khả năng sinh mã tối ưu , nhưng quả thực là nó khá đau đầu , mất thời gian nếu như phải viết một bài lập trình hoàn toàn mới .

Để lập trình ứng dụng , đảm bảo thời gian cho khách tôi quay lại với CCS ... CCS có rất nhiều thư viện sẵn có và chỉ việc lôi ra để dùng .

Những phiên bản cải tiến sau này CCS đã tỏ ra vượt HTPIC trong trình dịch MIDRANGE MCU bởi nó đã hỗ trợ nhiều thư viện có sẵn ( rất tiện ) lại có hỗ trợ kiểu bit khá là mạnh , nó có thể nhóm bit , mảng của bit...
Nếu thao tác trên những thành phần bit ( xử lý sự kiện ) - rõ ràng là hơn hẳn các trình dịch khác .


-----------
Quay trở lại trình dịch cho AVR , tôi thấy CodeVision rất tốt đó chứ , mà code vision cũng khó học chứ không phải dễ học như các trình dịch khác .

Đừng bác nào nói là dễ nhé , nó chỉ dễ khi người ta đã biết tôi ... khà khà

[phucthinhel]

Đụng cái nào chơi cái đó thui ! dụng USB dùng WINAVR vì nó có thư viện cho thằng này , enthernet cũng có luôn ! còn cái nào dùng tính toán thì dùng thằng CV cho tiện . Khách hàng đâu viết mình viết code như thế nào nó chỉ bít là nó chạy là ok rồi .
Viết ASM hay sẽ học hỏi dc nhiều điều từ nó . Nhưng chính nó cũng tạo ra một rào cản là quản lý chương trình . Khi đụng tới MMC , FAT , USB , Lan thì khả cần nhìu phép tính , quản lý vùng ram chặt chẻ ! Nên khi đó ASM lại bất lợi .
Nếu có thể thì vừa viết C nhưng nhúng thêm ASM thì thật sự quá tuyệt và chương trình nào cũng cho phép nhúng ASM vào cả .