Giới thiệu luồng

[falleaf]

Chúng tôi sẽ dần dần đưa ra hình thành và phát triển hệ thống cơ sở làm việc cho picvietnam. Một khi picvietnam được các bạn học sinh sinh viên ủng hộ, không chỉ là vấn đề kỹ thuật nữa, mà còn là vấn đề cách làm việc, , các sáng tạo, chúng ta có thể làm được nhiều điều to tát
Chúc vui.

[minhdang]

Một trong các vấn đề cần thiết để làm việc chuyên nghiệp, đó là chuẩn hóa văn bản. Nếu văn bản được chuẩn hóa tốt, thông tin sẽ được chuyển tải thông suốt, đầy đủ, đó là điều kiện quan trọng để một ê-kíp phối hợp với nhau. Việc chuẩn hóa văn bản cũng giúp lưu trữ văn bản thuận lợi cho người sau đọc.

Trong thời gian hơn 1 tháng vừa rồi, được phân công của anh falleaf, tôi đã làm việc với một số bạn sinh viên ĐHBK TPHCM để xây dựng nhóm phát triển của PICVIETNAM. Vấn đề đầu tiên falleaf yêu cầu là cả nhóm làm việc theo một hệ thống văn bản có chuẩn. Và kinh nghiệm cho thấy rằng dù đã có sẵn một chuẩn (file WORD) rất dễ theo, nhưng ít người nhanh chóng tiếp thu và làm việc theo chuẩn được.

Có thể các bạn đã đọc một bài giảng của admin falleaf, trong file .PDF, theo kiểu có định dạng khung header. Đó là chuẩn tạm thời chúng tôi dùng cho picvietnam. Việc xây dựng chuẩn văn bản như thế nào, tại sao làm như vậy, anh falleaf sẽ chia sẻ kinh nghiệm với mọi người, và cũng mong các thành viên có đóng góp trên cơ sở phê bình chuẩn văn bản này.

[bonghongthuytinh]

Em xin ủng hộ các bác và cũng mong các bác truyền đạt một ít kinh nghiệm vì xây dựng một phong cách làm việc chuyên nghiệp cũng là điều mà nhiều bạn hiện giờ đang quan tâm.
Em xin mạn phép nêu ra một câu hỏi của em, cũng nhằm phát triển tính chuyên nghiệp.

Em biết các bác đều là những bậc cao thủ trong lập trình PIC hay các VDK khác nhưng xin hỏi các bác khi các bác đụng một bài toán cần phải lập trình cho VDK, PIC chẳng hạn thì các bác sẽ tiếp cận giải bài toán đó như thế nào, em muốn đề cập đến phương pháp giải quyết bài toán đó. Theo em biết thì bên Công nghệ thông tin có những môn học về phuơng pháp lập trình như TOP DOWN design,...còn trong lập trình VDK, có thể dùng những phương pháp này không ?

Nếu có bác nào đã từng dùng những phương pháp này cho việc lập trình của mình thì có thể chỉ bảo cho em biết và đưa ra một ví dụ cụ thể được không ?
Chúc các bác vui vẻ.

[ntc]

Theo mình, để giải quyết một vấn đề nào đó sử dụng vi điều khiển, điều trước tiên là cần phải có những công cụ cơ bản. Lấy một ví dụ đơn giản, bạn muốn xây dựng một ứng dụng cho mấy con led tắt sáng liên tục, bạn cần phải biết được cách xuất dữ liệu ra một port, biết cách tạo ra thời giản delay bằng chương trình delay, như vậy có thể xem những cái mà bạn "biết cách " đó là những cộng cụ cần thiết cho ứng dụng của bạn, đó là chưa kể đến các công cụ như bạn dùng cái gì để viết chương trình, dùng cái gì để đưa chương trình vào cho con pic, hay dùng cái gì để coi thử con PIc nó có hoạt động như mình điều khiển hay không, vân vân và vân vân. Đó đều được xem là những công cụ.

Theo kinh nghiệm của riêng mình, muốn xây dựng một ứng dụng phức tạp, trước hết phải bắt đầu từ những công cụ đơn giản nhưng cần thiết cho ứng dụng đó, và khi đã xây dựng thành công các công cụ đó, công việc còn lại chỉ là ghép nối các công cụ với nhau một cách hợp lí. Theo ý mình đây cũng là cái hướng đi mà PICVIETNAM đã định ra, đó là phải hoàn thiện tất cả các công cụ dành cho vi điều khiển PIC, và từ cái nền có sẵn đó, ta có thể phát triển các ứng dụng cao hơn, phức tạp hơn và có tính thực tiễn cao hơn một cách dễ dàng.

