 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Question about PIC32 Csubs
| Author | Message | ||||
| sawasdee01 Newbie  Joined: 23/12/2016 Location: United KingdomPosts: 33 |
Hi, I would be very grateful for any help relating to the following:- I have a Lora Gateway, which uses the PIC32MX470 to gather data from a SX1276 Lora transceiver via the SPI Bus, using a TDM based Lora protocol, which I have developed to pass data to and from multiple Lora nodes. All seems to be working well - however, I am now at the point where I need to add one or more additional SX1276 transceivers, so that I can bump up the number of Lora Nodes which can be handled by the Gateway. Due to the design of the TDM Lora protocol, each SX1276 can talk to 12 Lora Nodes, based on talking to all Nodes every 4 seconds. My design makes a lot of use of a MMBASIC sub called LORA_INT(), which as you will probably guess is initiated by a Data Received Interrupt Line, coming from the SX1276. ie SETPIN RFM_INT,INTH,LORA_INT() Unfortunately, quite a lot goes on inside the LORA_INT() subroutine and despite my best efforts at optimisation, it still takes about 50-60ms to traverse the routine (measured using an oscilloscope). So, I am starting to think about re-writing LORA_INT() using a CSUB and I have been doing a bit of research via Peter's 4 very helpful CSUB tutorials. However, I do have a few outstanding questions:- i). Can CSUBS be called directly from hardware pin based interrupt, in the normal MMBASIC way - eg SETPIN RFM_INT,INTH,LORA_INT()? ii). I need to return the received data in a standard MMBASIC string array. Are there any reasons why this can not be achieved via the aforementioned interrupt based CSUB? iii). I need to access the standard MMBASIC SPI interfaces within the said CSUB. Given that there are various graphics device drivers around, my guess is that there is a SPI function available to CSUBS, but I couldn't see anything in CFunctions.h. Any help would be gratefully received. Also, any thoughts, ideas, advice on how to progress would be wonderful. Best wishes to you all. sawasdee01 |
||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 4139 |
My first thought is that your interrupt routine sounds way too big and thus also runs far too long. A way round this is commonly to do almost nothing in it but set one or more flags to signal to the rest of the program what needs to be done. You probably won't need a CSub at all that way, but if you do it won't be an interrupt one. John |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10580 |
i). there is one pin which can generate a H/W interrupt that CSUBs can link to using CFuncInt2. You will need to get the MM+ source to understand how to use it ii). Definitely do-able iii). SPI needs to be handled at the register level - can provide an example file if you need it |
||||
| sawasdee01 Newbie Joined: 23/12/2016 Location: United KingdomPosts: 33 |
A big 'thank you' to John and Peter, I am leaning towards a hybrid of both of your proposals. Assuming that I have got this right, I could just set a DATA_RXED flag to true in a standard MMBASIC sub, called via the same hardware pin interrupt as now (this approach has the significant benefit of not having to change the pcb design). I could then write a standard CSUB to pick up the the subsequent processing of the RXED data inside the main loop. Presumably, the same rules apply to needing to handle SPI at the register level(?). The only potential issue, is that there could be some latency while the main loop eventually makes its way to the CSUB. Is there some way of doing something like a 'call back', where I can tag on the CSUB to execute immediately after the return from interrupt? Best wishes. sawasdee01 |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4139 |
No callbacks as such, so you'll have to sort of create your own via a flag. Do you really need a CSub at all? Life's easier without and also if you stick to MMBasic you can post code for almost anyone to hunt through if you hit problems. John |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
+1 |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Just FYI: I am delighted with the performance of the MX470 based E-100 that I have implemented as a host controller for my CNC system but for my production design, I prefer to go "distributed" by using multiple MX170s. I just love the simplicity of this solution. However, I am a bit concerned about execution speed in certain applications and so, rather than resort to C coding, I will simply load-up that/those particular devices with Bypic. Bypic is no longer being developed but hey, it works and it is also interactive. In fact, it can be more interactive than MMBASIC if one decides to use multi-tasking because the command prompt is always available whilst the program is executing. Code is on page 3 of this thread  Edited 2020-08-11 22:29 by Tinine |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
