MRF90XAM9A interfacing help

[Tabsoft]

Sorry for the delay.

No I didn't get anywhere with this as I didn't pursue it further.
Got off on different projects.

[ecoli-557]

I know, frustrating.
I have a ticket with Microchip, perhaps they can shed some light....
Regards.

[astanapane]

i've seen most of the RFM topics are not completed. I'm about to use the Adafruit RFM 69HCW for sending GPS data from one side to the other. (embedded the modules and the code on this project http://www.picbasic.co.uk/forum/show...936#post143936)

I've seen other posts as well, whicht a guy tried to do the same thing with the GPS, but didnt see any luck.

Has anyone finally succeed to those modules? I'm on holidays right now, and the following days i will try to configure the registers at first.

It is sad that this amazing unique forum, not to have a start up code for each major application. Just for all the users to see and experiment with every single application.

There are still very helpful guys here but non of them have posted a startup code for those modules. And i believe that not only me would love to see that kind of help.

Thanks so much again for your time.

[richard]

It is sad that this amazing unique forum, not to have a start up code for each major application

[rant]
its not the fault of the forum its pbp's total lack of development that causes the issue.
pbp cannot easily manage memory/memory structures or most of the pic inbuilt hardware modules. its difficult to
make easy to use flexible pin definitions to use in include files so that library functionality can be created.
most of my stuff uses asm and usercommand to overcome some of these hurdles but that leads to another level
of complexity for code that translates between pic16/18 platforms. half the people here never even upgraded to pbp3
the lack of usercommand in pbp2 kills that sort of combability anyway. you would have to wonder if more people upgraded to
pbp3 in the past if development would have continued instead of becoming a backwater. all this stuff is dead easy in C .plug and play in Arduino


the rfm69 family of modules are a quite complex device to use , their range and speed make the effort worthwhile
if warranted. i have used them for several years now and did initially use them with pbp3. i did not publish
my code for a number of reasons :-
i wrote it specifically to suit my application , to be compatabile with rfm12bs[a retrograde step] , the code is completey undocumented .
you could write a small novel explaining usage of a rfm69w/cw/hcw... . i look back on other less complex things i have posted
code for like TFT modules, i went to a lot of trouble to make it easy-ish and adaptable . i think 3 people have had some
success in using the code . three people in the whole world FFS. the rfm69 code can be more complex and they are more exotic why would i
bother.
unless you really need the speed/range then there a many less complex devices to use. you thought my suggestions for your gps project
were overly complex rfm69 code is of the same ilk maybe more so.
i was going to say nrf24L01 is a candidate ,very cheap not too hard to use but just noticed i did not even bother to create a pbp include for them , its all C from here

[astanapane]

[rant]
its not the fault of the forum its pbp's total lack of development that causes the issue.
pbp cannot easily manage memory/memory structures or most of the pic inbuilt hardware modules. its difficult to
make easy to use flexible pin definitions to use in include files so that library functionality can be created.
most of my stuff uses asm and usercommand to overcome some of these hurdles but that leads to another level
of complexity for code that translates between pic16/18 platforms. half the people here never even upgraded to pbp3
the lack of usercommand in pbp2 kills that sort of combability anyway. you would have to wonder if more people upgraded to
pbp3 in the past if development would have continued instead of becoming a backwater. all this stuff is dead easy in C .plug and play in Arduino


the rfm69 family of modules are a quite complex device to use , their range and speed make the effort worthwhile
if warranted. i have used them for several years now and did initially use them with pbp3. i did not publish
my code for a number of reasons :-
i wrote it specifically to suit my application , to be compatabile with rfm12bs[a retrograde step] , the code is completey undocumented .
you could write a small novel explaining usage of a rfm69w/cw/hcw... . i look back on other less complex things i have posted
code for like TFT modules, i went to a lot of trouble to make it easy-ish and adaptable . i think 3 people have had some
success in using the code . three people in the whole world FFS. the rfm69 code can be more complex and they are more exotic why would i
bother.
unless you really need the speed/range then there a many less complex devices to use. you thought my suggestions for your gps project
were overly complex rfm69 code is of the same ilk maybe more so.
i was going to say nrf24L01 is a candidate ,very cheap not too hard to use but just noticed i did not even bother to create a pbp include for them , its all C from here

Hi Richard,

thanks once again for your kind reply. I'm not familiar with programming as you have already understood, so for me will be really difficult to make any of these modules to work. I always think, technology make things easier and as those modules are "new" then it would be much easier for a user to embed those small and nice systems.

I also thought that PBP, is capable of making thinks easier for most of the users. I've seen over the internet the Arduino users, have ready libraries for everything and even sample programs that are functioned. I was wonder why not here.

PBP is it quite friendly and can become complicated, but in arduino world, things looks much easier when libraries are documented and registered for every single application. To be honest now i'm quite old to start understanding C language, and as being on a completely different area of interest (3D printing in Medicine) i do not have much time.

I do what i do for my own experiments and hobby.

I dont want you share any of your code, but it would be really nice, if anyone could simply start developing a code for those applications using RFM69 or even Lora modules.

thanks a lot once again.

[richard]

but it would be really nice, if anyone could simply start developing a code for those applications using RFM69 or even Lora modules.

I think you have missed the point of my post , I don't think it can happen the pic environment is awash with veritable plethora of hardware combinations
the "simple" Arduino style libraries you seek exist because the Arduino is a rigid series of products , each one has a fixed osc ,fixed pin definitions ,
a fixed setup routine ,a fixed software shell , a fixed interrupt handler etc.... the user can change none of these things . the hardware is abstracted away from the user
hell even the pwm freq is fixed .you need some level skill to manipulate any of the hardware and the Arduino ide makes sure its going to stay that way and will
hide as much as it can from you

[astanapane]

I think you have missed the point of my post , I don't think it can happen the pic environment is awash with veritable plethora of hardware combinations
the "simple" Arduino style libraries you seek exist because the Arduino is a rigid series of products , each one has a fixed osc ,fixed pin definitions ,
a fixed setup routine ,a fixed software shell , a fixed interrupt handler etc.... the user can change none of these things . the hardware is abstracted away from the user
hell even the pwm freq is fixed .you need some level skill to manipulate any of the hardware and the Arduino ide makes sure its going to stay that way and will
hide as much as it can from you

Many people told me to stay away from arduino.

So you are saying that in pic environment will never happen something like this, because of its complexity. People do not bother to learn and configure a complex hardware, so they move to a fixed and standardized hardware, that effort is eliminated.