Pic16f877a TỪ DỄ TỚi KhÓ

[ntc]

Chao ban nhh. ban co cong nhan voi toi la loi viet bai nhu cua ban ntc thi da co qua nhieu bai viet trong nuoc va nuoc ngoai roi khong? co can toi chi ra mot it khong?. ban doc lai tu dau den cuoi cai forum nay di. co bao nhieu ban cho bai moi cua ban ntc. nhu the chang qua cac bai viet truoc chang co y nghia gi nhieu voi ho ca. Con van de toi co viet bai hay khong con tuy thuoc trinh do cua toi den muc do nao nua. Toi cam thay minh chua the du nang luc de viet nhung bai co chat luong that su nen toi chua viet duoc.

Ý nghĩa của bài viết có thể không quan trọng với những thành viên đã rành về vi điều khiển PIC, nhưng mình tin rằng nó sẽ rất bổ ích cho những ai mới chập chững làm quen với nó, vì đó là những vấn đề rất cơ bản, được viết rất cơ bản, chi tiết và có trách nhiệm với cộng đồng quan tâm đến PIC.

Mình không có tham vọng biên soạn tất cả các vấn đề liên quan đến vi điều khiển PIC, và không thể viết với tốc độ nhanh để đáp ứng yêu cầu của cộng đồng, nhưng mình sẽ xây dựng nó theo tiêu chí "chậm mà chắc", từ dễ tới khó, rồi đây nó sẽ đầy đủ hơn, nhiều vấn đề hơn và có tác dụng tham khảo, ứng dụng nhiều hơn.

Tất nhiên một người không thể làm hết được tất cả, sự giới hạn về thời gian cũng như kiến thức không cho phép mình thực hiện điều đó. Mình vẫn luôn hy vọng có nhiều thành viên tham gia vào công việc này hơn, để cùng xây dựng một cái gì đó có ích cho cộng đồng, đồng thời tiết kiệm được nhiều thời gian và công sức hơn cho những thành viên muốn làm chủ công cụ PIC.

Vấn đề về năng lực có quan trọng hay không trong trường hợp này. Quan trọng là bạn muốn làm một cái gì đó thực sự có ích hay không. TÙy theo năng lực mà có được những đóng góp thích hợp. Bản thân mình cũng không thể khẳng định là có năng lực, nhưng tinh thần trách nhiệm và nỗ lực đóng góp đã thúc đẩy mình làm điều đó.

Mình tin rằng bạn hoàn toàn có thể có những bài viết có chất lượng cho diễn đàn, quan trọng là có muốn làm hay không thôi.

Đâu có cái gì hoàn toàn mới mẻ, vì mình đâu có phát minh ra con PIC, sử dụng nó không đã mệt lắm rồi. Bạn không nên dựa vào việc đã có nhiều bài viết trong nước và nước ngoài viết về các vấn đề tương tự mà đưa ra các nhận định rằng các bài viết của mình là không cần thiết như vậy. Mình tin rằng vẫn có nhiều thành viên cần đến nó, vì người mới học PIC bao giờ cũng có, và luôn hy vọng rằng những đóng góp của mình sẽ giúp ích được cho những thành viên đó.

Rất mong bạn đóng góp những tài liệu trong nước và nước ngoài đó. Chỉ nó ra để mọi người cùng tham khảo đi.

Một vài góp ý như vậy.

[ntc]

Sao không ai nói tiếp chuyện của bác F thế. Buồn Wá. Tôi đưa ra thuật toán thế này nhé. thuật toán này chỉ dùng cho mạng 485 của tôi.

Hìhì. Bác Falleaf đang đặt ra các vấn đề về giao tiếp song song mà.

Mạo muội đưa ra một giải pháp về giao tiếp nhiều PIC qua PSP như sau:

Module PSP có chân CS*, ta có thể chọn chân này làm giải pháp để giao tiếp nhiều PIC qua PSP. Các PIC sẽ được nối với nhau theo dạng BUS (nối tất cả các chân data của Slave và Master lại với nhau). Muốn giao tiếp với chip nào chỉ cần đưa chân CS* của chip đó xuống mức logic thấp (tất nhiên, bàn đầu đưa tất cả các chân CS* lên cao). Đại khái cách nối giống như nối nhiều LED 7 đoạn. Các chân RD* và WR* cũng được nối chung với nhau.

