Virtual Wire lib for CHIPKIT

Created Fri, 03 Apr 2015 10:23:16 +0000 by PICedh

PICedh

Fri, 03 Apr 2015 10:23:16 +0000

Hello,

I have adapted the Arduino Virtual Wire lib for CHIPKIT? this lib. This lib is very helpfull for a very low cost transmission between 2 shields. I have also improved the lib by adding functions that transmitt float and indicate source and type of data.

More details here: [url]http://chipkit.net/virtual-wire-lib-for-chipkit/[/url]

Are you interested to include this lib in the next Chipkit release ?

Eric

guymc

Wed, 08 Apr 2015 20:20:09 +0000

Hi Eric,

Thank you for posting your work, and for suggesting that Virtual Wire be incorporated into the chipKIT software framework. I'll ask the Steering Committee to look into this at the next opportunity.

Cheers

Jacob Christ

Sat, 25 Apr 2015 22:41:22 +0000

Seems like a great thing to include. Any suggestions on how to do this, in the core libraries?

Jacob

Jacob Christ

Sat, 25 Apr 2015 22:43:01 +0000

We have this lib repo we haven't done much with either...

https://github.com/chipKIT32-libraries

Jacob

Jacob Christ

Sat, 25 Apr 2015 22:47:38 +0000

So I was looking at your code and noticed you had a line with a comment that says "comment this out if your not chipkit"

When I ported the cryposuite lib for Arduino to chipKIT I added this:

#if defined(PIC32MX) #define PROGMEM #define memcpy_P(dest,source,len) memcpy((dest),(source),(len)) #define pgm_read_dword(address) (uint32_t)(*(address)) #else #include <avr/io.h> #include <avr/pgmspace.h> #endif

This way its just detected. However, there are not PIC32MZ parts in the mix an this may not be the best way to do this. I'll try to get some smarter people to look at this post.

Jacob

EmbeddedMan

Sat, 25 Apr 2015 22:51:19 +0000

If we don't have some sort of #define CHIPKIT that we can test in our code, we really should have.

*Brian

majenko

Sat, 25 Apr 2015 22:57:24 +0000

You can check for PIC32MZ as well as PIC32MX I believe.

You can also look for sub families too, like PIC32MX1XX

Check in the cpudefs.h file in the core for all the funky defines.

majenko

Sat, 25 Apr 2015 22:59:43 +0000

I think I got Jason to add a chipKIT or similar defines to the compiler so we can tell it apart from XC32.

majenko

Sat, 25 Apr 2015 23:47:51 +0000

I can't see the CHIPKIT define in the compiler I'm using on UECIDE, and I thought that was the absolute latest. Instead it has the XC32 define back in there. I'll check with Jason to see if that got missed. It was definitely there at one point.

There is, however, some other useful defines available:

#define __PIC32
#define __PIC32__
#define PIC32

(if MX part is used)
#define __PIC32MX
#define __PIC32MX__
#define PIC32MX

(if MZ part is used)
#define __PIC32MZ
#define __PIC32MZ__
#define PIC32MZ

Jacob Christ

Sun, 26 Apr 2015 00:43:59 +0000

Looks like PIC32 or PIC32 would be the ticket unless you need to target a specific family or chip.

Jacob

majenko

Sun, 26 Apr 2015 09:50:15 +0000

You can use any of PIC32 __PIC32 or PIC32 - the choice is yours. The three are provided purely because some people are used to using ARCH, some __ARCH and others ARCH from ancient times. Personally I use ARCH as it is more obviously a compiler-defined symbol a opposed to something more local.

My personal underscore / capitalisation preference is:

• SYMBOL = compiler defined
• __SYMBOL = core defined
• _SYMBOL = library or include-local define
• _symBol = Class (library) member variable
• SYMBOL = local or other "normal" program define
• symBol = local or other "normal" program variable

Note that I am a fan of camelCase and think that people who still insist on using Hungarian notation should be shot. usI gulLike bMy uspPrograms ubTo crBe udReadable.

Jacob Christ

Sun, 26 Apr 2015 10:39:46 +0000

+1 on people who still insist on using Hungarian notation should be shot.

I do use it from time to time, because I would rather not mix metaphors when maintaining someone elses code.

Jacob