Comments for Pilot's Logbook http://blog.flyingpic24.com Programming 16 and 32-bit microcontrollers in C. Wed, 10 Mar 2010 18:47:03 +0000 http://wordpress.org/?v=2.2.1 Comment on Animation on the MikroE PIC32MX4 Multimedia Board by pilot http://blog.flyingpic24.com/2010/01/27/animation-on-the-mikroe-pic32mx4-multimedia-board/#comment-309 pilot Mon, 01 Mar 2010 15:35:31 +0000 http://blog.flyingpic24.com/2010/01/27/animation-on-the-mikroe-pic32mx4-multimedia-board/#comment-309 I am going to post the code and explain it a bit on this same blog ... Just don't hold your breath... I am ... slow! I am going to post the code and explain it a bit on this same blog …
Just don’t hold your breath… I am … slow!

]]> Comment on Animation on the MikroE PIC32MX4 Multimedia Board by Toley http://blog.flyingpic24.com/2010/01/27/animation-on-the-mikroe-pic32mx4-multimedia-board/#comment-294 Toley Fri, 12 Feb 2010 02:16:28 +0000 http://blog.flyingpic24.com/2010/01/27/animation-on-the-mikroe-pic32mx4-multimedia-board/#comment-294 Me too I have a PIC32MX4 board and also wish to look at your code. Do you use the Microchip Graphic library or you wrote your own? Me too I have a PIC32MX4 board and also wish to look at your code. Do you use the Microchip Graphic library or you wrote your own?

]]> Comment on Animation on the MikroE PIC32MX4 Multimedia Board by sbeckman http://blog.flyingpic24.com/2010/01/27/animation-on-the-mikroe-pic32mx4-multimedia-board/#comment-292 sbeckman Sun, 31 Jan 2010 21:44:52 +0000 http://blog.flyingpic24.com/2010/01/27/animation-on-the-mikroe-pic32mx4-multimedia-board/#comment-292 Very Nice! I received one of these PIC32MX4 Multimedia boards a couple weeks ago. Would love to see your code for creating these graphics. Very Nice! I received one of these PIC32MX4 Multimedia boards a couple weeks ago. Would love to see your code for creating these graphics.

]]> Comment on Good old printf() (continued) by c.pergiel http://blog.flyingpic24.com/2009/09/30/good-old-printf-continued/#comment-291 c.pergiel Wed, 30 Dec 2009 16:13:29 +0000 http://blog.flyingpic24.com/2009/09/30/good-old-printf-continued/#comment-291 I am glad I stopped by. I just started a new project: porting some code I wrote a few years ago for an AVR Atmega processor to a new PIC32. Having printf available should make my job much easier. I am glad I stopped by. I just started a new project: porting some code I wrote a few years ago for an AVR Atmega processor to a new PIC32. Having printf available should make my job much easier.

]]> Comment on Olimex PIC-P32MX board by SevenLegion http://blog.flyingpic24.com/2009/07/15/olimex-pic-p32mx-board/#comment-288 SevenLegion Sun, 06 Dec 2009 09:57:14 +0000 http://blog.flyingpic24.com/2009/07/15/olimex-pic-p32mx-board/#comment-288 I have this board and it's good. The design is simpler than Microchip starter Kit, but you can make your own projects at the cheapest cost and without "expansion" boards. The quality of the proto-area is very good and it's a real pleasure to solder components on it, many times without the risk of damage. The worst problem is debuggin: Microchip's MPLAB doesnt support directly PicKit2 and ICD. Also the JTAG connector is another great promise betrayed from Microchip, till now. Now there is the new PICKIT3 wich should enable the debugging on ICD port... I have this board and it’s good.
The design is simpler than Microchip starter Kit, but you can make your own projects at the cheapest cost and without “expansion” boards.

The quality of the proto-area is very good and it’s a real pleasure to solder components on it, many times without the risk of damage.

The worst problem is debuggin: Microchip’s MPLAB doesnt support directly PicKit2 and ICD. Also the JTAG connector is another great promise betrayed from Microchip, till now.