Không biết cảm giác của các bạn như thế nào, chứ cái lần đầu tiên mình xuất được dữ liệu ra cái port của con PIC, đúng là sướng điên người, và mọi việc sau đó đều dần trở nên sáng tỏ và dễ dàng hơn rất nhiều. Có thể nói đó là do tại thời điểm đó, các công cụ cần thiết sử dụng cho con PIC của mình đã hoàn thiện phần cơ bản.

[falleaf]

Em biết các bác đều là những bậc cao thủ trong lập trình PIC hay các VDK khác nhưng xin hỏi các bác khi các bác đụng một bài toán cần phải lập trình cho VDK, PIC chẳng hạn thì các bác sẽ tiếp cận giải ?

Nếu có bác nào đã từng dùng những phương pháp này cho việc lập trình của mình thì có thể chỉ bảo cho em biết và đưa ra một ví dụ cụ thể được không ?
Chúc các bác vui vẻ.

Rất khó để trả lời câu hỏi của bạn bởi vì thực ra, mỗi người có một cách tiếp cận khác nhau trong mỗi vấn đề, và tùy quan điểm tiếp cận, mà hướng giải quyết cũng khác nhau.

Vi điều khiển - vi xử lý giống như một ngã ba đường giữa lập trình, điện tử, và điều khiển. Nếu xét riêng về bài toán lập trình cho vi điều khiển, cuối cùng, chúng ta còn lại 2 sự lựa chọn đó là tư duy theo kiểu tin học, và tư duy theo kiểu điều khiển.

ngõ ra cuối cùng là gì? Vậy những ngõ vào chúng ta cần là gì? Từ đó đi sâu hơn, đó là TOP DOWN.

Phương pháp BOTTOM UP, sẽ đi từ một thiết kế nhỏ nào đó, sau đó phát triển lớn dần ra. Với máy tính, hoặc các hệ thống lớn, có thể sử dụng BOTTOM UP. Nhưng với vi điều khiển, và picvietnam, chúng tôi mong muốn rằng cung cấp hết tất cả các công cụ cấp thấp của vi điều khiển. Bạn kể đi kể lại, thì tất cả các công cụ đó đâu có nhiều. Khi Có thể đưa một thí dụ sau:

Bài toán điều khiển PID cho động cơ DC, giao tiếp và hiển thị trên máy tính.

À, tôi phải đi lên lớp học, hẹn trả lời tiếp sau giờ học của tôi.


Chúc vui.

[falleaf]

Bây giờ viết tiếp,

Khi chúng ta gặp một bài toán như thế này, một bài toán điều khiển mà nói, chỉ cần xác định ngõ vào ngõ ra của hệ thống, sau đó phân nhỏ dần. Vậy khi thiết kế bộ điều khiển, chúng ta phải làm những gì?

Chúng ta phải lấy tín hiệu ngõ vào là encoder, sau đó làm cái gì đó không cần biết, tạo ra tín hiệu ngõ ra PWM.

Như vậy, với bài toán này, chúng ta sẽ thấy, chúng ta cần đọc encoder, sau đó đưa vào độ điều khiển, giá trị ngõ ra của bộ điều khiển sẽ là một cái gì đó mà chúng ta không biết, nhưng chúng ta biết có thể đem giá trị này vào để tạo ra PWM.

Như vậy, đến buớc này, chúng ta sẽ viết một đoạn chương trình tạo PWM với một giá trị nào đó bất kỳ. Vậy chúng ta sẽ làm đoạn chương trình nhập một biến vào, và tạo ra PWM.

Như vậy, giả sử như ở bước encoder, các bạn không biết đọc encoder như thế nào, ở bước PWM các bạn không biết làm sao tạo xung PWM. Các bạn phải giải quyết thật triệt để ngay vấn đề. Có nghĩa là bằng mọi giá phải giải quyết được nó. Khoan nghĩ đến chuyện bộ điều khiển PID phức tạp như thế nào.

Trong quá trình phân tích bài toán TOP DOWN, các bạn hoàn toàn tách thành những phần nhỏ bao gồm những phần giải quyết được và không giải quyết được.

Tất cả những phần giải quyết được phải giải quyết thật triệt để.

Vd: Phần PWM các bạn sẽ thấy thêm một vấn đề, nếu xung quá nhỏ, thì động cơ không thể chạy được. Vậy thì các bạn viết luôn phần giới hạn xung. Nếu giá trị k đưa vào PWM quá nhỏ, k<k_min thì k =k_min.

