LQFP64ピンからQFN48ピンになると体積では1/10くらいになるので実装面積低減とマイコンの軽量化ができる(LQFP64ピンは意外と0.4 gもあって無視できないのです…)．
I/O数がぎりぎり足りていることは既に確認済み．今日は動作テスト．変換基板にチップと，ブレッドボードに拡張するためのピンソケットをつけた．
同じF4シリーズのプロセッサなのでライブラリなど大きな変更はなく，メモリ容量が減っていること，存在しないポートやペリフェラルの設定をしないこと，デバイスIDが違うことに注意すると問題なく書き込みができ，hello worldが出力された．(ただし，一部大先輩の協力が必要だった)
来年のマウスはこれ以外回路面で大きな変更はないが，やはりきちんとテストしないとミスの原因になるのでちゃんと確認することにしている．これから周辺デバイス(モータドライバ，ジャイロ等)の駆動もテスト予定．
以上，今年のマウス活動納め．
VQN48 STM32F411 won't save that much space on PCB as your expected especially on a high density PCB because you won't be able to utilize the area under the IC to make via to in order to lead the connect away from the chip since it is occupied with thermo pad by default. I had thought of using 411 earlier 2015 for a half size design however figured it out it wasn't that much better than LQFP64 STM32F405.
返信削除I made All in on dev board over summer for both 405 and 411(same PCB with slightly different hardware configuration with USB 2.0 hub, FTDI, J-link, mpu6500, buzzer integrated). The configurations are exactly same, all I need to do is to change the clock from 184MHz ti 100MHz.
I still perfer to use stm32F405 with LQFP64 package because I believe after all half size micromouse has 4 times of workload than classic size mouse when processing its algorithm. You are definitely more experienced for half size mouse than me, what do you think?
VFN48 instead of VQN48, that was a typo.
削除Last year I used STMF405RGT6 with 42 MHz clock. In the 32x32 maze pattern of the last all Japan contest(http://www.ntf.or.jp/mouse/micromouse2015/MM2015MMHE.png) it took 5 msec to decide the next direction in the search run and 250 msec to calculate the best route for the second run.
返信削除These are fast enough to me, so even 42 MHz clock is OK to my software.
The 42 MHz clock is also low enough to avoid using a thermo pad. When I use STM32F411 without soldering thermo pad, there are not so large temperature change. I will inslate the thermo pad by taping.
Is the 5ms the average time or the worst case for the entire maze? Assume you make the turning radius for searching run at 40mm and the mouse run at 0.5m/s on straight. This will give you 10ms time since the buffer straight distance before turn is 5mm. Sounds pretty safe if there is no slippage at all.
返信削除Since STM32F4 scale down the clock to 1MHZ then PLL to whatever number you want, why do you still stick on the frequency with multiply at 21?
21MHZ on SPI is a little bit uncomfortable for MPU-6500 (although I made it work all the time when my SPI is at 21MHz scaled down from 168MHz system clock)
My LQFP64 STM32F411 Dev board is warm when at full load(by enabling some peripherals and looping code in main routing, 100MHz when some theomo polygon under the MCU)
I am looking forward to hear any good news from you for the thermo performance for VQN48 STM32F411 without a thermo pad.
5 ms and 250 ms is the worst case. I measured the time after giving all maze data. My mouse runs 0.35 m/s with 35 mm radius, so 5 ms delay is short enough.
返信削除42 MHz, the frequency with multiply at 21, does not have so important meaning. It is got only by 168/4.
I use SPI with the 42/64 ≒ 0.65 MHz clock. It took about 200 ms to finish one cycle sending the AD value of 3 axis acceleration and 3 axis angular velocity. It means that the sampling rate is 5 kHz, if the communication is repeated with no delay. It is a little faster than the accelerometer's sampling rate(4 kHz), and slower than that of gyroscope(8 kHz).
I think 5 kHz sampling is somehow reasonable. By using 42/64 ≒ 0.65 MHz clock, it is achieved easily. I only repeat the communication without any delay technique.
Of cource faster communication, for example 21 MHz, can be used. But I want to save energy consumption and RAM.
削除if you stick on 50-70mah 1 cell battery, then this becomes necessary. I read gyro and accelerometer every 1ms and having them sampling at max rate(8K and 1K). The SPI running at 21MHz takes about 10us to read all 6 axles data, just for your reference, without using DMA.
返信削除No wonder your mouse still had enough power to make faster speed run after a long search.