 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 : Fast interrupt service: Cfunction?
| Author | Message | ||||
| jsand Newbie  Joined: 02/07/2014 Location: South AfricaPosts: 15 |
Hello All, I've been using the 'standard' uMite (PIC32MX250F128B) for a while now, using MKI v4.5. The MMBasic interrupt service just is way too slow in latency for this job I'm engaged in. I have a 107kHz clock coming in on PIN(16) where it is config'd as SETPIN 16,CIN to count pulses coming from an external adc - there are 4x of them all running off the same clock and I need to read the lot. Each adc has a \busy line that allows me to find the output value by counting the pulses during busy HI. Well and good. When I interrupt the mite on the leading edge of busy HI it takes a long time to service the job, and again when the line goes LO I have to service it again to get a valid count value. There's a large loss of accuracy due to the latency and it varies a lot too. Something close to a quad encoder function is needed. Is it available anywhere? I've been using the uMite to avoid the pain of C and of trying to keep away from spending my life becoming a MPLABX guru too. I have written a huge amount of MPASM assembler over past years and I know it could do all this easily. I just don't want to repeat the process for this project where this is the only fast requirement in it, all the rest is floating point arithmetic and char LCD, I2C which I have already cracked well. Any ideas or suggestions out there? rgds, John Lost in darkest Africa. |
||||
| WhiteWizzard Guru  Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Hi John, If I have understood you correctly, you are trying to count 107KHz pulses while a BUSY line is high? And you have four sets of these you are trying to count. Could you not have each ADC output AND'd with it's BUSY line and feed the AND output into the MM. Then the MM will only count the required pulses (i.e. while BUSY is high) and that will eliminate any latency mis-count. In the meantime, feed the BUSY to an INTL, and simply read the counter value reached, store, it, then reset it it to zero ready for the next time it sees a High-to-Low interrupt. I may have misunderstood your requirement but from my interpretation this should work just fine  WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| jsand Newbie Joined: 02/07/2014 Location: South AfricaPosts: 15 |
Hi WW, Thanks for this, appreciate your attention and reply. The 4x ADCs are Maxim 7135s and were built into an instrument by myself around 1990. Data was read into a horrible all-parallel glue logic board then shuffled into an Epson PX4 computer (C/PM - those were the days!) The PX4 has collapsed so the uMite is brought in to bring the whole thing back from the grave. I have a 4x20 LCD with I2C -works nicely, a panel printer and a few buttons to think about. The only problem is reading these ADCs fast enough. Maxim actually suggest exactly what you came up with, ANDing the /busy line with the clock then reading the counted pulses. Let's see if I can do that with 4x INTs, maybe an external AND gate etc. TTYL rgds, John Lost in darkest Africa |
||||
| jsand Newbie Joined: 02/07/2014 Location: South AfricaPosts: 15 |
Hi WW and all, I'm still hitting problems with this scheme: (a) My uMite is already built, filled up with pins allocated etc., almost no pin space left. (b) The idea of adding an AND gate for each channel would no doubt work but would need 4 counter pins _and_ 4 INT pins. These exist on the uMite but two of the countable pins are also I2C SDA & SCL. I need I2C for other stuff so that's hard. Seeing as I'm a great fan of I2C I'm having a look at the various NXP etc., peripheral chips out there. Maybe one of them can do it one shot, gated counting. Hope to report back later on. YMMV rgds, John Lost in darkest Africa |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1094 |
John, Do you have access to the analogue inputs you want to sample? If so, would replacing the Maxim's with something like a single LTC1863 8 input ADC chip with SPI interface work? That way you could sample at whatever rate you choose doing it all entirely in MMBasic. Doug ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| jsand Newbie Joined: 02/07/2014 Location: South AfricaPosts: 15 |
Hi Panky & WW, Thanks for the suggestion about the LTC1863, I am reluctant to replace the 4x Maxims because I would then lose the span adjustments for them all. With some care that is surmountable so it's an option, have you any experience with a similar part using I2C? I am now looking at using a PIC 16F84A to read the clock line + 4x /busy on RB4 change-on-interrupts. It can read the clock counts on each busy HI period store each count value then gracefully send each on to the uMite. This is a part I have used in the past, have in stock etc., and am familiar with MPASM & MPLAB 8.xx. Anyway I'll not commit till I've had a goood look at using a more modern ADC. rgds, John Lost in darkest Africa. |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1082 |
If you have a choice, don't use a '16F84A. Use a '16F627A instead. More useful peripherals, internal oscillator, cheaper, etc. If you have a choice. ;-) Visit Vegipete's *Mite Library for cool programs. |
||||
| jsand Newbie Joined: 02/07/2014 Location: South AfricaPosts: 15 |
Hello Vegipete and all, The 16F84A is falling out because there are far better parts around now. 16F627 doesn't have an I2C port but the 16F1826 _does_ & that makes a big difference to me. each costs <US$2.00. The ADCs in contention are:- (a) Texas ADC128. 12bit, 4ch diff, I2C, TSSOP (b) Linear Tech LTC2309. As above. (c) Microchip TC514. 4ch diff, uC controlled resolution up to 17bit, comms via 5 digital lines, no I2C. (c)is the most expensive overall and requires the extra uC but has the best flexibility. I'm more likely to succeed at the first shot with it even when I have to do the extra asm programming etc. for the 16F1826. I 'could' do all that in the uMite PIC32 but I'd be painting myself into a corner with speed/resolution tradeoffs. The costs don't matter for a one-off job where a brand new instrument is a shake-down in the order US$40K! rgds, John |
||||
 Print this page |