Như vậy, các bạn hoàn toàn chỉ còn lại bài toán PID. Tôi không đề cập giải bài toán PID ở đây như thế nào, nhưng giả sử các bạn đã có thuật toán PID, các bạn chỉ cần đem nguyên phần thuật toán viết vào nữa là xong.

Điều này có nghĩa là gì? Hãy suy nghĩ theo phương pháp TOP DOWN trong thiết kế, và giải quyết thật triệt để những gì mình có thể làm. Từng bước từng bước một.

Một vấn đề tôi phân tích ở đây, đó là những người đi theo xu hướng suy nghĩ TOP DOWN sẽ thường đặt câu hỏi : "Tôi cần cái gì?" "Để có cái đó, tôi phải làm cái gì?". Trong khi đó, người suy nghĩ BOTTOM UP thường nghĩ: "Tôi có cái gì?" "Tôi cần phải làm gì với cái tôi có để có thẻ đạt được cái tôi cần?".

Với các phương pháp thiết kế, khoa học cũng vậy, những người suy nghĩ BOTTOM UP thường đưa ra những giải pháp sáng tạo hơn, nhưng những người suy nghĩ TOP DOWN thường suy nghĩ có tính toàn cục hơn.

Đối với những người học vi điều khiển, tôi nghĩ rằng sử dụng phương pháp TOP DOWN trong tư duy lập trình, và giải quyết ngay vấn đề gặp phải.

Khi giải quyết một vấn đề, các bạn nên đánh số các vấn đề theo phương pháp sau:

Đánh số 1: nếu vấn đề là dễ giải quyết, nằm trong hiểu biết của bạn
Đánh số 2: nếu vấn đề là dễ giải quyết, và nếu các bạn chưa rõ về cách giải quyết, nhưng biết rằng mình có thể giải quyết được, hoặc biết rằng có một tài liệu đáng tin cậy có thể hỗ trợ các bạn...
Đánh số 3: nếu vấn đề bạn không biết, nhưng có các tài liệu tham khảo, người hướng dẫn, hoặc bạn biết hướng giải quyết của nó; hoặc những vấn đề này có thể giải quyết nhưng dài dòng, phức tạp, có thể giải quyết sau những vấn đề số 2
Đánh số 4: nếu vấn đề bạn thực sự không biết hướng giải quyết, và chưa thể giải quyết được.

Khi đi bằng phương pháp TOP DOWN này, các bạn sẽ có thể đánh dấu được toàn bộ các bước cần phải giải quyết. Sau khi đánh dấu xong, các bạn giải quyết tất cả các bài toán đánh dấu theo thứ tự từ nhỏ đến lớn, không cần đi theo thứ tự bài toán.

Điều thường hay thắc mắc của những người muốn áp dụng phương pháp TOP DOWN để giải quyết vấn đề, đó là làm thế nào để có thể vạch ra các bước giải quyết, và đi sâu đến khi phân chia nhỏ được bài toán.

Có một số yêu cầu như sau:

1) Nâng tầm hiểu biết của mình bằng cách đọc nhiều sách báo, tài liệu, phương pháp tư duy. Những hiểu biết mang tính tổng quát sẽ rất có lợi cho phương pháp suy luận này.

2) Một khi không rõ phương hướng, riêng với bài toán vi điều khiển, và lập trình vi điều khiển, các bạn hoàn toàn có thể phân chia theo phương pháp xác định đâu là các ngõ vào, đâu là các ngõ ra như tôi lấy thí dụ ở trên.

Một bài toán PID mà không biết đã có bao nhiêu sinh viên phải hỏi, nhưng thực sự lập trình PID điều khiển động cơ đâu có quá khó khăn. Lập trình thuật toán đọc encoder, lập trình điều khiển PWM, cuối cùng lấy thuật toán PID bỏ vào là xong.

Rất nhiều sinh viên cứ loay hoay với PID, nhưng nếu hiểu đơn giản, PID là một bộ điều khiển, lấy ngõ vào từ encoder, và ngõ ra là PWM, thì nếu đã có encoder rồi, có PWM rồi, khi hỏi bất kỳ ai, người ta chỉ cần đưa thuật toán PID ra là lập tức hiểu và có thể giải quyết được vấn đề.

Chúc các bạn thành công

[Khoa]