Trong trường hợp có nhiều PSP Slave, có thể dùng thêm các IC ghi dịch hoặc giải mã để tiết kiệm chân điều khiển cho PIC, ngõ ra các IC ghi dịch và giải mã sẽ được nối với các chân CS* của PIC.

PSP Master không nhất thiết phải sử dụng module PSP, mà có thể sử dụng bất cứ port 8 chân nào để làm ngõ data và một số chân để điều khiển việc chọn chip. PSP Slave nên sử dụng module PSP để việc truyền nhận dữ liệu đơn giản hơn.

Về firmware, cách đọc và ghi dữ liệu có thể dùng ngắt, và cách điều khiển cũng tương tự như giao tiếp giữa 2 PSP, các vấn đề phát sinh cần xử lí là chọn chip và xử lí thuật toán chia lấy phần dư.

Tuy nhiên cần tối ưu code xử lí ngắt để cải thiện thời gian truyền. Vì cứ mỗi lần phát sinh ngắt, phải mất một số chu kì lệnh phát sinh để vào ngắt và thoát ngắt.

[ntc]

À, quên nữa. Cái TUT của mình phân tích quá trình hoạt động của PSP dựa vào giản đồ xung. Nếu vừa đọc bài của mình, vừa nhìn vào giản đồ xung của PSP trong cái datasheet của PIC thì sẽ dễ hiểu hơn rất nhiều.

[hungnp]

bạn có khẳng định được là PSP hay hơn 485 không?. Nếu bạn khẳng định được điều này thì hãy sử dụng PSP.

[hungnp]

Tôi muốn hỏi bạn một chút về PSP:

Khả năng chống nhiễu của nó thế nào. Nếu mang sản phẩm của bạn sử dụng PSP vào trong một nhà máy công nghiệp thì nó có hoạt động ổn định không?

Khoảng cách truyền của PSP có thể tối đa là bao nhiêu mà tín hiệu vẫn có thể đảm bảo.

PSP có thể kết nối được bao nhiêu PSP slave trên cùng một mạng.



PSP dùng 8 sợi dây để truyền tín hiệu nhưng 485 chỉ cần 3 dây thôi. 2 dây tín hiệu và một dây GND

[namqn]

Nguyên văn bởi hungnp

Tôi muốn hỏi bạn một chút về PSP:

Khả năng chống nhiễu của nó thế nào. Nếu mang sản phẩm của bạn sử dụng PSP vào trong một nhà máy công nghiệp thì nó có hoạt động ổn định không?

Khoảng cách truyền của PSP có thể tối đa là bao nhiêu mà tín hiệu vẫn có thể đảm bảo.

PSP có thể kết nối được bao nhiêu PSP slave trên cùng một mạng.

PSP dùng 8 sợi dây để truyền tín hiệu nhưng 485 chỉ cần 3 dây thôi. 2 dây tín hiệu và một dây GND

Không nên so sánh kiểu này bạn ạ. Mỗi giao thức được sinh ra đều có mục đích, cũng như những ưu điểm và khuyết điểm. Bạn dùng cái mục đích của RS485 để so sánh giữa nó và PSP thì không công bằng. Bạn thử so sánh nó với PSP theo tiêu chuẩn tốc độ truyền dữ liệu ở cự ly gần xem.

Thân,

[hungnp]

Cái tôi cần nói là ở chỗ đó. Nếu bạn đã đi làm thì những ứng dụng ở cự ly gần có nhiều không?. Chúng ta nên làm những cái gì mà nó có ý nghĩa trong thực tế nhiều hơn. Làm không chỉ để học mà cũng phải có tính ứng dụng nữa.

[namqn]

Nguyên văn bởi hungnp

Cái tôi cần nói là ở chỗ đó. Nếu bạn đã đi làm thì những ứng dụng ở cự ly gần có nhiều không?. Chúng ta nên làm những cái gì mà nó có ý nghĩa trong thực tế nhiều hơn. Làm không chỉ để học mà cũng phải có tính ứng dụng nữa.

