MRF90XAM9A interfacing help

[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.

[richard]

People do not bother to learn and configure a complex hardware, so they move to a fixed and standardized hardware, that effort is eliminated.

its not that people don't bother , its that there are no pbp tools to do it properly.

i will give you an simple example of the problem that demonstrates why i don't bother making anymore "hardware module" code for pbp any longer
if you extrapolate this to include port/pin choices,on chip hardware and complex memory needs its no wonder that no "libraries" exist .
take my tm1637 demo
http://www.picbasic.co.uk/forum/showthread.php?t=23417
the code is small, efficient and feature rich and works wonderfully, usercommand allows it fit seemlessy into pbp as though it was a pbp function.
problem is it only works on enhanced core pic16 devices.
to use it on a older chip like a pic12f683 it needs a bit of work these chips have only got one 8 bit FSR and no BRW opcode
whereas the modern chips have 2 16 bit FSR's and a BRW opcode .
therefore my rjust function can't work on these old chips and the rest of the code needs a bit of a tweak too
the asm portion of the code becomes :-

SEG_val         ;VALID INPUT  0-9 ,A-F, a-f ," " ,-
    CHK?RP  _TM_TMP
    MOVWF   _TM_TMP
    SUBLW   0x21
    btfsc   STATUS, C
    retlw   0   ;" "
    MOVF    _TM_TMP,W
    SUBLW   0x2f
    btfsc   STATUS, C
    retlw   64   ;"-"
    MOVF    _TM_TMP,W
    MOVLW   0X40
    SUBWF   _TM_TMP,W
    btfsC   STATUS, C
    GOTO    TM_ALPHA
    MOVF    _TM_TMP,W
    ANDLW   0X0F
    GOTO    TM_LU
TM_ALPHA 
    ANDLW   0xdf    ;ucase
    SUBLW   6
    btfsS   STATUS, C
    retlw   0       ;ERROR
    MOVLW   0X37
    SUBWF   _TM_TMP,W
    ANDLW   0xdf    ;ucase
TM_LU     
    addwf   PCL, F                                          
    retlw  0X3F    ;0   
    retlw  6             
    retlw  0X5B   
    retlw  0X4F 
    retlw  0X66
    retlw  0X6D                        
    retlw  0X7D  
    retlw  7   
    retlw  0X7F          
    retlw  0X67    ;9
    retlw  0X77    ;A
    retlw  0X7C    ;b
    retlw  0X39    ;C
    retlw  0X5E    ;d
    retlw  0X79    ;E
    retlw  0X71    ;F
    
TM_START  
_TM_START   
    CHK?RP TM_OUT_PORT
    BSF    TM_OUT_PORT,TM_CLK
    BSF    TM_OUT_PORT,TM_DIO
    NOP
    BCF    TM_OUT_PORT,TM_DIO
    NOP
    BCF    TM_OUT_PORT,TM_CLK
    ;NOP
    RETURN
    
TM_STOP 
_TM_STOP 
    CHK?RP TM_OUT_PORT
    BCF    TM_OUT_PORT,TM_CLK 
    BCF    TM_OUT_PORT,TM_DIO 
    NOP
    BSF    TM_OUT_PORT,TM_CLK 
    NOP
    BSF    TM_OUT_PORT,TM_DIO 
    ;NOP
    RETURN
    
TM_WRITE  
_TM_WRITE
    MOVLW  8 
    CHK?RP _TM_BIT
    MOVWF  _TM_BIT
NXBT   
    CHK?RP TM_OUT_PORT
    BCF    TM_OUT_PORT,TM_CLK 
    CHK?RP _TM_DAT
    BTFSS  _TM_DAT,0
    GOTO   TM_0
    CHK?RP TM_OUT_PORT
    BSF    TM_OUT_PORT,TM_DIO 
    GOTO   TM_NB
TM_0    
    CHK?RP TM_OUT_PORT
    BCF    TM_OUT_PORT,TM_DIO  
TM_NB   
    CHK?RP _TM_DAT
    RRF    _TM_DAT,F
    CHK?RP TM_OUT_PORT
    BSF    TM_OUT_PORT,TM_CLK 
    CHK?RP _TM_BIT
    DECFSZ _TM_BIT,F
    GOTO   NXBT
    CHK?RP TM_OUT_PORT
    BCF    TM_OUT_PORT,TM_CLK 
    CHK?RP TM_TRIS
    BSF    TM_TRIS,TM_DIO 
    CHK?RP TM_IN_PORT
    BTFSC  TM_IN_PORT,TM_DIO 
    BSF    _TM_NAK,7
    CHK?RP TM_OUT_PORT
    BSF    TM_OUT_PORT,TM_CLK 
    NOP
    NOP
    NOP
    NOP
    BCF    TM_OUT_PORT,TM_CLK 
    CHK?RP TM_TRIS 
    BCF    TM_TRIS ,TM_DIO 
    BANKSEL 0
    RETURN
_TM_INIT
    CHK?RP  _TM_COLON
    CLRF    _TM_COLON
    CLRF    _TM_BRIGHT
    CHK?RP TM_TRIS
    BCF    TM_TRIS ,TM_DIO
    BCF    TM_TRIS ,TM_CLK
    BANKSEL 0
    RETURN
    
_TM_DISP4
    CHK?RP  _TM_DAT
    MOVLW   _CMD_AUTO_ADDR
    MOVWF   _TM_DAT
    CLRF    _TM_NAK
    CALL    TM_START
    CALL    TM_WRITE
    CALL    TM_STOP
    MOVLW   _NUM_DIGITS          
    CHK?RP  _TM_DIG
    MOVWF   _TM_DIG
    MOVLW   _START_ADDR
    CHK?RP  _TM_DAT
    MOVWF   _TM_DAT
    CALL    TM_START
    CALL    TM_WRITE 
NXDIG
    MOVF INDF,W
    INCF FSR ,f
    CALL    SEG_val
    CHK?RP  _TM_DAT
    IORWF   _TM_COLON ,W
    movwf   _TM_DAT
    CALL    TM_WRITE
    CHK?RP  _TM_DIG
    DECFSZ  _TM_DIG,F
    GOTO    NXDIG
    CALL    TM_STOP
    CHK?RP  _TM_BRIGHT 
    MOVF    _TM_BRIGHT ,W
    ANDLW   7
    IORLW   _DISPLAY_ON
    CHK?RP  _TM_DAT
    MOVWF   _TM_DAT
    CALL    TM_START
    CALL    TM_WRITE
    CALL    TM_STOP
    BANKSEL 0
    RETURN
ENDASM

but it still wont work on a pic18 they have no MOVIW, MOVWI OR BRW opcodes.
so it needs a rework for them too. apita .its not easy to cover all the bases . i wrote the code to suit my app
at that time . if i need to use the code on a different chip i don't want to keep reinventing the wheel, a modular approach
is what i'm looking for. pbp simply has no tools to make that process a pleasant one.
to do the same thing in C needs no asm code other than a few NOPs for timing and is fully portable with no changes needed
eg
c source :-

#include "tm1637.h"
/*pin manager DEFINES :-
 TM_DIO ,TM_CLK 
 */
char TM_BRIGHT=1,TM_COLON=COLON_OFF ;
void SET_TM_COLON(char d){
    if (d) 
        TM_COLON=COLON_ON;
    else
        TM_COLON=COLON_OFF;           
}
void SET_TM_BRIGHT(char d){
    TM_BRIGHT = d&7;            
}
void TM_START(){
    TM_CLK_LAT=1;
    TM_DIO_LAT=1;
    asm ("NOP");        
    TM_DIO_LAT=0;
    asm ("NOP");
    TM_CLK_LAT=0;
}
    
void TM_STOP(){ 
    TM_CLK_LAT=0; 
    TM_DIO_LAT=0;
    asm ("NOP"); 
    TM_CLK_LAT=1;
    asm ("NOP");   
    TM_DIO_LAT=1; 
}
char TM_WRITE(char dat){ 
    char bit_cnt;
    for (bit_cnt=0;bit_cnt<8;bit_cnt++){    
    TM_CLK_LAT=0;  
    TM_DIO_LAT=dat&1;  
    dat>>=1;   
    TM_CLK_LAT=1;
    }
    TM_CLK_LAT=0; 
    TM_DIO_SetDigitalInput();
    bit_cnt=TM_DIO_GetValue();
    TM_CLK_LAT=1;
    #asm
    NOP
    NOP
    NOP
    NOP
    #endasm
    TM_CLK_LAT=1;
    TM_DIO_SetDigitalOutput();
    return bit_cnt;  //NAK IF SET
}
            
void TM_DISP(char* buff){
    char dat,TM_DIG,tmp;
    dat=CMD_AUTO_ADDR;
    TM_START();
    TM_WRITE(dat);
    TM_STOP();    
    dat=START_ADDR;
    TM_START();
    TM_WRITE(dat); 
    for(TM_DIG=0;TM_DIG<NUM_DIGITS;TM_DIG++ ){
        tmp=buff[TM_DIG];
        dat=SEG_VAL(tmp)|TM_COLON;
        TM_WRITE(dat);
    }
    TM_STOP();
    dat=(TM_BRIGHT&7)|DISPLAY_ON;
    TM_START();
    TM_WRITE(dat);
    TM_STOP();
}           
            
char  SEG_VAL(char dat){
    const char seg_data[]={ 0X3F,6,0X5B,0X4F,0X66,0X6D,0X7D,7,0X7F,0X67,0X77,0X7C,0X39,0X5E,0X79,0X71};
      if (isdigit(dat))
            return seg_data[dat-'0'];
      else if (isxdigit(dat))
            return seg_data[toupper(dat)-'A'+10];
      else if (dat=='-')
            return 64;
      else 
            return 0;
}

and the header file :-

/* 
 * File:   tm1637.h
 * Author: rc
 *
 * Created on January 3, 2018, 4:42 PM
 */
#ifndef TM1637_H
#define TM1637_H
#ifdef __cplusplus
extern "C" {
#endif
    
#include <ctype.h>
#include <stdlib.h>
#include <stdarg.h>
#include <stdio.h>    
    
#include "mcc_generated_files/mcc.h"   
#include "mcc_generated_files/pin_manager.h"
#define    CMD_AUTO_ADDR 0x40 
#define    START_ADDR    0xc0 
#define    NUM_DIGITS    0x4               //number of 7seg leds
#define    COLON_ON      0x80 
#define    DISPLAY_ON    0x88
#define    COLON_OFF     0
void  TM_START();
void  TM_STOP();
char  TM_WRITE(char);
char  SEG_VAL(char);
void  TM_DISP(char*);
void SET_TM_COLON(char);
void SET_TM_BRIGHT(char);
#ifdef __cplusplus
}
#endif
#endif /* TM1637_H */

and a C example of usage

#include <xc.h>
#include  "mcc_generated_files/mcc.h"
#include  "mcc_generated_files/pin_manager.h"
#include <ctype.h>
#include <stdlib.h>
#include <stdarg.h>
#include <stdio.h>
#include  "tm1637.h" 
#include  "hx711.h" 
/*pin manager DEFINES :-
 TM_DIO ,TM_CLK   
 HX_OUT,HX_SCH
 ZERO_SW
 */
 
void main(void)
{
    short long  cnt;
    char buffer[5];
    SYSTEM_Initialize();
    SET_TM_BRIGHT(2);
    while ( HX_OUT_GetValue()){} ;     
    while (1)
    {
      if(!ZERO_SW_GetValue() ) {
         SET_HX_ZERO();
        while (!ZERO_SW_GetValue() ) {}; 
      } 
      cnt = READ_HX711();
      cnt >>=5;
      SET_TM_COLON(0);
      sprintf(buffer,"%4d",cnt);
      TM_DISP(buffer);
      __delay_ms(500);
    }
}

to do the same in pbp code is possible but twice the size and half as fast with less features . and that is for a very simple device
http://www.picbasic.co.uk/forum/show...196#post144196