Picproje Elektronik Sitesi

Eğer bobin saturasyona yakın değilse çok fazla etkisi olmaz diyen var. Devrenin saçma sapan davranacağını söyleyenlerde var.
Ama hiçbir etkisi olmaz diyen yok. Zaten hiç etkisinin olmayacağını  iddia etmek zaten saçma olurdu zira ortamda manyetik alandan etkilenen bir komponent var.
Neodyum mıknatısn manyetik gücünün nisbeten işi görmeye yeten en düşük derecede (Grade) olanını seçmek ve mümkün olan en uzağa mıktatısı koymak etkisini oldukça azaltacaktır.

Gelen verileri ekranda istenilen sekilde gostermenin bircok yolu var. Yeni basladigin icin soyluyorum C bu verileri gorsellestirmenin en zor ve gereksiz yolu. Gereksiz deme sebebim harcadigin efor ve aldigin sonuc arasindaki iliskiden dolayi. Genel olarak C ile nasil GUI uygulamalari yaparim diyorsan Windows icin Win32API ye bakabilirsin, Linux icin GTK ya bakabilirsin. Fakat daha gelismis UI uygulamalari icin QT en temel ve rahat cozumdur.

Tum bunlarin disinda, bence UI merakin varsa javascript dunyasina adim atman cok cok daha dogru bir hareket olur. C/C++ ve benzeri low-level dillerle anca kendini tatmin eden uygulamalar yapabilirsin fakat JS ile cok hizli bir sekilde, sinirsiz kaynak ile hemen herseyi yaparsin. Gunumuzde artik desktop uygulamasi gelistirme isini JS temelli frameworkler ile cozuyorlar.

ElectronJS + ReactJS + ExpressJS(NodeJS) ile yapamayacagin uygulama(desktop) yok.

Tam emin olmamak la birlikte Mıknatısın ürettiği manyetik akı, bobin içerisinden akan manyetik akıyı etkileyeceği için, Bobinin endüktansı değişecektir diye düşünüyorum.

Ticari birşey yapmıyorsan: LabView Community Edition ile low level kod yazmadan yapabilirsin

Ben yeni versiyonunda ters polarite koruması var diye biliyordum.Yokmuş
Schottky Diodla  korumada çok daha az gerilim düşer.

Aşağıdaki  videoda  MOSFET +Transistörlü bir devre ile korumayı  gösteriyor.(Şema  9.dakikadan sonra izah ediliyor.)

 Ekleme:
Aşağıdaki TP5100 Modul de Ters Pil Bağlama koruması Varmış (Reverse Battery Protection ) Fiyatı 4056 dan fazla
4056 ya göre  daha fazla özelliği var Örneğin 2 pili şarz edebiliyor. (2 Amperle)
https://www.robolinkmarket.com/tp5100-1s-2s-lityum-batarya-sarj-modulu

Modulün Datasheeti
(2.sayfa da koruma geçiyor)

Resimdeki tür indüktörlerin çalıştığı bir devrenin 5mm yakınına bir sebebten dolayı 5mm çaplı neodymium mıknatıs koymak zorunda kaldım.
Bu durumun indüktörlere ve dolayısıyla devreye etkisi ne olur?

tp4056 devresine cep telefonu şarj cihazı bağlayarak lion 4.2 volt bir bataryayı şarj etmek istiyorum. Fakat bataryanin ters bağlanabilme olasılığı var.
Bu durumda artı hattına bir diyot koyup ters bağlantı koruması yapmayı düşündüm. Fakat diyot ile çıkışta 0.7 volt gibi bir gerilim düşümü olacak. Bunun şarja etkisi ne olur. Başka bir öneriniz var mı?

Alıntı yapılan: Tagli - Dün, 20:51:16Aynı fikirdeyim. RTOS kullanmanın artıları ve eksileri var. Ama genel görüşüm preemption şart değilse - ki genelde şart olmuyor - RTOS'a pek de gerek kalmadığı yönünde. State machine'ler bir event dağıtım mekanizması ile birleştiğinde çok güçlü oluyorlar. Artık tüm uygulamalarımı bu yapıyla tasarlıyorum.

Duraksamalar bazen yazılım akışında gerekli olabiliyor. Burada önemli olan, bu tür bir duraksama sırasında işlemcinin başka işler de yapabiliyor olmasıdır. Duraklama da state machine içinde bir durumdur aslında. Süresi dolan bir timer, kesme mekanizmasını kullanarak, bekleme durumundaki bir bileşene bir event atar ve bekleme durumu sona erer, sonrasında sırada ne varsa o yapılır. Ana mantık bu.

Zaman içinde projelerimin alt yapısında kullanmak üzere bir çeşit framework oluşturdum ve bunu da C++ ile yazdım. Haliyle, çok zorlayıcı bir neden olmadığı sürece C++ derleyicisi olmayan bir işlemciye geri dönmek istemiyorum. Zamanında ben de elektroniğe ve gömülü yazılıma PIC16F84A ile başlamıştım ve sanırım 2017 yılına kadar da sadece PIC (8 ve 16 bit) kullandım. Ama günümüzde PIC'ler ile aynı fiyata, hatta çok daha ucuza çok daha yetenekli Cortex M0 işlemciler bulunabilirken PIC kullanmak için bir sebep kalmadı benim bakış açıma göre.

dsPIC'ler için görüşünüz nedir?

Alıntı yapılan: Mucit23 - Dün, 18:34:54RTOS olmasa da öğrenmeniz gereken en temel şey State Machine Yapısı

Aynı fikirdeyim. RTOS kullanmanın artıları ve eksileri var. Ama genel görüşüm preemption şart değilse - ki genelde şart olmuyor - RTOS'a pek de gerek kalmadığı yönünde. State machine'ler bir event dağıtım mekanizması ile birleştiğinde çok güçlü oluyorlar. Artık tüm uygulamalarımı bu yapıyla tasarlıyorum.

Duraksamalar bazen yazılım akışında gerekli olabiliyor. Burada önemli olan, bu tür bir duraksama sırasında işlemcinin başka işler de yapabiliyor olmasıdır. Duraklama da state machine içinde bir durumdur aslında. Süresi dolan bir timer, kesme mekanizmasını kullanarak, bekleme durumundaki bir bileşene bir event atar ve bekleme durumu sona erer, sonrasında sırada ne varsa o yapılır. Ana mantık bu.

Zaman içinde projelerimin alt yapısında kullanmak üzere bir çeşit framework oluşturdum ve bunu da C++ ile yazdım. Haliyle, çok zorlayıcı bir neden olmadığı sürece C++ derleyicisi olmayan bir işlemciye geri dönmek istemiyorum. Zamanında ben de elektroniğe ve gömülü yazılıma PIC16F84A ile başlamıştım ve sanırım 2017 yılına kadar da sadece PIC (8 ve 16 bit) kullandım. Ama günümüzde PIC'ler ile aynı fiyata, hatta çok daha ucuza çok daha yetenekli Cortex M0 işlemciler bulunabilirken PIC kullanmak için bir sebep kalmadı benim bakış açıma göre.

RTOS olmasa da öğrenmeniz gereken en temel şey State Machine Yapısı.

En basitinden bir Timer kurup Timer Eventi ile main içerisinde durum değişkenleri ile işlem yapabilmelisiniz. Bu sayede program delaylara takılmaksızın yazdığınız döngüdeki işlemleri yerine getirir.