Đó là quan điểm của bạn, còn những người khác có thể có quan điểm khác bạn. Một số sinh viên của tôi cũng có quan điểm như vậy, chỉ chịu học những gì họ cho là sẽ dùng nhiều trong thực tế.

Tôi luôn luôn khuyến khích sinh viên của mình nghiên cứu dựa vào thực tế. Cám ơn bạn đã có lời khuyên như vậy.

Thân,

[falleaf]

Nguyên văn bởi hungnp

Cái tôi cần nói là ở chỗ đó. Nếu bạn đã đi làm thì những ứng dụng ở cự ly gần có nhiều không?. Chúng ta nên làm những cái gì mà nó có ý nghĩa trong thực tế nhiều hơn. Làm không chỉ để học mà cũng phải có tính ứng dụng nữa.

Điều bạn nói hoàn toàn đúng. Hiện nay, trên thế giới, người ta chủ yếu sử dụng giao tiếp nối tiếp. Theo lịch sử, ban đầu luôn xuất hiện các giao tiếp song song, vì người ta cho rằng giao tiếp song song, tại một lúc có thể truyền nhiều bit hơn giao tiếp nối tiếp. Nhưng về mặt điện, thì càng ngày người ta càng phát hiện, giao tiếp nối tiếp lợi thế hơn giao tiếp song song rất nhiều về mặt tốc độ.

Đơn cử một thí dụ, chúng ta có cổng IDE để giao tiếp với ổ cứng, nhưng hiện nay, giao tiếp SATA nối tiếp, cho phép đọc ổ cứng tốc độ cao hơn nhiều.

Do vậy, điều bạn nói hoàn toàn không sai. Nhưng một vấn đề đặt ra, nếu như bạn giao tiếp với các thiết bị đóng gói, và những sản phẩm đóng gói, có thể những sản phẩm đó sẽ là các giao tiếp nối tiếp. Nhưng nếu như bạn sản xuất thiết bị, thì bạn sẽ thấy, trong đó còn rất nhiều phần cần dùng giao tiếp song song.

Những linh kiện đơn giản như chuyển đổi ADC vẫn sử dụng giao tiếp song song, những linh kiện mã hoá, vẫn dùng giao tiếp song song. Trong một sản phẩm nhỏ vd như điều khiển động 3 động cơ bước cho ống kính thiên văn cá nhân, người ta vẫn dùng tín hiệu song song để điều khiển, vì tốc độ của nó chỉ cần 1 instruction để điều khiển động cơ bước đi 1 bước, và như vậy, trong vòng 3 instructions có thể điều khiển 3 động cơ bước, gần như tức thời. Nếu lập trình nối tiếp thì sẽ thế nào? Đây là ứng dụng thực tế, không phải là lý thuyết.

picvietnam nhận vai trò đào tạo phổ cập, cho nên những vấn đề picvietnam đưa ra, một phần là hơi mang tính academic, có nghĩa là phải mang tính chất đầy đủ, chưa chắc ứng dụng nhiều. Bạn có thể không cần, nhưng người khác sẽ cần. Đó là một vấn đề khiến picvietnam phải hao tổn sức lực khá nhiều so với việc cứ làm rồi làm. Ví dụ như bài toán của F đưa ra, há chẳng phải F không thể làm được giao tiếp nối tiếp, nhưng F đặt ra bài toán, để các bạn học sinh, sinh viên suy nghĩ giải pháp. Điều này cho thấy rằng picvietnam luôn muốn các bạn sinh viên suy nghĩ, vận dụng đầu óc của mình, với những điều kiện cố định cho trước (giao tiếp PSP, song song) để thực hiện bài toán. Khi có những kinh nghiệm suy nghĩ này, thì việc ứng dụng nó vào trong thiết kế về sau sẽ giúp người kỹ sư có một cái nhìn tổng quát hơn, và khi cần thì người ta có thể biết cách dùng.