Now there is the new PICKIT3 wich should enable the debugging on ICD port…

]]> Comment on MikroE MX4 Multimedia Board by SevenLegion http://blog.flyingpic24.com/2009/11/18/mikroe-mx4-multimedia-board/#comment-287 SevenLegion Sun, 22 Nov 2009 11:40:09 +0000 http://blog.flyingpic24.com/2009/11/18/mikroe-mx4-multimedia-board/#comment-287 very interesting... After a very slow starting in the PIC32 area, now MikroElektronika seems to be more interested in the 32 bit family from Microchip. The hope is to see a version of their compilers coming out soon. Expecially the BASIC compiler would be a good point to attract more hobbists on PIC32 than now... very interesting…
After a very slow starting in the PIC32 area, now MikroElektronika seems to be more interested in the 32 bit family from Microchip.
The hope is to see a version of their compilers coming out soon.
Expecially the BASIC compiler would be a good point to attract more hobbists on PIC32 than now…

]]> Comment on Changing habits… and dreaming a bit by SevenLegion http://blog.flyingpic24.com/2009/08/26/changing-habits-and-dreaming-a-bit/#comment-286 SevenLegion Mon, 16 Nov 2009 15:42:18 +0000 http://blog.flyingpic24.com/2009/08/26/changing-habits-and-dreaming-a-bit/#comment-286 Same feelings for me, too! I hope to live enought to see the end of 1) TV and 2) Microsoft invasive power... :) Same feelings for me, too!
I hope to live enought to see the end of 1) TV and 2) Microsoft invasive power… :)

]]> Comment on Good old printf() (continued) by pcwood21 http://blog.flyingpic24.com/2009/09/30/good-old-printf-continued/#comment-284 pcwood21 Tue, 20 Oct 2009 07:05:54 +0000 http://blog.flyingpic24.com/2009/09/30/good-old-printf-continued/#comment-284 If you define and configure a baud rate for UART1 in your code, the printf and UART output are run with delay, as it should to properly simulate. The printf command will take the proper cycles to operate. This can mess with stimulus inputs to the UART. I had a printf statement in a receive ISR when I encountered this. I scratched my head for some time until I figured it out by placing breakpoints and watching it work fine without the printf. It wasn't exiting the ISR before the next input byte arrived, and it dropped the rest of the data. If you define and configure a baud rate for UART1 in your code, the printf and UART output are run with delay, as it should to properly simulate. The printf command will take the proper cycles to operate. This can mess with stimulus inputs to the UART. I had a printf statement in a receive ISR when I encountered this. I scratched my head for some time until I figured it out by placing breakpoints and watching it work fine without the printf. It wasn’t exiting the ISR before the next input byte arrived, and it dropped the rest of the data.

]]> Comment on Searching for a Pin in a Haystack by SevenLegion http://blog.flyingpic24.com/2009/04/24/searching-for-a-pin-in-a-haystack/#comment-242 SevenLegion Sat, 25 Apr 2009 19:01:47 +0000 http://blog.flyingpic24.com/2009/04/24/searching-for-a-pin-in-a-haystack/#comment-242 Useful for sure! So useful I was already doing the same job by myself... but you come first, saving me some extra work, tanks! ;) see you! Useful for sure!
So useful I was already doing the same job by myself… but you come first, saving me some extra work, tanks! ;)
see you!

]]> Comment on Testing the PIC32 I/O Speed by pilot http://blog.flyingpic24.com/2009/03/18/testing-the-pic32-io-speed/#comment-239 pilot Sun, 29 Mar 2009 19:55:47 +0000 http://blog.flyingpic24.com/2009/03/18/testing-the-pic32-io-speed/#comment-239 Trying to count and optimize the asm code down the single clock cycle detail gets very complicated very quickly... but let's say that you are on the right track... In fact the branch slot makes use of one clock cycle, while the pre-fetch mechanism attempts to get the (jump target) instruction. If this is within the last 256 bytes fetched (most likely) the cache will hit and there will be no stalling whatsoever... As per MPLAB SIM, there is a very crude attempt at estimating the actual number of cycles, cache included, but the ultimate test of truth is running the code on the REAL ICE and looking at the stopwatch. Trying to count and optimize the asm code down the single clock cycle detail gets very complicated very quickly… but let’s say that you are on the right track… In fact the branch slot makes use of one clock cycle, while the pre-fetch mechanism attempts to get the (jump target) instruction. If this is within the last 256 bytes fetched (most likely) the cache will hit and there will be no stalling whatsoever…
As per MPLAB SIM, there is a very crude attempt at estimating the actual number of cycles, cache included, but the ultimate test of truth is running the code on the REAL ICE and looking at the stopwatch.

]]>