Đố vui về PIC, các câu đố cực vui và cực hay... hehe..

[falleaf]

hihi..

Dùng timer0 không cần khởi động (quả này F đố mẹo) 2 lệnh ghi giá trị vào. Nhưng không cần khởi động vì nó đếm đến 256 thì chỉ là 256/4 us = 64us. Đạt tốc độ vài chục KHz, tốc độ này đủ tốt. Dùng mặc định, không tốn lệnh nào.

Khởi tạo ngắt timer (1 lệnh)

irs{}
Không kể đoạn khởi tạo ngắt ở đây, nếu tính thì quá cù nhầy, bởi vì luôn luôn phải có ngắt, mà ngắt chuẩn của F đưa ra đã 20 dòng rồi.

AND temp, 00000011

temp = 0; (2 lệnh) XOR & BTFSS
W = 11110000
ANDWF BYTE1, W
PORTB = W (3 lệnh)
Tổng cộng mỗi đoạn 5 lệnh

temp = 1;
W = 00001111
AND BYTE1, W
SWAPF W
PORTB = W (6 lệnh)

4 đoạn như vậy khoảng 23 dòng lệnh, thêm đoạn if(++i ==4)? Không, chỉ cần thêm 1 lệnh INCF i thôi, nó tràn hay không kệ nó, quan tâm làm gì? dùng XOR và BTFSS rồi thêm một lệnh AND nữa trước khi vào irs cho temp. Mất 2 dòng nữa, tổng cộng 25 dòng

Hết chương trình. Nếu làm với 8 chân thì cả chương trình 23 dòng lệnh , bớt được 2 lệnh SWAPF

hihi...

Nếu viết lệnh if(++i == 4) thì các bạn xem lại nó generate code như thế nào . Coi bộ trường hợp này dùng lệnh CASE có vẻ hợp lý hơn?

[qmk]

Anyway là không nên thế, anh cứ nghĩ là em làm cho mọi led bằng nhau và bằng trường hợp bad chứ.

[thaithutrang]

Ý tưởng quét động của em có lẽ khác với anh F chứ:ví dụ
Côt 1: 3 led sáng đồng thời--->P[0]=3;--->thời gian sáng là:PW[p[0]]=PW[3]=dài nhất
Cột 2: 0 led sáng đồng thời---->P[1]=0;--->thời gian sáng là:PW[p[1]]=PW[0]=ngắn nhất. Nhưng chú ý nếu mọi led đều tăt thì thêm lệnh Off:LED+timer.
Cột 3: 1 Led sáng đồng thời---->P[2]=1;--->thời gian sáng là:PW[p[2]]=PW[1]hơi ngắn
Cột 4: tắt hết LED.------------->P[3]=2;;--->thời gian sáng là:PW[p[3]]=PW[2] khá dài
Cho nên ứng với mỗi lần quét có một thời gian khác nhau.
Bảng tra PW thì phải theo công thức tính thời gian và dòng điện+ chút thực tế.
Như trường hợp trên, ví dụ cụ thể như sau:
Vậy i=0--->thời gian sáng là 3ms(do 3 led cùng sáng).
Vậy i=1--->thời gian sáng là 0.1ms(do tắt hết led)
Vậy i=2--->thời gian sáng là 1ms(1 led sáng)
Vậy i=3--->thời gian sáng là 2ms(2 led sáng)
Đảm bảo các led sáng đều nhau.
Tuy nhiên bị trường hợp(nếu ai tinh mắt sẽ biết):
Hiện tại:nếu 4 led sáng---> thì 4led đó sáng đều nhau.
Một lúc sau toàn bộ chỉ 2 led sáng(do người sử dụng muốn thay đôi chẳng hạn)---> thì 2led đó sáng đều nhau nhưng lại sáng mờ hơn lần trước(4 led).
Vậy nên hay ko?

[qmk]

Đấy là fall nghĩ thế thôi. Dùng SW kiểu này phải so sánh xem đang ở trạng thái nào nữa. Việc việc chỉ mười mấy dòng asm coi bộ khó.

[falleaf]

Bé Trang đưa ra cái ý điều chỉnh thời gian timer để cho led sáng đều. Khi đó, em sẽ quay trở lại cái bài ban đầu của em, bởi vì khi các LED 12, 13, 14 đều sáng, thì timer phải để ở 1 chu kỳ nhỏ. Mà nếu lúc đó 23, 24 không sáng, thì nó trở thành 1/3 chu kỳ nhỏ. Kết quả, để sáng đều, cuối cùng vẫn là 1/12 chu kỳ. Nếu vậy, cách quét ban đầu của em đảm bảo vấn đề sáng đều tốt nhất, code ngắn gọn và đơn giản nhất. Cho nên bài giải đầu tiên của em tốt hơn bài giải thứ hai. Em dùng biến s để điều chỉnh thời gian chắc em chưa tính lại thử rằng mẫu số chung nhỏ nhất của s sẽ là 12. Kết quả vẫn là 1/12.

