 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 : MM Cfunctions for Interrupts
| Author | Message | ||||
| sawasdee01 Newbie  Joined: 23/12/2016 Location: United KingdomPosts: 33 |
Hi All, I am using MM+ for a RF project, which entails the use of FSK/Lora chipsets, connected to the MM+ via the SPI bus. As part of this project, I have written a receive interrupt routine in MMBasic for handling the data incoming from the RF chipset. Because my MM+ board is talking to several Nodes, it is necessary for the receive interrupt routine to complete rapidly, otherwise it takes too long to get round all of the Nodes. Using every optimisation that I can think of, I have achieved a receive interrupt routine time of approx 30 mSecs using 100% MMBasic. Ideally, I would like to get this down to 10 mSecs and I suspect that Cfunctions may be the 'way to go'. Having read through various CFunction posts, I have a few questions and I would be very grateful indeed for any help that can be given. Ideally, I would like to use a hybrid approach, where the CFunction receive interrupt routine just deals with getting data out of the RF chipset and stuffing it into a buffer for later processing in MMBasic. ie all of the OPEN SPI, getting data transmitted over RF, etc stuff would continue to be written in MMBasic. - Does MMBasic support this approach? - For instance, if I opened the existing MM+ SPI2 in MMBasic, how could I pass the handle to the CFunction interrupt routines? - My receive interrupt routine uses a hardware interrupt line coming from the RF chipset. Would I still be able to use the MMBasic SETPIN RFM_INT,INTH,LORA_INT() to trigger my new CFunction interrupt routine, or would I have to handle every aspect of the interrupt inside CFunctions? In general any thoughts, help, advice on the above would be very gratefully received, as would any 'out of the box' thinking. For instance, I have considered moving to a MM Extreme or using a small PIC24 co-processor to act solely as a dedicated network controller. Although I am an infrequent poster, I am an avid reader of the Backshed Forum, so many thanks for the wonderful posts and best wishes to all. Sawasdee |
||||
panky Guru  Joined: 02/10/2012 Location: AustraliaPosts: 1114 |
Hi Sawasdee, Have a read through the info about SPIPort.pdf in the Embedded C Modules folder that is included in the MMBasic zip file. With this, you may be able to create a number of pseudo SPI ports as CFunctions and using the code examples, upon receipt of an interrupt from any LoRa module, invoke a CFunction to open and read the data from the interrupting node. I am not sure if you can have multiple CFunctions with the same code but different names ie. CFunction ReadSPI1% ..., CFunction ReadSPI2% .... etc. If not, then you would have to have one CFunction but pass it different pin numbers for whichever node you are servicing. The only down side is that it will use up 5 digital pins for every node, namely a MISO,MISO,CLK,Enable and Interrupt. Hope this gives you some ideas. Perhaps you could expand on how many nodes, how much data each node sends back etc. etc. Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
What you want to do is very do-able but you have a lot of learning to do. The key to your requirement is that the hardware interrupt must be connected to pin RPC3 (pin 8 on 100-pin, pin 12 on 64-pin). Cfunctions.h includes a hook to allow you to link code into the H/W interrupt routine for this pin. You can do all the setup in Basic and the interrupt code could then read from SPI and buffer the output into a Basic variable (integer array is normally best) |
||||
| sawasdee01 Newbie Joined: 23/12/2016 Location: United KingdomPosts: 33 |
Hi Doug and Peter, A big 'thank you' for your thoughts and advice on this item. I think that I will have a shot at the approach suggested by Peter first as, if I can make it work, it seems to retains the purity of the existing MM+ SPI hardware and software model. However, Doug's approach also seems to be an excellent solution, as it very neatly sidesteps having to worry about interference with the existing MMBasic SPI. Also, my guess is that, if I didn't use the SPI OPEN command, I could use the very same hardware pins that I am using today. So, as there is a every chance that I am not clever enough to use the interrupt hooking approach proposed by Peter, I would also be very happy to create a bit banged SPI using SPIPort, as an alternative solution. Peter, I have had a quick look at CFunctions.h and the only Macros / API addresses that I can find that seem to relate to the linking of interrupts are CFuncInt and CFuncInt2. My guess is that the CFuncInt macro is probably where I should be heading and then I need to read the Interrupt Status to determine whether the interrupt originated from the SPI. Is this the correct approach? Best wishes. Sawasdee |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
Have a look at this project . It shows how I use CFuncInt2 (this is the correct hook) to trigger a timed pulse. I've attached the complete MPLabX project to help get you going 2018-08-06_194034_pulseit.zip |
||||
| sawasdee01 Newbie Joined: 23/12/2016 Location: United KingdomPosts: 33 |
Hi Peter, Many thanks for this. I have a full colonoscopy and upper GI scheduled for tomorrow am and I took the 'nuclear powered' laxative about 90 minutes ago. As I have never been great at multi-tasking, I am going to sign off for now. Once again, a big thanks to you and Doug. Sawasdee  |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
The colonoscopy is OK. It's when they decide to band a few hemorrhoids that the fun begins. Good luck. Jim VK7JH MMedit |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