Nếu bạn muốn thảo luận những vấn đề cao siêu, không mang tính chất học thuật mà ứng dụng nhiều, không mang tính chất đào tạo mà chỉ là trao đổi sơ qua, hoặc muốn thể hiện khả năng kỹ thuật của mình, hàng loạt sinh viên của F và bác BA sẽ có thể trả lời các vấn đề về PIC cho bạn tại www.dientuvietnam.net

Về việc bạn nhận xét về các bài viết không được mọi người theo dõi nhiều, xin thông báo là hiện nay picvietnam có phần lỗi counter, không hiểu sao bộ đếm người xem không tăng khi có người ra và vào. Bạn lưu ý điểm này và có thể thử vào xem rồi đi ra. Số lượt xem hoàn toàn không thay đổi. Do bộ phận kỹ thuật hiện nay quá bận, và đang phải ổn định www.dientuvietnam.net, đồng thời cá nhân F đang phải thiết kế bộ thư viện về Điện Tử, Điều Khiển, và Toán Ứng Dụng, nên rất hạn chế về mặt thời gian. Hơn nữa, F cũng vẫn phải đi học trên lớp, và vẫn phải thi, cho nên về mặt thời gian càng hạn chế hơn. Việc sử chữa này F sẽ cố gắng thực hiện sớm nhất có thể.

Mặc dù vậy, mỗi ngày F vẫn theo dõi không thiếu một bài trên picvietnam, và những bài có tính chất quan trọng, định hướng, và lý luận như của bạn, F sẽ phải dành thời gian để trả lời.

Có lẽ vì anh Nam trả lời bạn một cách khúc chiết, và quá ngắn gọn, cho nên làm cho bạn có cảm giác về câu trả lời chưa được thỏa mãn. Mong rằng bạn hiểu được ý đồ của picvietnam, muốn đem pic đến cho mọi người.

Chúng ta mỗi người, mỗi ngày làm một việc cho pic, F mong muốn rằng cái điều F nói "Học PIC trong 1 ngày" sẽ sớm thành sự thật. Đừng bảo việc gì khó thì không làm được, đó là tôn chỉ của picvietnam.

Chúng tôi rất mong những người đã có kinh nghiệm làm việc như bạn cùng tham gia xây dựng và phát triển về pic, robotics và các bài học cho picvietnam. Sức một vài người không làm được gì cả, nhưng sức của cả một cộng đồng thì không có gì không làm được. "Học pic trong 1 ngày" không phải là điều mà F cố đạt được, mà đây là tinh thần kêu gọi, chúng ta sẽ làm được.

Mong những đóng góp của bạn cho picvietnam nói riêng, và cho cộng đồng điện tử nói chung.

Chúc vui.

[ntc]

Tôi muốn hỏi bạn một chút về PSP:

Khả năng chống nhiễu của nó thế nào. Nếu mang sản phẩm của bạn sử dụng PSP vào trong một nhà máy công nghiệp thì nó có hoạt động ổn định không?

Khoảng cách truyền của PSP có thể tối đa là bao nhiêu mà tín hiệu vẫn có thể đảm bảo.

PSP có thể kết nối được bao nhiêu PSP slave trên cùng một mạng.



PSP dùng 8 sợi dây để truyền tín hiệu nhưng 485 chỉ cần 3 dây thôi. 2 dây tín hiệu và một dây GND

Chính xác là cần từ 9 đến 11 sợi dây, chứ không phải chỉ cần 8 dây.

Các vấn đề này mình đã có đề cập đến trong phần kết luận của bài viết TUT04. Bạn đọc xem như thế nào, rồi cho mình biết ý kiến nhá.



Hì, đã nhấn mạnh là bài viết này mang tính academic nhiều hơn mà, nhưng ứng dụng của nó trong thực tế thì phải có trường hợp hữu dụng cho nó, giống như sự hữu dụng của RS485 trong môi trường công nghiệp vậy.

Tùy thực tế mà mình quyết định dử dụng cái nào chứ bạn. Không để đem PSP vào các mạng công nghiệp, cũng như không nên đem RS485 vào ứng dụng trong các mạng cần khoảng cách ngắn và đơn giản, hì, nói nôm na là giết ruồi mà xài dao mổ bò.