AFH, giải được bài toán rất rõ ràng, có thể điều khiển và tính toán rất đơn giản. Một gợi ý của F đã đưa ra, đó là bài toán 0 thì sáng, 1 thì tắt.

Dữ liệu được lưu dạng 0ddd d0dd dd0d ddd0, lật ngược lại thành

1d*d*d* d*d*1d*.....

rõ ràng, nếu với 4 chân hoặc 8 chân thì chúng ta sẽ tối ưu được bài toán, bằng cách úp ngay một cái mask vào. Bài toán F đưa ra là 12 led, và ghi vào 2 byte, cho nên code mới có thể ngắn được như vậy.

Có một cái mẹo của F ở đây, đó là viết dữ liệu dạng:

0ddd dd0d dd0d 0ddd

nửa đầu đúng thứ tự của AFH làm, nửa sau của byte viết ngược lại. Cho nên, lúc chuyển lên, chỉ cần 1 lệnh ASM = SWAPF, thành ra khởi tạo và viết lệnh tất tần tận mới có mười mấy dòng lệnh. Chứ nếu dịch bit 2 lần thì mất 8 lệnh rồi, không làm được gì nữa cả.

Khi giải N chân, thì dịch bit phải sử dụng, không có cách nào khác hơn.

Nếu như để led sáng đều trong mọi trường hợp, thì cách của bé Trang làm lần đầu tiên là tốt nhất. Nếu để led sáng đều trong từng trường hợp riêng thì ý tưởng của cách 2 của bé Trang có thể dùng được nhưng phải kết hợp với cách của AFH. Nếu dùng một số led N biết trước thì ghi thành nhiều byte sẽ khôn ngoan hơn. Nếu dùng 4 hoặc 8 chân, thì modify cách của AFH một chút. Nếu N chưa biết giải lý thuyết thì cách của AFH làm led sáng tốt nhất (cho điện trở nhỏ, khi led sáng rồi thì hiện tượng mờ là không đáng kể nữa, vì nó chỉ có 1/4 chu kỳ, nếu giải theo cách bé Trang, với số led ít thì sáng yếu, số led nhiều càng yếu hơn nữa).

Như vậy, tất cả đều đã có những ý tưởng hay.

Xin được phép tặng 1 con 16F88 cho AFH, và cho phép bé Trang chọn một con PIC bất kỳ, nếu có anh sẽ tặng, còn nếu không có, anh sẽ gợi ý một con có chức năng tương đương để em chọn.

Gửi email cho F, ghi rõ tên người nhận, địa chỉ (sử dụng đúng email đăng ký trên diễn đàn để F biết đúng là AFH và bé Trang).

Chúc vui.

[qmk]

Hihi, nếu là vài us thì may ra tắt hết điện và tắt hết các led bên cạnh và mắt em phải cực tinh mới nhận ra được bóng mờ đấy. Em có thể thử.
Nhưng mà viết như em hay hơn tặng em 0.5 điểm đấy.

Anh cũng phản đối việc thêm linh kiện mà mất ý nghĩa của bài toán. Nhưng control thời gian động như em làm không dễ đâu em nên viết lại và đưa ra bản cuối xem có thể khả thi không.

[thaithutrang]

Nếu nối thêm trở mỗi led thì em phản đối ngay.Chẳng thà thêm 4 byte RAM (nếu ko thì thêm dòng xử lý tại chỗ)còn hơn mất nhiều trở đến vậy,vì thiết kế ít ai lại dùng đến hết RAM+Flash. Anh qmk đọc lại bài em trang trước nhé, anh bị bóng mờ của LED đó, vài us cũng thấy bóng mờ đó.Vì em làm LED7T đã mắc cái này 1 lần.Trừ anh qmk 0.5 điểm ở chỗ này vừa khuến khích vừa cho anh cẩn thận lần sau có làm thật thì tránh...

[qmk]

Vừa đọc lại Datasheet Vbe sat là -1.1V cơ đấy Bạn nhầm với Vce sat rồi = -0,3V.

To Trang: Đoạn đấy anh tính rồi nó chỉ mất vài phần us thôi. Không ai nhìn nổi đâu.

[qmk]

Vì s thay đổi theo mỗi cột quét, nên cần làm mảng lưu để tăng tốc,đỡ phải tính lấiu mỗi lần quét.
Ví dụ
P[1]=0;--->Cột 1 ko có led sáng.
P[2]=3;--->Cột 2 Có 3 led sáng.
P[i]chính là số LED sáng của cột i.Power[p[i]] là công suất sáng cột i;

Theo ý tưởng quét của AFH thì độ sáng vẫn đều nhau nhưng phải dùng thêm cổng đệm, và nối thêm trở trên mỗi led. Mà thêm cổng đệm thì chẳng có ý nghĩa gì mấy. Đây là bài toán tiết kiệm port mà. Mình vừa thử hàm << trên C++ xong có vẻ nó không phải là hàm quay mà chỉ là hàn shift thôi. AFH sửa chương tình đưa ra bản final đi.

Không ai xem phần chứng minh của mình cách đấy mấy trang nhỉ.
Nếu cho các led sáng đều thì không cần làm như em Trang chỉ cần nối thêm trở trên mỗi led.

