+ Reply to Thread
Page 2 of 2 FirstFirst 12
Results 41 to 63 of 63
  1. #41
    Join Date
    Sep 2007
    Location
    Waco, Texas
    Posts
    151

    Default Re: MRF90XAM9A interfacing help

    Changed the registers one more time - still no PLL lock being reported.
    Below:
    Code:
         RF_Init_Values[0] = $2A                                                   'Standby mode, 915-928 MHz, VTune by inductors, ENABLE R1/P1/S1
         RF_Init_Values[1] = $8C                                                   'FSK, max IF gain, Packet Mode
         RF_Init_Values[2] = $03                                                   '100KHz Freq Dev
         RF_Init_Values[3] = $07                                                   '25kbps
         RF_Init_Values[4] = $0C                                                   'for OOK mode, not apliable
         RF_Init_Values[5] = $01                                                   '16Bytes FIFO, 1 byte threshold FIFO interrupt
         RF_Init_Values[6] = $77                                                   '915MHz R1 Reg
         RF_Init_Values[7] = $64                                                   '915MHz P1 Reg
         RF_Init_Values[8] = $32                                                   '915MHz S1 Reg
         RF_Init_Values[9] = $74                                                   '920MHz R2 Reg
         RF_Init_Values[10] = $62                                                  '920MHz P2 Reg
         RF_Init_Values[11] = $32                                                  '920MHz S2 Reg
         RF_Init_Values[12] = $38                                                  'config mode for OOK, not apliable
         RF_Init_Values[13] = $00                                                 'RCV:IRQ0=payload ready + IRQ1=CRC OK
                                                                                   'TX: IRQ1=TXdone
         RF_Init_Values[14] = $01                                                  'FIFO starts filling when SYNC detected,TXDONE goes hi when done,
                                                                                   'RSSI IRQ when is above level set, enable PLL lock
         RF_Init_Values[15] = $00                                                  'RSSI interupt level zero - minimum
         RF_Init_Values[16] = $A3                                                  'default filters config
         RF_Init_Values[17] = $38                                                  'default filters config
         RF_Init_Values[18] = $30                                                  'sync word ON, 24bits, 0 errors tolerance
         RF_Init_Values[19] = $07                                                  'reserved reg
         RF_Init_Values[20] = $00                                                  'RSII status read register, 0.5dB / bit
         RF_Init_Values[21] = $00                                                  'OOK config reg
         RF_Init_Values[22] = $53                                                  '"S" 1st byte of sync word
         RF_Init_Values[23] = $53                                                  '"S" 2nd byte of sync word
         RF_Init_Values[24] = $53                                                  '"S" 3rd byte of sync word  - my initials!
         RF_Init_Values[25] = $53                                                  '"S" just in case
         RF_Init_Values[26] = $72                                                  'Cutoff fcy = 200KHz, output power = 13dBm 0b000
         RF_Init_Values[27] = $3C                                                  'clk out disabled - default 427KHz
         RF_Init_Values[28] = $03                                                  '3 bytes payload
         RF_Init_Values[29] = $01                                                  'initial MAC ADDRESS, only for test
         RF_Init_Values[30] = $5E                                                  'Fix Packet Lenght, 3 bytes preamble, whitening ON, CRC ON, Node ADDR|0x00|0xFF filtering
         RF_Init_Values[31] = $00                                                  'FIFO autocreal enable if CRC fails, Write to FIFO in stby mode
    I'm frustrated ......
    "If we knew what we were doing, it wouldn't be called research"
    - Albert Einstein

  2. #42
    Join Date
    Sep 2007
    Location
    Waco, Texas
    Posts
    151

    Default Re: MRF90XAM9A interfacing help

    I now get a PLL lock indication, I put a wait until PLL lock bit was true before moving on.
    Code:
                'Verify PLL Lock Flag
    PLLwait:    bReg_Address = $0E                                                  'FTPRIREG
                gosub RegisterRead
                PLL_LOCK = 0
                PLL_LOCK = bReg_Value.1
                         'You can test this bit to see if PLL Is Locked
    debug "waiting for PLL lock",13
                if PLL_LOCK=0 then PLLwait
    PLLdone:
    debug "PLL Lock=",bin1 PLL_LOCK,13
    Still no received data or IRQs however.
    Transmitter gives both IRQ0 and IRQ1 outputs - making some progress.
    "If we knew what we were doing, it wouldn't be called research"
    - Albert Einstein

  3. #43
    Join Date
    Jan 2013
    Location
    Texas USA
    Posts
    229

    Default Re: MRF90XAM9A interfacing help

    Progress for sure.
    When in TX mode your IRQ0 says you have crossed the FIFO Input threshold and IRQ1 says FIFOFull.

    Why don't you try changing your definition of IRQ1 for TX (IRQ1TX) from 0 = FIFOFULL (default) to 1 = TXDONE. This is your RF_Init_Values[13] value.
    Then in the Send_Packet: routine after changing the mode to RF_TRANSMITTER, instead of a hard pause 5, use a loop to test for IRQ1 to go high (TXDONE).
    This way you can explicitly test for the Transmitter to complete.
    Regards,
    TABSoft

  4. #44
    Join Date
    Sep 2007
    Location
    Waco, Texas
    Posts
    151

    Default Re: MRF90XAM9A interfacing help

    Thanks for the additional input TABSoft, I had already changed the $0D register to $08, and still saw no interrupt.
    One thing I had noticed, In the Send_Packet routine, I saw you re-write the registers. I had changed your original code changing registers $1F, $0D, $0E, in which you re-wrote the registers to the original value, I changed to read the register 1st, then performed the logic manipulation thinking it may have been an oversight on your part. Still no output:
    Code:
    Send_Packet:    
                'Set Standby mode
                bRF_Mode = RF_STANDBY
                gosub SetRFMode
        
                'Enable FIFO access in Standby mode
                bReg_Address = $1F  'Register 31
                gosub RegisterRead
                bReg_Value = ((bReg_Value & $BF) | $00)
    '            bReg_Value = (RF_Init_Values(bReg_Address) & $BF) | $00
                gosub RegisterSet
                'Clear FIFO Overrun
                bReg_Address = $0D  'Register 13
                gosub RegisterRead
                bReg_Value = bReg_Value | $01
    '            bReg_Value = (RF_Init_Values(bReg_Address) | $01)
                gosub RegisterSet
                'Set PLL Locked
                bReg_Address = $0E  'Register 14
                gosub RegisterRead
                bReg_Value = bReg_Value | $02                                       'Set LSTLPLL to 1
    '            bReg_Value = (RF_Init_Values(bReg_Address) | $02)
                gosub RegisterSet
    'debug "Send Packet: waiting for PLL lock",13
    '            gosub PLLchk  'Verify PLL Lock Flag
    'debug "Send Packet: PLL locked",13
        
                For i = 0 to (TxPacketLen-1)
                'Wite the Packets to the FIFO
                wr_FIFO_Val = TxPacket[i]
                gosub WriteFIFO
                Next i 
       
                'Set RFMode to Transmit
                bRF_Mode = RF_TRANSMITTER
                gosub SetRFMode
                return
    Then as you can also see, I also added a bit test to see if in fact the PLL locked - it never did. Just sat there and spun waiting. I don't know what that is telling me. The 2 other places I have the wait until PLL lock do seem to change; the initial initialization and the RCV loop. Don't know what that is telling me either......

    I like your advice, and I had thought of doing something similar but my observations in the no IRQ0 or IRQ1 being set, I was looking for a way to test the register to see if the FIFO was ready. Some kind of flag I could use.
    I still haven't found it - an easy one.

    I have been on MC site and found numerous people grumbling over this radio - I can't believe this is so hard! One guy could never get the packet to work and went for the buffered approach. Many, Many posters have had interrupt issues as well. Seems I am not alone. All the more reason to post actual working code.

    My current drain is higher on the transmitter, so I think it is transmitting, and I actually believe the receiver is receiving - I just don't have it set to flag me so I can get the data!

    Thanks again for the assist, I owe you several beers! Any other ideas?
    Regards.
    "If we knew what we were doing, it wouldn't be called research"
    - Albert Einstein

  5. #45
    Join Date
    Jan 2013
    Location
    Texas USA
    Posts
    229

    Default Re: MRF90XAM9A interfacing help

    Sorry I've been busy on other items.
    Have you made any further headway or are you still stuck?
    Regards,
    TABSoft

  6. #46
    Join Date
    Sep 2007
    Location
    Waco, Texas
    Posts
    151

    Default Re: MRF90XAM9A interfacing help

    Thanks for asking, I haven't done any more on it. I don't have a spectrum analyzer to see if its transmitting, so its really frustrating.
    It looks like it should work, but it doesn't so I am still missing something basic I feel.
    I appreciate your help, but, I am stuck and like you, I have things I should be doing besides this 'fun' item.
    "If we knew what we were doing, it wouldn't be called research"
    - Albert Einstein

  7. #47
    Join Date
    May 2013
    Location
    australia
    Posts
    1,465

    Default Re: MRF90XAM9A interfacing help

    these rfm69 chips are easy to use and have loads of working examples to draw information from and are really cheap too

    http://www.ebay.com.au/itm/RFM69CW-HopeRF-433Mhz-Wireless-Transceiver-with-RFM12B-compatible-Footprint-/181643908981?pt=LH_DefaultDomain_0&hash=item2a4ad2 1775

    I started out with the rfm12b modules and now have developed code that can successfully network the rfm69's with the old rfm12b's . I had similar issues to you trying to get the rfm69's up an running , not having the right gear to see what is really happening makes life difficult . in my case the known working rfm12b net allowed me to get pkt reception code working first after that the tx side just fell into place.

  8. #48
    Join Date
    Sep 2007
    Location
    Waco, Texas
    Posts
    151

    Default Re: MRF90XAM9A interfacing help

    Richard, Thanks for the link. My only desire (if I stick with it) to use the MC modules, is I think it would be interesting to build my own PAN using the Zigbee stuff.
    HOWEVER, as I have not demonstrated that I am smart enough to figure it out, another module may be in need.
    Do they make these with an integrated antenna?
    "If we knew what we were doing, it wouldn't be called research"
    - Albert Einstein

  9. #49
    Join Date
    Jan 2013
    Location
    Texas USA
    Posts
    229

    Default Re: MRF90XAM9A interfacing help

    Just curious.

    Did you ever get these modules working for your project?
    Regards,
    TABSoft

  10. #50
    Join Date
    Sep 2007
    Location
    Waco, Texas
    Posts
    151

    Default Re: MRF90XAM9A interfacing help

    No I did not. I had used up so much time on this 'friendly' project I wasn't getting any of my fun projects moved forward.
    I have shelved it for the time.
    Are you trying to do the same thing?
    If you succeed, please share what you found out. I think my problem is in the interrupt settings - I think its transmitting, and receiving, just not getting out?!?
    "If we knew what we were doing, it wouldn't be called research"
    - Albert Einstein

  11. #51
    Join Date
    Sep 2007
    Location
    Waco, Texas
    Posts
    151

    Default Re: MRF90XAM9A interfacing help

    Tabsoft-
    Did you get anywhere ?
    "If we knew what we were doing, it wouldn't be called research"
    - Albert Einstein

  12. #52
    Join Date
    Jan 2013
    Location
    Texas USA
    Posts
    229

    Default Re: MRF90XAM9A interfacing help

    Sorry for the delay.

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

  13. #53
    Join Date
    Sep 2007
    Location
    Waco, Texas
    Posts
    151

    Default Re: MRF90XAM9A interfacing help

    I know, frustrating.
    I have a ticket with Microchip, perhaps they can shed some light....
    Regards.
    "If we knew what we were doing, it wouldn't be called research"
    - Albert Einstein

  14. #54

    Default Re: MRF90XAM9A interfacing help

    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.

  15. #55
    Join Date
    May 2013
    Location
    australia
    Posts
    1,465

    Default Re: MRF90XAM9A interfacing help

    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
    This is more entertaining than Free to Air TV

  16. #56

    Default Re: MRF90XAM9A interfacing help

    Quote Originally Posted by richard View Post
    [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.

  17. #57
    Join Date
    May 2013
    Location
    australia
    Posts
    1,465

    Default Re: MRF90XAM9A interfacing help

    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
    This is more entertaining than Free to Air TV

  18. #58

    Default Re: MRF90XAM9A interfacing help

    Quote Originally Posted by richard View Post
    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.

  19. #59
    Join Date
    May 2013
    Location
    australia
    Posts
    1,465

    Default Re: MRF90XAM9A interfacing help

    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 :-
    Code:
    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 :-
    Code:
    #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 :-
    Code:
    /* 
     * 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
    Code:
    #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
    This is more entertaining than Free to Air TV

  20. #60

    Default Re: MRF90XAM9A interfacing help

    After all that, i have the simplest question.

    Why after all these years, PBP havent improve itself with a newer and more competitive version? Then Everyone could buy the compiler with no thought.

    Because as far as i see C is not only higher level language, but doesnt need asm.

    Now i'm stack at this stage with the GPS project. Not that the code i have done is efficient or a super smart, but i thought i could send those GPS info, easier from one side to the other by using those modules. I thought that it would be a setup for TX -RX and then using only few command to send GPS data.

    I think that i need to start learning C from the beginning.

    Richard, thanks once again for all of your time and help.

  21. #61
    Join Date
    Apr 2014
    Location
    Northeast
    Posts
    233

    Default Re: MRF90XAM9A interfacing help

    Quote Originally Posted by astanapane View Post
    After all that, i have the simplest question.

    Why after all these years, PBP havent improve itself with a newer and more competitive version? Then Everyone could buy the compiler with no thought.
    Daryl Taylor was involved in the development of PBP up till about 3 years ago when he passed away. Charles Leo now carries the entire burden of running ME Labs. ME Labs has been bought out by a racing products company. The real money is in the racing products. Charles continues to support PBP users in spite of the fact that the revenue from PBP sales barely pays the light bills. For above-and-beyond type support, we, as a community, must help each other. Creating cool modules and sharing them helps keep our group moving forward. It's a mixed bag I suppose.

    I think that i need to start learning C from the beginning.
    I just bought a couple books to do just that. I see many benefits from learning C.

  22. #62
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    2,734

    Default Re: MRF90XAM9A interfacing help

    There is an alternative to PBP, Proton Basic.

    As for the lib's comparing to Arduino platform, Richard hit the point well. You have to accept using ONLY one or two chips, with a lot of peripherals to support as many as possible features.

    But this takes away from you the choice. You cannot select a cheaper chip for mass production of a product, tailored to the project needs.

    Can you accept that? I am not as this reduces my range of selection. Then I have to pay the price of doing myself the rest of programming and if I am lucky have some good friends here to help overcome any, usually, silly mistake.

    So, you have to select the right tool for the job.

    Go to Arduino and just download the library for the GPS, Fingerprint reader, RF communication module or Graphic LCD and just power up. Minimal effort on programming but very narrow hardware selection range. And also a strange lanquage.

    ++i? Not for me.

    Ioannis

  23. #63
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    2,734

    Default Re: MRF90XAM9A interfacing help

    There is an alternative to PBP, Proton Basic.

    As for the lib's comparing to Arduino platform, Richard hit the point well. You have to accept using ONLY one or two chips, with a lot of peripherals to support as many as possible features.

    But this takes away from you the choice. You cannot select a cheaper chip for mass production of a product, tailored to the project needs.

    Can you accept that? I am not as this reduces my range of selection. Then I have to pay the price of doing myself the rest of programming and if I am lucky have some good friends here to help overcome any, usually, silly mistake.

    So, you have to select the right tool for the job.

    Go to Arduino and just download the library for the GPS, Fingerprint reader, RF communication module or Graphic LCD and just power up. Minimal effort on programming but very narrow hardware selection range. And also a strange lanquage.

    ++i? Not for me.

    Ioannis

Similar Threads

  1. Interfacing LC75854
    By MR2010 in forum mel PIC BASIC Pro
    Replies: 0
    Last Post: - 18th July 2010, 02:42
  2. Keypad Interfacing
    By uaf5000 in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 15th June 2010, 02:35
  3. Interfacing with the ISD4003
    By lerameur in forum mel PIC BASIC Pro
    Replies: 6
    Last Post: - 2nd June 2008, 15:25
  4. SPI Interfacing
    By toofastdave in forum Serial
    Replies: 8
    Last Post: - 18th November 2007, 11:15
  5. interfacing LCD
    By husakhalid in forum mel PIC BASIC
    Replies: 3
    Last Post: - 30th May 2006, 22:53

Members who have read this thread : 20

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts