 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 : Newbie
  Page 5 of 7   |
|||||
| Author | Message | ||||
Dinosaur Guru  Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all Gerard, I had to add one line 49 Dim S(6) But other than that it worked straight away. The only "error" is that the response Format$ replies as: 1,12345,0f,OK There were 5 locations where I changed "%1.0f,OK" to "%1.0f";",OK" At this stage I have no idea how fast it is, so will test again with 3 simultaneous counters.At the moment checking with one counter, and turning sig gen off when the count is over target. Then a second or so later it quits to step -1. You are right about being hard to read. I may keep 2 copies, with one commented and the other not. Once again many thanks for your effort, and a side affect is that I am getting to know all the quirks. Regards EDIT: PS It doesn't like "No EOF" ie: extra line feed after last line. Regards Hervey Bay Qld. |
||||
| seco61 Senior Member  Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi. The missing Dim S(6) must have occurred when I was cleaning up the comments ready for posting - needless to say it is in my code at line 40. I do not understand your issue with the format$ statements - they all print correctly here..... Regards Gerard (vk3cg/vk3grs) |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Ahhh... Now I can see the issue with the Format$ - for some reason when I have posted the code the website appears to have added an extra blank between the 1. and the 0f. Eg: Format$(S(i),"%1. 0f,OK") when it should have been Format$(S(i),"%1.0f,OK") And looking through the posted listing I can see some other "randomly" inserted spaces..... Maybe I should just put the code on my website... Regards Gerard (vk3cg/vk3grs) |
||||
Bob Regular Member  Joined: 11/08/2011 Location: United KingdomPosts: 41 |
Hi, In your example you say that you used a 2kHz pulser, but your measurements all show in excess of 3000, or is this just the accumulated count over a period of time? In any case, bear in mind the priority of interrupting inputs, with pin 1 being highest, etc. This can affect simultaneous input changes, since if the trigger condition has "been and gone" before the priority allows it to be serviced then it will be missed. I didn't test with >1 input interrupting, so this was not visible in my own results for max clock rate, but it is a definite consideration. The input must have both high and low states 'long enough' to be sampled by Gerard's code in order to be recognised. What is 'long enough' depends on the high & low periods of the inputs and their hierarchy in the priority scheme. I would have expected that, in your case, the signal on input 1 would be best represented, with the signals on the higher pins being progressively missed, but this doesn't seem to be what you saw. I'll try to set up something similar today. Regards, Bob Bob Dalley http://www.m0rjd.co.uk |
||||
| Bob Regular Member Joined: 11/08/2011 Location: United KingdomPosts: 41 |
Ah, Dinosaur, sorry, the bottles take a while to warm up to decent emission these days... With Gerard's latest code the maximum rate for a square-wave is 5kHz, both by calculation and from my own verification. I.E the input must be high for at least 100us and low for at least 100us in order to be sampled by the interrupt routine. But if several inputs are interrupting, then it all changes. In order for ALL the inputs to be sampled then the input rates must be less. If, for example, two inputs have the identical signal then each must be present for 200us each way to guarantee being sampled, etc, so for 6 simultaneous identical inputs the maximum frequency (if square-waves) would be 5/6kHz, or dropped events can occur. So your 2kHz square-wave (?) input would be OK for 2 inputs but not for more, it seems. However, I still can't explain why Input-1 didn't grab all the attention. I'm sure there is a simple explanation (if only my cathode were not losing emission...). Regards, Bob Bob Dalley http://www.m0rjd.co.uk |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi All. The firmware should capture all the input transitions up to around 5kHz, though depending on how long the interrupt routines are, and how often they are invoked will affect the value of MM.PCNT when read. I will attempt to do some tests with 6 inputs all fed from a source of 1 to 5kHz (it will have to be the same source though until I finish a new connector for my Maximites - then I can use the PWM outputs of one to drive the others inputs). Regards Gerard (vk3cg/vk3grs) |
||||
| Bob Regular Member Joined: 11/08/2011 Location: United KingdomPosts: 41 |
Hi Gerard, I see that I misunderstood; I guess the ISR sees every pin's changes of state and updates MM.PCNT for them all, when necessary, on each tick. So this means that no interrupt inputs should be missed so long as the hi/lo periods are all within the sampling requirement. But as I understand it, the interrupts (as evidenced by a non-zero MM.PCNT for any input) are serviced in a simple order, always starting at 1 if it has a non-zero MM.PCNT, so is it quite possible that the higher pins will never be serviced at all if the input on lower pins occurs at a rate that exceeds the target subroutine execution time? So with a 2kHz interrupt rate on all of 6 pins, only the lowest numbered will 'ever' be serviced if it's service routine takes >0.5ms? The only opportunity to examine MM.PCN is in the service routine, since it is filtered by pin number (hence each pin's service routine sees a different original MM.PCNT specific to that pin)), so unless an interrupt occurs for pin 'n' then its MM.PCNT is not visible. If the priority mechanism means that pin 'n' doesn't get a look in, the only way to see it's MM.PCNT is to stop the inputs and wait for the interrupt to happen. Presumably MM.PCNT is a 32-bit integer (?) so what will happen after 2^32 unserviced transitions? Does it recycle? OK, a count of 4E9 would take a lot of seconds at 5kHz... Or have I misunderstood all that as well :-) Regards, Bob Bob Dalley http://www.m0rjd.co.uk |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all Bob, yes using square wave, and the count is simply an acccumulation until I switch the sig gen off. But in this method you simply can't gurantee which counter gets the first interupt, or last one when I switch off. Today I will try to add a small counter to the interupt routine, and count the number of Int in the MM.PCN for each counter. Then dividing by the number of entries will give me average Int happening during the servicing of another Int. It will also show the difference in code speed between my older "Spread out" code and Gerard's optimised code. I really need to know what difference there is. Then turn off printing to see what that does. Regards PS:Bob ,my bottles never warm up, I do. But then mine have this smooth malty liquid inside. Regards Hervey Bay Qld. |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all There was something I didn't understand when running pulses. I changed the code so that when the target count is complete, it would not wait for stable count but just reset the step to -1. (Just to see the reaction time) But when I wasn't getting any print statements, I realised that regardless of the "Step" for each counter, the pins are still set to interupt on a rising edge. If you have three pins interupting at 2khz, there simply isn't enough time to do anything else. Now in the real world this shouln't happen unless a liquid is leaking. Just an observation Regards EDIT: Test results. Same pulse on 3 counters. Counter 1 got to Int Routine 13273 times for a count of 13275 Counter 2 got to Int Routine 8213 times for a count of 13269 Counter 3 got to Int Routine 1 time for a count of 13275 Well. that proves Gerard that your Timer MM.PCNT is working correctly. It was busy with Int Counter 1 or 2 every time Counter 3 wanted an Int. Once again, in the real world this won't happen, but if on occasions it does,(and it will for a few pulses)) then the accumulated count in MM.PCNT has captured all the events. Ignore the count difference, as this test is not ideal. Regards Hervey Bay Qld. |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi. I am setting up to use a 2nd Maximite as the test device for this system. I have modified the firmware to support 10 PWM outputs - that way I can use 6 for the test. I need to check what effect adding the extra PWM output capability has on the throughput - but I can not do that until I get home tonight. I have also modified the program so that it only activates the pin change interrupt when the process enters step 3, and disables them at the end of step 6. I have placed the latest program on my web site (to avoid those random spaces) and I have also placed a copy of the test program I will be using as well. Regards Gerard (vk3cg/vk3grs) |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi All Gerard, do I need a firmware update ? I am getting an error on the test program. The SetPin 1,10 I think is the problem. 30 setpin 1,10,a,0 Error line 30: Invalid configuration value Regards EDIT:However the updated program for the counters only works well. Have just updated the firmware again, but still no luck. The Nbr 10 for Setpin is the problem. Regards Hervey Bay Qld. |
||||
| Bob Regular Member Joined: 11/08/2011 Location: United KingdomPosts: 41 |
Hi Dinosaur, I had very similar results; the total was correct but only the lowest 2 pins interrupted at all whilst the input was present. At anywhere near the top whack even for one pin the programme never managed to do anything else but service the interrupt. This clearly shows the priority mechanism at work, but also shows that interrupts such as this can lock out any other action! I guess that if the interrupt line statements take 0.5ms to complete then at 2kHz, by the time the first interrupt has returned there is another from the same pin waiting. Thanks to Gerard's MM.PCNT the inputs will be counted, but might never be seen by the programme! I guess that if that sort of rate is exceptional then it may be OK, but it is certainly a consideration when using pin-interrupts! Caveat emptor! They may not be missed, but if it locks the programme forever busy servicing them it may not be what was expected. Regards, Bob Bob Dalley http://www.m0rjd.co.uk |
||||
| Bob Regular Member Joined: 11/08/2011 Location: United KingdomPosts: 41 |
Hi Gerard, Does this mean that the first 2 input edges are counted but no interrupt line execution occurs? This would be a problem in lower speed use of the pins, which although not what we have considered is probably the major use. I expect I have misunderstood 'step 3' and 'step 6'. Are there any other ways, such as for example 'disabling' and 'enabling' the interrupting action (in much the way that the micro itself allows) so that interrupts can only cause the service line to be called at certain times? I can see this being no use if the programme is blocked by the execution of interrupts, unless they can be disabled within the service routine line and only enabled later (not after IRETURN, but by the main programme). Not very clearly explained, sorry! Regards, Bob Bob Dalley http://www.m0rjd.co.uk |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi Bob. The step numbers refer to the "state machine" values as initially defined by Dinosaur. I have updated the the 2 test programs (Master & Slave (DUT)) so the above links now have the latest programs I am using to test with. I have unrolled the FOR loop and also used discrete variables instead of arrays. I have the 2 Maximites connected via the 26 way I/O connectors (with 24 of the lines being connected - I cut the 3.3V and 5V wires in the 26 way cable). What I am finding with my testing is that with 6 signal sources at 500Hz and the start commands issued by a terminal macro (so they are issued very fast) that after 5 have kicked off the system then becomes very busy handling the interrupts and does not process the last comand (in the input buffer) until one of the counts has finished. With the signal sources running at 1000Hz, 3 are kicked off and the remainder are kicked off as processes come to completion. However, All the counts are correctly processed and the final count values are the target ones. This indicates that the interrupt routines are handling the test for target value and raising the stop output line in under a millisecond - so over all a reasonable result. And the test Maximite (the DUT) is responding to the stop signal and stopping the appropriate PWM output also inside of a millisecond. And this is with a different version of the firmware that supports 10 simultaneous PWM outputs (with this firmware, the baseline performace is 2% slower than the firmware with just 4 PWM outputs). What needs to be known is the expected pulse rates for the 6 inputs to determine if the firmware in its current state would be suitable. Also, the current maximum target value is 99999 - is this sufficient? Regards Gerard (vk3cg/vk3grs) |
||||
| Bob Regular Member Joined: 11/08/2011 Location: United KingdomPosts: 41 |
Hi Gerard, I understand the states now, thanks. Understood about the maximum input rate for simultaneous interrupts. ISTR that the approximate execution time for a BASIC statement is 0.2 to 0.5ms. If the interrupting pin's target address holds what must be the shortest statement such as x=x+MM.PCNT : IRETURN Then it will take about 0.4 to 1ms. Immediately after the IRETURN it will be able to see the next interrupting condition, so any interrupt condition that has occurred in the meantime will cause another interrupt call etc ad infinitum. So I don't think that the 2% reduction in speed of your test-version with 10 PWM is what matters; it is simply that the interrupts can (singly or collectively) arrive more rapidly than they can be serviced, which means (just as it would at the machine level for overfast interrupts) that nothing else can/will get done. But this is a 'fact of life', the only way to deal with it is to either reduce the collective input interrupt rate or to have a way in which to 'disable interrupts' (not a lot of good if it doesn't get executed though). It's a 'feature' not a 'bug' IMHO. The inputs successfully count the events (up to 99999 - how long is a bit of string!) and don't lose track; they do interrupt as designed. There is no real alternative to letting a BASIC line deal with the interrupt, so unless there were some cunning way of throttling the interrupts there is bound to be a rate that blocks the programme. I have two "idle man's" suggestions for possible changes: Just as a 'hopeless suggestion' (my best sort), would it be possible to code things so that every time an IRETURN from the service routine line (in BASIC) occurs, one (or 'n') further BASIC statement is executed before the next interrupt is honoured? That would be a possible way of ensuring that the main BASIC programme can continue to run, albeit rather crippled... The problem of not seeing 'higher' interrupts is due to the simple priority scheme; a (maybe easier than the previous) suggestion that might be possible is to service the interrupt of that pin with the highest MM.PCNT value? This would impose a form of priority that would service the currently most needy pin, rather than a fixed order. It would avoid the problem of higher-number pins never getting a look-in. All in all, an interesting side-effect of making the interrupters respond better! Regards, Bob Bob Dalley http://www.m0rjd.co.uk |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all Out of the office today, but some quick comments. The Largest number of counts is 1000 Litres x 25 Counts per litre. There will only be two operating at any one time.(even though they have the option of 6 different liquids) Just as a 'hopeless suggestion' (my best sort), would it be possible to code things so that every time an IRETURN from the service routine line (in BASIC) occurs,
Bob, I think that would defeat the purpose of an Interupt.
one (or 'n') further BASIC statement is executed before the next interrupt is honoured? That would be a possible way of ensuring that the main BASIC programme can continue to run, albeit rather crippled... Am I right in assuming that the reason this PIC is so slow in handling Int, is that we are running Interpreted Basic ? I wonder if I re-wrote it in MikroBasic if it would significantly increase the speed. Regards EDIT: Also the maximum rate is 1Khz. Regards Hervey Bay Qld. |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi. I have done quite a few tests with my Maximite test rig using outouts running at 1000Hz. With only 2 operating at one time (with a target of 25000 - ie 1000 litres) I get regular 2 second updates of the current counts and the finishing value is either 25000 or occasionally 25001. That final count is reasonable as there is always the possibility of being sent the halt request just as a count transition occurs. As regards the speed, you are correct in that running an interpreted program takes time to interpret each command. It is a trade off with not having to precompile. However, there are quite a few things that can be done to the interpreter to speed up it's processing speed. And I am sure some of these will be implemented over time. The current interpreter is only in its early days and a I suspect that there has been more effort placed on functionality then on performance. This is to be expected - and the developer (who has done a great job in writing it from scratch in a very short time) has been enjoying a wonderful holiday around Australia for a large percentage of the time since its release (and is still finding time to work on it - my wife would not be so understanding!. However, even in its current form it would appear to fulfill your current requirements. Regards Gerard (vk3cg/vk3grs) |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi All Gerard, the improvements you have made aince my first post on this subject, have made it worth while. Because the PC has control over when the Liquids start, I can prevent a third liquid starting to early. The only danger even with 2 liquids, is that when the target count is reached on either,that the pump gets turned off. For that to happen, the non-interupt code has to get atention. The 8254 timer chip has Interupt on Terminal Count, which sets an output (Stop) as soon as the count is complete. Because that happens on a separate board, the PC application could have been ended, yet it will still stop the pump on terminal count. I suspect that the timer's in the pic don't allow that kind of operation. However, I will thoroughly test the reliability before I commit, but in the meantime I am ever so greatfull for your participation. Staying with MMBasic is the preferred option, as the unit is complete in it's functions, such as kbd vga and usb, and normally my code for distributed controllers is not that Time critical. Regards EDIT:I have been keeping my "non-optimised" code to compare with your code, and some of the things that will improve further are ; Not printing every 2 Sec's but instead allow the PC to poll for data. Don't enter the pulser state machine for any counter that has a Step = -1 Would love to Turn the vga , kbd off once installed. Regards Hervey Bay Qld. |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
But I do turn off the pump in the interrupt routine.... And the code checks for -1 at the beginning and skips to the next channel if true... Regards Gerard (vk3cg/vk3grs) |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi All Yes, but if the interupt never get's serviced,(or to late) then the pump doesn't get turned Off.If your timer created an Int (or set an output) when terminal count was reached, then it would be perfect. I didn't check your code before making the -1 statement. Regards Regards Hervey Bay Qld. |
||||
| Page 5 of 7 |
|||||
 Print this page |