[giao_su_can]

sao các bác ko có cái tut bằng C nhỉ ngôn ngữ C rất hay mà

[falleaf]

Không, picvietnam hướng dẫn về căn bản, để mọi người hiểu bản chất của PIC, nên chủ trương sử dụng MPASM để mọi người hiểu rõ bản chất của nó. Việc sau này dùng C hoặc B, đó là chuyện rất đơn giản.

Chúc vui

[ncv]

Nguyên văn bởi falleaf

Không, picvietnam hướng dẫn về căn bản, để mọi người hiểu bản chất của PIC, nên chủ trương sử dụng MPASM để mọi người hiểu rõ bản chất của nó. Việc sau này dùng C hoặc B, đó là chuyện rất đơn giản.

Chúc vui

Tôi nghĩ không nên tự bó buộc chúng ta khi chỉ quyết định dùng MPASM. Hãy thử tưởng tượng việc phát triển lĩnh vực vi điều khiển tại VN. Ta cần bao nhiêu chuyên viên / chuyên gia làm việc trong từng phạm vi nào? Tôi chưa tìm ra câu trả lời toàn diện cho câu hỏi này, nhưng tôi không nghĩ là tất cả mọi người cần học căn bản thông qua assembly. Thậm chí tỉ lệ người dùng assembly là rất nhỏ, mặc dù họ đóng một vai trò vô cùng quan trọng. Có phải "căn bản" là dành cho tất cả mọi người không?

[falleaf]

Nhận định này của bạn rất hợp lý, chúng ta sẽ nhanh chóng đi đến việc phổ biến và nghiên cứu C, đó là cách cần thiết để tiếp cận với các dự án thực hành.

Do vậy, các thành viên vẫn thường xuyên viết các bài viết về C và trao đổi về C, ban điều hành của diễn đàn thì chú trọng vào phần MPASM. Thực tế, nếu ban điều hành không làm hoạt động nghiên cứu theo nghĩa hơi chuyên gia một chút, thì rất khó để có thể phát triển hoạt động và hỗ trợ, cũng như có cách nhìn về lâu về dài.

Chúng tôi vẫn luôn ủng hộ các hoạt động trao đổi về các ngôn ngữ cấp cao, bằng chứng là chúng tôi hỗ trợ rất nhiều công cụ trình dịch, cũng như có box dành cho ngồn ngữ cấp cao. Tuy nhiên, thử nghĩ đến việc, cả ban điều hành cũng không làm việc với MPASM nữa, thì gần như hoạt động của các ngôn ngữ cấp cao sẽ phát triển rất nhanh, mà đôi lúc không thể có những bài hướng dẫn một cách bản chất cho các bạn được.

Vd: Nguyễn Trung Chính phụ trách thực hành và báo cáo vừa qua về bootloader, PIC877A, và giao tiếp PSP, chúng ta không thể nói dùng dòng lệnh C này, dòng lệnh C kia để làm... Như anh Nam, hướng dẫn về dsPIC, thực sự mà nói, làm việc với dsPIC thì làm với C sẽ có nhiều lợi thế hơn, nhưng để các bạn hiểu, thì cách thể hiện bằng ASM30 là tốt nhất.

Chúng tôi hoàn toàn ủng hộ các hoạt động của các thành viên và những người viết tut bằng ngôn ngữ cấp cao, còn nhiệm vụ của chúng tôi thì lại là nghiên cứu PIC... Nhưng F khẳng định một điều, khi các bạn hiểu ASM, sẽ rất tốt cho các bạn khi sử dụng ngôn ngữ cấp cao để làm việc

Chúc vui

[MHz]

Nhưng F khẳng định một điều, khi các bạn hiểu ASM, sẽ rất tốt cho các bạn khi sử dụng ngôn ngữ cấp cao để làm việc

... rất đúng, khi các bạn hiểu về ASM các bạn sẽ thấy tự tin hơn khi làm việc với PIC, vì khi đó bạn đã hỉu rất rõ về cấu trúc phần cứng của PIC... và việc chuyển qua ngôn ngữ bậc cao chỉ là chuyện nhỏ...