Created Fri, 27 May 2011 14:29:10 +0000 by CopperPhil
Fri, 27 May 2011 14:29:10 +0000
Hi,
I'm trying to use my brand new chipKIT Uno with different shields, but I get some issues trying to use the related libraries in the mpide...
I'm trying to replace all the #include pointing to avr/[something] (I found that removing references to avr/io.h and avr/pgmspace.h, and including systematically WProgram.h makes things going better), but now I have trouble because of direct usage of registers... i.e. the library I'm trying to use is manipulating DDRD.
Most of shields libraries are using direct reference to avr code and direct access to registers instead of using high level functions...
So finally, is there a regular way to update library code in order to make it working with the Pic32?
Many thanks,
Phil
Fri, 27 May 2011 18:56:46 +0000
Phil:
Looks like you and I are at about the same point. I posted in the IDE forum: http://www.chipkit.org/forum/viewtopic.php?f=6&t=32
Looking for some PIC analoges to the Atmel so I can compile some existing code.
Lemme know if you find anything and I will advise you likewise.
Cheers, Mike.
Mon, 30 May 2011 10:01:41 +0000
same boat
Mon, 06 Jun 2011 22:11:58 +0000
That must be what I'm seeing.
I need an update to MsTimer2.
Also, it seems the the ChipKit IDE wants the libraries directory to be in the project directory (Arduino), not under the compiler directory ...mpide-0022-chipkit-win-20110521 like the UNO wants ...arduino-0022.
Any thoughts?
Mon, 06 Jun 2011 22:39:02 +0000
Correct, any library that directly access the hardware has to be re-written
From now on, any file that references hardware should do things like this
#if defined(AVR) #include <avr/pgmspace.h> #endif
and if its only written for AVR
#if !defined(AVR) #error This code only works on the AVR platform #endif
Tue, 07 Jun 2011 20:04:20 +0000
Yes, those are good conventions, and will lead to the LIB being more useful.
What are the #DEF for the UNO chipKIT? Are there perhaps examples already in the furnished LIB?
PIC32MX340
I've still not got my head around where the LIB files (folder) should actually go. the IDE should be able to see it in it's defined paths, right?
Thanks!
Alan KM6VV
Fri, 01 Jul 2011 23:37:30 +0000
Hi, i.e. the library I'm trying to use is manipulating DDRD. Phil
The i/o blocks on the PIC32 parts and the AVR parts are implemented differently. DDRD is the data direction register for PORTD. On an AVR, setting a DDR register bit to 1 makes the pin an output.
The equivalent register in a PIC part would be the TRISD (tristate) register. Setting a TRIS bit to 1 makes the pin an input.
On an AVR part, writing to the PORT register writes to a latch. If the pin is configured as an output the value in the latch sets the state of the pin. If the pin is configured as an input, it controls turning on or off an internal pullup resistor.
On a PIC, writing to the PORT actually writes to a register called LAT (latch). Writing to PORTD or LATD have the same effect. If the pin is configured as an output, it sets the state of the pin. If the pin is configured as an input, it doesn't do anything but write to the latch.
On an AVR part you read the pin state by reading the PIN register. On a PIC part, you read the pin state by reading the PORT register.
On an AVR part if you read from the PORT register, you read the last value written. To read the last value written on a PIC part, you read the LAT register.
Gene Apperson Digilent
Mon, 11 Jul 2011 08:26:11 +0000
I'm trying to use a third part library but it uses avr-specific code to control an GLCD. Can I modificate this library to use it with chipkit uno32 ? What are the steps to modify a library like that ? There are some work in progress that will be applied in the next versione of the mpide that solve the problem ?
Thanks to all of you for your support !
Mon, 11 Jul 2011 11:30:18 +0000
Yes the library can be modified. I have a library working on several graphic LCD displays already. Which one are you using. I will try to get it converted.
Mark
Mon, 11 Jul 2011 12:44:36 +0000
I'm using the iteadstudio 's ITDB02 is an LCD with Touch screen. At he end you will find a zip file as attachment, with the libraries of my interest inside.
Thanks a lot !! ;)
Mon, 11 Jul 2011 16:11:15 +0000
Hi
Just a quick note... I am the author of the libraries refered to here, and I will be releasing a chipKip-port of those libraries soon. I just have to finish some modifications to my website first.
/Henning
Tue, 12 Jul 2011 08:05:55 +0000
Wonderful !!!!! I hope that you'll release it soon...... :D
Thanks a lot for your work !
Wed, 13 Jul 2011 00:26:35 +0000
Hi Just a quick note... I am the author of the libraries refered to here, and I will be releasing a chipKip-port of those libraries soon. I just have to finish some modifications to my website first. /Henning
I can attest to the quality of work that Henning does; I was one of the first to use his touch and display libraries for the Arduino Uno and then the Mega and they made my life easy indeed. I was able to craft a first class GUI, with user touch control, for my project using his handiwork!!!
Thanks again Henning!!!!!!!!!!!!!!!
David Garrison :D
Wed, 13 Jul 2011 07:06:32 +0000
Thank you very much David.
I am hoping to release the ported versions of my RGB_GLCD and ITDB02_Graph libraries this weekend, with ITDB02_Graph16 following soon after that.
/Henning
Wed, 13 Jul 2011 14:59:18 +0000
Thank you very much David. I am hoping to release the ported versions of my RGB_GLCD and ITDB02_Graph libraries this weekend, with ITDB02_Graph16 following soon after that. /Henning
If you are interested in adding a color graphics display with touch input to your ChipKit module (or Arduino) board then you might want to have a look at Hennings website:
[url]http://henningkarlsen.com/electronics/index.php[/url]
I promise that you will not be disappointed!
David Garrison --a satisfied user--
Sat, 16 Jul 2011 18:17:37 +0000
Once again I thank you David, both for the high praise and for your very generous donation :)
I have released my first chipKit libraries today.
Check out my website for more info: [url]http://www.henningkarlsen.com/electronics[/url]
/Henning
Mon, 18 Jul 2011 13:16:45 +0000
Thank you so much. Now i'm wating for the touch module version........ I'm going to test the LCD module !
Tue, 19 Jul 2011 02:45:31 +0000
Henning:
I have your CK_ITDB02_Graph libraries now running on a UNO32. Works as expected. I did run into one small problem and that was when I finished wiring the ITDB02 2.4 display up to the UN032 the display did not light up..After several anxious moments and schematic reviews, I saw that I had not connected up the backlight LED to the 3.3V..I had assumed that only the connections shown on the requirements .PDF were needed. Ypu might want to add a note about that; if you are using a ITead shield (which in this case is not possible)it would taken care of for you.
All in all it is MUCH faster than the Arduino, but I expected that! nudge, nudge... looking forward to your other libraries being ported....... Thanks for your energy
David Garrison
Tue, 19 Jul 2011 20:56:46 +0000
As David says you must remember to connect the LED-A pin from your ITDB02 module to 3.3v or else you probably will not be able to see much on your display.
You should also connect the RD signal from the module to 3.3v to keep it at a high level. The 2.4" displays does not seem to care, but it caused a MAJOR headache for me on the 3.2" displays.
I will probably write a how-to make your own interface cable, but I want to finish mine first so I know it will work :)
Oh, and the CK_ITDB02_Graph16 had just been released :) You ought to know where to find it by now: [url]http://www.henningkarlsen.com/electronics/[/url]
/Henning
Wed, 20 Jul 2011 14:32:45 +0000
You should also connect the RD signal from the module to 3.3v to keep it at a high level. The 2.4" displays does not seem to care, but it caused a MAJOR headache for me on the 3.2" displays. /Henning
Hello All
I found out last night that holding the RD signal line high solved two seperate problems with my 2.4" display, both of which I tried to ignore until later when I had some time. I did tie the RD signal line to the 3.3V and the "display noise --dropped lines and odd pixels here and there" went away on the bit map demo examples.. On a lark I tried connecting to external power on the UNO32 (regulated 5.0V and the power jumper set to bypass) a condition under which the 2.4" display would not function, I could only get the display to work with the USB port power, and ....It worked! Why? who knows ...why didn't it work before....? under both power input conditions the 3.3V measured the same (just about 3.3vV) ??? I now have rock solid 2.4" color display.
Tonight I will wire up my 3.2" and see how that works. I am now not expecting any surprises..with ALED and RD connected to 3.3V!
One other thing to note: the demo examples now run really fast and it is hard to see some of the animated portions of the demos.. I added some delays and changed some values to slow them down. This makes them more appealing and interesting..the moving SIN wave benefited most from this.
David G.
Fri, 22 Jul 2011 14:26:29 +0000
Hi All:
I finally got the 3.2 " LCD display wired up to my UNO32 and have it running the CK_ITDB02_Graph16 example demos. Neat!
I had a bit of a fuss until Henning told me that the pin 10 function jumper (JP4)needs to be set to the PWM position. See: [url]http://www.digilentinc.com/Data/Products/CHIPKIT-UNO32/chipKIT-Uno32-Jumpers.pdf[/url].
I can now start to write the code for my planned application..It will use the touch input library, that I understand will be along soon.
I will be replacing a Arduino UNO that now uses a mess of input button switches (8) and bicolor LEDs (16) as the user interface. It works just fine , but Henning's graphic libraries for the ChipKit boards allow me to keep up the fine traditon of "Feature Creep"!
Happy Summer to All
David Garrison
Fri, 22 Jul 2011 17:35:49 +0000
Due to the bombing in Oslo today I will probably not be able do much work on the porting this weekend (clarification: I live in Oslo).
But, the touch-library is next on my list :)
/Henning
Fri, 22 Jul 2011 17:39:09 +0000
Sorry to hear that. Best wishes and our prayers for all.
Alan KM6VV
Sat, 23 Jul 2011 01:46:08 +0000
All our thoughts and prayers are with you and all that have been effected by these terrible events.
David G.
Sat, 23 Jul 2011 11:08:44 +0000
As things are starting to return to normal for most people in Oslo already I did port the CK_ITDB02_Touchtoday afterall :P
You know where...
/Henning
Sat, 23 Jul 2011 17:45:36 +0000
As things are starting to return to normal for most people in Oslo already I did port the CK_ITDB02_Touchtoday afterall :P You know where... /Henning
Downloaded..wired up (used with ITead Studios 3.2" screen and UNO32).. ran calibration; made corrections, ran demo- buttons..works!
note: This capability, a 3.2" screen and touch in the Arduino world requires a Mega (more output pins than Uno) runs a lot slower and costs more !.
Henning, thanks again for this wonderful library!!!! [img]http://s1139.photobucket.com/albums/n554/sierrasmith71/][/img] David Garrison
Sun, 04 Sep 2011 04:55:05 +0000
Correct, any library that directly access the hardware has to be re-written From now on, any file that references hardware should do things like this #if defined(AVR) #include <avr/pgmspace.h> #endif and if its only written for AVR #if !defined(AVR) #error This code only works on the AVR platform #endif
Good idea. Now when are you fixing up all the libraries etc for pic32 in the same way? One could also pointedly ask when Microchip will fix up all the software available under free open source licenses to be multi-platform. Having done absolutely nothing to provide any FOSS in the past Microchip is now trying to freeload on the Arduino bandwagon. It's good to see they've knocked the Arduino IDE into shape, but that doesn't give you a functional development environment. Among other things you need a compiler and a C runtime library. Have you looked at the offensive license conditions Microchip has put into the C runtime supplied with the chipkit-modified Arduino IDE? Do they have any plans providing a FOSS one?
I have changed some of my libraries to address the portability issue, but the bottom line is a large part of the AVR software is user-supplied over a long time by AVR users, so if pic32 (anything less than pic32 is useless here) users want to tap in then they'll probably have to do some more work too.
Sat, 17 Sep 2011 20:12:58 +0000
I'm triying to migrate a library to Chipkit and get the following error:
error: cast from '__uint8_t*' to '__uint16_t' loses precision
linked to this line:
dst_mask = (uint16_t)dst & SMASK;
Type of the variable dst is uint8_t*
Anyone has an idea where the incompatibility comes from?
Sun, 18 Sep 2011 00:04:26 +0000
error: cast from '__uint8_t*' to '__uint16_t' loses precision
Do you understand what that line of code does? The basics of the AVR8 architecture is that it is an 8-bit CPU with a 64k (16bit) address space for variables (the address space for programs is separate from data in the Harvard architecture of the AVR8, and may be larger, like on the Arduino Megas). A data pointer (to anything) is therefore 16bit on the AVR8, but is obviously 32bit on a 32bit architecture with a 4G address space. So the error you get is precisely to the point: you're dumping half of the pointer size. Casting a pointer to 16bit is obviously not portable code. Unfortunately C and C++ miserably fail to define a type for the size of a pointer. With avr-gcc both size_t and ptrdiff_t are defined to 16bit and could be used as a pointer size type. Note that size_t is unsigned, and ptrdiff_t is signed and strictly speaking only available in C++.
Btw you find that out by dumping the C preprocessor content to output. This will also tell you what conditionals you can use to identify the architecture:
avr-cpp -dMI < /dev/null | sort -d | grep -i size
pic32-cpp -dMI < /dev/null | sort -d
arm-none-eabi-cpp -dMI < /dev/null | sort -d
To be more explicit you could do something like this:
#ifdef __AVR__
typedef uint16_t ptrsize_t
Now let me guess - all the johnny-come-lately pics are complaining about code being avr specific, but are they as short-sighted? So you'd want to continue with
#elif defined(__PIC32MX__)
typedef uint32_t ptrsize_t
#elif defined(__ARM_EABI__)
typedef uint32_t ptrsize_t
#else
#error Unknown pointer size for architecture. Add definition here.
#endif
You could start with casting to size_t instead of uint16_t, but that still doesn't mean your particular code bit will then work. You may have to deal with other hardware-related issues too, like what the pointer masking is supposed to achieve exactly, and whether that works on pic too.
Mon, 19 Sep 2011 11:51:24 +0000
Thank you very much for your complete and detailed answer. That solves the compilation problem, but as you mentioned, there are probably other hardware related issues that I need to investigate since it is not working yet!