Bạn falleaf phân tích khá chi tiết rồi, mình chi xin bổ sung chút kinh nghiệm trong quá trình làm việc thực tế của mình thôi.Khi đứng trước một bài toán hay một vấn đề đặt ra yêu cầu dùng vi điều khiển để điều khiển,trước hết mình sẽ tập trung vào việc xây dựng một hệ thống các lưu đồ giải thuật thật chặt chẽ sao cho cố gắng không để sót bất cứ một sự kiện ,một biến cố nào có thể xảy ra(thường là không hết,nhưng không sao, ta có thể bổ sung sau mà), để có được một lưu đồ chặt chẽ như vậy, theo cách của mình thì mình sẽ xem mình như đang làm công việc của con vi điều khiển đó,từ đó mà mình sẽ hình dung được cụ thể mình sẽ làm những gì,những biến cố gì sẽ xảy ra và mình sẽ đáp ứng như thế nào,cái nào ưu tiên trước...tóm lại là tự đặt ra càng nhiều câu hỏi càng tốt(áp dụng nguyên tắc 5W+1H,nghĩa là what,where,when,who,why,+how) sao đó tự trả lời càng cụ thể càng tốt.Khi đã có lưu đồ giải thuật rồi, thì mình sẽ phân tích xem với giải thuật như vậy thì minh nên chọn họ vi điều khiển nào thì thích hợp(về giá cả,độ tin cậy, độ phức tạp của chương trình...).Sau khi chọn họ VDK rồi thì mình sẽ nghiên cứu kỹ để hiểu rõ cách thức hoạt động của Ic như trong lòng bàn tay, rồi thì mình tiến hành xây dựng các hàm cơ bản(cố gắng quy về hàm chuẩn càng nhiều càng tốt,làm vậy khi viết chương trình chính sẽ nhẹ hơn rất nhiều) từ lưu đồ giải thuật rồi tới chương trình chính.Công việc cuối cùng là đưa vào thực tiễn để kiểm tra độ chính xác của chương trình,tiến hành sửa chữa ,bổ sung đến khi hoàn thiện.Theo kinh nghiệm cho thấy thì khâu xây dựng giải thuật là khâu quyết định,để co được một giải thuật hay đòi hỏi phải tư duy rất nhiều mọi lúc ,mọi nơi(ngay cả khi đi toalet hay đi ngủ, xin lỗi hehe, nhưng thường những giải thuật hay thường phát sinh lúc này,ít nhất cũng là đối với mình).Đó là giải quyết bài toán về kỹ thuật thôi,thực tế là còn phải giải quyết bài toán kinh tế nữa(phức tạp hơn nhiều)nhiều khi làm xong sản phẩm mà giá mắc quá không cạnh tranh lại thì cũng coi như thua.

[minhpic]

Mình cũng xin có một đóng góp nho nhỏ, đó là cứ làm đi, sai sẽ biết ngay, chỉnh sửa dần dần, tất nhiên phải có được các tính hợp lý ban đầu.

[ncv]

Từ lúc làm việc với máy tính đến nay, tôi cảm thấy phương pháp Extreme Programming (XP), một đại diện của trường phái Agile Methods, là phù hợp với hoàn cảnh của tôi (chúng ta). Lướt qua thì phương pháp này gần giống với việc làm đến đâu sửa đến đó, nhưng nó đã được nâng lên một tầm cao đáng nể. Xin thảo luận sơ bộ về 4 chân giá trị của XP:

1. Communication (Giao tiếp)
Điều này người Việt chúng ta cực kỳ yếu. Đây chính là tinh thần tập thể. Diễn đàn này may mắn có đội ngũ quản trị "trên cả tuyệt vời". Nếu nhiều người làm được như thế thì may ra chúng ta mới "lớn" được

2. Simplicity (Tính đơn giản)
Càng làm nhiều (và bớt nói lại) mới có thể cảm thụ hết giá trị của sự giản đơn. Nhiều người thích "lấy dao mổ trâu để cắt cổ gà"

3. Feedback (Sự phản hồi)
Nhiều khi cắm đầu cắm cổ làm mãi làm mãi mà cuối cùng cũng là "người nông dân chất phác". Giá trị này sát với làm đến đâu sửa đến đó với ý thức rằng chúng ta cần nhanh chóng rút kinh nghiệm từ những bước đi trước. Tốc độ phản hồi kết quả càng sớm càng tốt để chúng ta không phải trả giá đắt

4. Courage (Sự dũng cảm)
Có can đảm, có quyết tâm thì mới có thể vượt qua nhiều khó khăn. Nhiều khi phải biết bắt đầu lại từ đầu, phải biết hy sinh lợi ích trước mắt cho lợi ích lâu dài, phải biết học hỏi từ đồng nghiệp, từ các nhân viên của mình, và nhất là phải vượt qua được nỗi sợ hãi của sự thay đổi

Tôi thấy 4 chân giá trị trên có thể áp dụng hầu hết vào mọi lĩnh vực, kể cả trong những hoạt động bình thường hàng ngày.