Việc control led theo thời gian của em Trang phức tạp và tốn tương đối bộ nhớ. Em nên sửa hết lỗi và đưa ra chương trình final đi.

Fall đâu rồi đưa ra đáp án đi. Nhớ là mười mấy dòng asm thôi nhé. (Với 12 led)

[thaithutrang]

Em dùng kiểu byte chứ có bit đâu nhỉ?(em có chữa ko dùng mảng bit),

PORTB = (PORTB | 0x0F)& (mbcMask[y] | Led[x]);
TRISB = (TRISB | 0x0F)& (mbcMask[y] & mbcMask[x]);

Cái của anh qmk bị nháy chỗ này dúng ko nhỉ?
Vì

Đang là giai đoạn TRIS lần trước.
PORTB = (PORTB | 0x0F)& (mbcMask[y] | Led[x]);
Thời điểm này bị sáng kotheo ý muốn
TRISB = (TRISB | 0x0F)& (mbcMask[y] & mbcMask[x]);

Thêm 1 dòng và sửa đi một tý:

TRISB |= 0x0F
PORTB = (PORTB | 0x0F)& (mbcMask[y] | Led[x]);
TRISB& = (mbcMask[y] & mbcMask[x]);

Anh qmk làm đúng nhất,nhưng em vẫn thích dùng kiểu buff nhất, để đỡ tốn thời gian cho mỗi lần quét.Chỉ tiếc thiếu mất một phần về thay đổi độ sáng theo cột

[AFH]

Vì s thay đổi theo mỗi cột quét, nên cần làm mảng lưu để tăng tốc,đỡ phải tính lấiu mỗi lần quét.
Ví dụ
P[1]=0;--->Cột 1 ko có led sáng.
P[2]=3;--->Cột 2 Có 3 led sáng.
P[i]chính là số LED sáng của cột i.Power[p[i]] là công suất sáng cột i;

Vậy là em vẫn bám theo cái ý tưởng là dùng hàm buffer tính cho một rừng giá trị kiểu mảng BIT. ha ha........
Vậy sao kô dùng mảng kép kiểu POWER[i][j], với giá trị lần lượt là độ sáng thứ j của cột i ???? Về bộ nhớ chiếm dụng là bằng nhau mà. hơn nữa lại kô bị giới hạn về j.
Phải kô?
Em kô được giải là cái chắc rồi,

gửi bạn qmk, thực tế người ta dùng cách đó để tạo TTL đó, chọn loại Trans tốt thì chỉ sụt áp có 0,2 V thôi, vậy là chấp nhận được rồi.
AFH

[thaithutrang]

Vì s thay đổi theo mỗi cột quét, nên cần làm mảng lưu để tăng tốc,đỡ phải tính lấiu mỗi lần quét.
Ví dụ
P[1]=0;--->Cột 1 ko có led sáng.
P[2]=3;--->Cột 2 Có 3 led sáng.
P[i]chính là số LED sáng của cột i.Power[p[i]] là công suất sáng cột i;

[qmk]

Cách này dùng được nhưng bị rơi áp 0.7V trên con Transistor A1015

[thaithutrang]

Em vưa phát hiện sai là phải xuất tris nữa,chết thật. Nhưng các anh cũng phải giải bài toán "độ sáng= nhau" và ko đc lấy giống ý tưởng của e nhé)--->rất có thể ko ai đạt giải rồi đây...hi hi...

[AFH]

Vậy chữa thành:const unsigned int POWER[N]={a,b,c....}; có đúng ko anh ới? rất tiêc là protes của em bị lỗi,nếu ko mô phỏng sẽ biết những kiểu sai+1,-1 thế này.

thật ra, với cái hàm này, em cần gì phải truy suất mảng lồng mảng.
Giả sử N=4, nghĩa là cùng một lúc em chỉ có thể hiển thị tối đa là N-1 LED tương đương 3 LED, do đó, việc em dùng biến s để biểu thị có bao nhiều LED sáng là tốt, và em chỉ việc gán TIMER=POWER[s] là xong rồi. Nhớ rằng hàm buffer của em cùng lắm nó chỉ tăng s = 2 là cùng thôi. Mặc định s=0 là 1 LED sáng, s=1 là 2 LED sáng và s=2 là 3 LED sáng. Nếu kô có LED nào sáng thì các đầu vào TRISB=0xff hết, do đó kô cần quan tâm đến thời gian ở điểm này (coi như vẫn là = Timer cho 1 LED sáng)
Vậy là mảng của em sẽ là POWER[N-1]. Đúng chưa cô gái láu cá.
p/s: hôm nào em dậy anh cách mô phỏng bằng Protes nhé. Từ xưa đến nay, chưa bao giờ anh biết Debug một chưa trình trên máy tính, từ cái hồi học 89C51 tới nay. Toàn debug trong đầu với những phép toán đơn giản, còn phức tạp thì cứ nạp xuống board xem nó chạy ra làm sao.


Bạn qmk ơi, xem hình dưới đây để biết đầu ra TTL dùng transitor nhé.