 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 1 of 7   |
|||||
| Author | Message | ||||
Dinosaur Guru  Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all Discovered this product as I was looking for a replacement for an 8254 counter board.(for which the local supplier wants $400 + gst) Basically I use Advantech CPU boards and connect boards to control mainly Weighing machines and Concrete batching plants. In the last few years I have progresed from ISA slot boards to usb boards, and currently I am using the UBW32 by Brian Schmalz, which may even be the same pic as the Maximite. I got them to modify the code, so that I could implement a Zero crossing detector to control voltage to vibratory feeders. Now seeing this board, and being very familiar with Basic (FB in particular)I am considering using it as a distributed controller, where I can connect it to the PC via usb. That brings me to my first question: Can I send commands to my basic program from my PC.? The next question relates to the 8254 timer. Is this board capable of counting pulses to a maximum of 1khz.? Hopefully I can set a count, then on completion set an output. The next question relates to the analog inputs. The spec does not mention the resolution.It notes the maximum voltage of 3.3 vdc. (10 bit ?) Also I don't want to buy the boards and assemble them, I need to buy them pre-assembled and tested. Regards Regards Hervey Bay Qld. |
||||
| rhamer Senior Member  Joined: 06/06/2011 Location: AustraliaPosts: 174 |
Don is your man for pre built boards. www.dontronics.com.au Technically you could use the USB to send commands to your program, but you need a terminal session (or your own software of some sort). Think of it as a remote keyboard. However Serial is coming soon and that means RS485 is possible which may be a better solution if you have lots of them to monitor. Not sure about the analog resolution, ill let someone else who knows the PIC32 specs answer that. Cheers Rohan Rohan Hamer HAMFIELD Software & Hardware Solutions Makers of the Maximite Expander. http://www.hamfield.com.au |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi. The PIC32 (and therefore the Maximite) has a 10bit ADC. The count inputs can count pulses at up to 200kHz (with a 10nS minimum pulse width). Currently there is no facility to be interrupted when the count reaches a certain number - but this would be a simple firmware change. Regards Gerard (vk3cg/vk3grs) Regards Gerard (vk3cg/vk3grs) |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all Thanks for the replies. The lack of Int on Count complete won't be a problem. If I use the board as a dedicated controller, then it can poll the count and set an output. The bigger obstacle is the Commands via usb. Rs485 is ok but I gather it's not here yet. Does anyone know when ? Regards Regards Hervey Bay Qld. |
||||
Keith @ Senior Member Joined: 19/06/2011 Location: AustraliaPosts: 167 |
Dino from the PIC32 Hardware Manual The PIC32MX5XX/6XX/7XX 10-bit Analog-to-Digital Converter (ADC) includes the following features: • Successive Approximation Register (SAR) conversion • Up to 1 Msps conversion speed • Up to 16 analog input pins • External voltage reference input pins • One unipolar, differential Sample and Hold Amplifier (SHA) • Automatic Channel Scan mode • Selectable conversion trigger source • 16-word conversion result buffer • Selectable buffer fill modes • Eight conversion result format options • Operation during CPU Sleep and Idle modes Keith The more we know, the more we know we don't know ! |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all Considering the board has no other a2d's on board, the 10 bit should have been obvious. With regard to the usb commands, it reminds me of what I did when I first started playing with Ethernet. I could send files, but couldn't get a packet into my program. Simply updating a file (via usb) may be a short term fix. But is the usb available during the execution of the Basic program? Can I copy a file to memory ? as the compact flash won't like frequent re-writes. Regards EDIT: The USB socket is for connection to a desktop computer. The Maximite appears as a virtual serial port to the bigger computer and anything typed onto this port will be used by the Maximite just as if it has been typed on the keyboard. Similarly, any output from the Maximite will be sent to both the video and USB outputs. This facility can be used to upload/download programs and data. What does that mean for me ? EDIT Again: Functional Summary Keyboard/Display Input can come from either a keyboard or from a computer using a terminal emulator via the USB interface. Both the keyboard and the USB interface can be used simultaneously and can be detached or attached at any time without affecting a running program. The Inkey$ command doesn't mention this, but does the above mean I can send a command via usb, and then A$ = Inkey$ will give me the command ? Anyway, I have ordered one, so will suck it and see. Regards Hervey Bay Qld. |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi. Geoff is close to releasing the serial code for testing - so serial should be available in the near future. As regards the statement above, the USB interface appears as a virtual serial port on the PC. Therefore, any program running on the PC that can read/write to a serial port can communicate to the Maximite. When a MMBasic program is running, any output (ie PRINT commands) will be written to the virtual serial port as well as updating the internal memory area that is used to send the VGA output. Similarly, the MMBasic INPUT commands (INPUT, LINE INPUT and the INKEY$ function) will read input from the keyboard and also data that is written by the PC program to the virtual serial port. So you can communicate with a running MMBasic program using the virtual serial interface. regards Gerard (vk3cg/vk3grs) Regards Gerard (vk3cg/vk3grs) |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all seco61 , that's brilliant. So, basically this can be considered a very cheap PLC. Looking forward to testing it. Regards Regards Hervey Bay Qld. |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all Reading more doc's I have one more question. I set a number of pins to create an Int on the rising edge. Then when I am handling the first Int, a second Int occurs. According to the Doc's During processing of an interrupt all other interrupts are disabled until
Now when I return from Int, is the other Int handled or Lost, because by now the Pin is Hi and there is no rising edge.
the interrupt routine returns with an IRETURN. During an interrupt (and at all times) the value of the interrupt pin can be accessed using the PIN() function Regards Regards Hervey Bay Qld. |
||||
haiqu Senior Member Joined: 30/07/2011 Location: AustraliaPosts: 152 |
Make your int routines extremely short and this should minimize the issue. Rob unzip, strip, touch, finger, grep, mount, fsck, more, yes, fsck, fsck, fsck, umount, sleep |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all haiqu, minimising the problem is not good enough. When you are counting pulses of a highly volatile / expensive liquid into a process then I have to find an alternative. Even if it means counting the pulses without Interupts. In some instance I can stagger the starting of these liquids, and thus prevent the problem. Regards Regards Hervey Bay Qld. |
||||
sparkey Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 819 |
i thought tat this would compare to a plc as i have stated in other posts technicians do it with least resistance |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi. I have had a quick read of the source code and the way the "interrupt on edge (cfg option 6 and 7)" works is as follows. After every MMBasic statement is executed, a check is done for "MMBasic" interrupts. (These are distinct from PIC32 interrupts). They are checked for in the following order: I2C interrupts Pin interrupts (from pin 1 to pin 20) Settick interrupt If an interrupt condition is found, the code will then execute the associated MMBasic interrupt routine. Whilst in the interrupt routine the interrupt check is bypassed. After the IRETURN statement is executed the interrupt check will be done again, starting at the beginning of the above order. The I2C interrupt and Settick interrupt conditions are set in "real" PIC32 interrupt routines, so that if one of these conditions occurs during a MMBasic interrupt routine they will still trigger the appropriate MMBasic interrupt routine when the check is done. However, the Pin interrupt conditions are only checked during the "interrupt check" routine. So if a pin rise/fall occurs duing a MMBasic interrupt routine, and returns to its original state before it is checked by the "interrupt check" routine, the condition will NOT be seen and will NOT trigger a MMBasic interrupt. The only way for the conditions to be seen (and there would have to be maximum frequencies and minimum high and low pulse periods to guarantee it would work) would be to change the firmware to do the check in one of the PIC32 timer interrupt routines, and store the number of times it has occurred since the MMBasic pin interrupt routine was last invoked. While this is relatively simple to do, it will tie up the timer interrupt with more processing which will reduce the MMBasic statement throughput a bit. I can make the change and submit it to Geoff (the "owner" of MMBasic) to see if he approves. Or you can choose to run a customised version of the source - it is open source so changes are allowed and welcome. Regards Gerard (vk3cg/vk3grs) Regards Gerard (vk3cg/vk3grs) |
||||
Bob Regular Member  Joined: 11/08/2011 Location: United KingdomPosts: 41 |
Gerard, If the interrupt condition on the pin is removed before the interrupt is serviced does the interrupt still occur (for example, if a narrow(ish) pulse is input)? It sounds as though the differentiation is done in the running programme, so that the probability of a pulse below some critical width being seen is less than 1, and depends on the width of the pulse and the interpreter statement execution time. Is this how it works? Regards, Bob Bob Dalley http://www.m0rjd.co.uk |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi Bob. Yes, your interpretation of how the current pin interrupts are generated is correct. The check is only done between "MMBasic statements" - and different statements will take different times to execute. Also, a statement that contains multiple MMBasic commands separated by colons (":") is still just one statement. The only exception to this is the PAUSE command issued outside of an interrupt routine (why anyone would put a PAUSE inside an interrupt routine I do not know) - in this case the interrupt check is done continuously until the pause wait time has elapsed. The pin check inside the interrupt check routine reads the values of each pin (defined as an interrupt on pin change) in turn (starting from 1 to 20) and compares the value to the value from the previous interrupt check. If the appropriate change has occured (ie high to low or low to high as set by the SETPIN command) the interrupt is then invoked. If not, the next pin (defined as an interrupt on pin change) is then checked. If an interrupt is invoked, when the check interrupt routine executes next it will start from the beginning again. And as previously stated, the check interrupt routine is not invoked during the execution of the statements in a MMBasic interrupt routine. So, as a pin change condition can only be detected in the interrupt check routine, if a pin change occurs and then reverts to its last read state before the interrupt check routine can check for it, the interrupt will NOT occur (hope that makes sense!) Regards Gerard (vk3cg/vk3grs) Regards Gerard (vk3cg/vk3grs) |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all Thank you for the time taken. I am not sure if I am going to repeat a question that Bob asked. 1.Int on Pin1 ---> Interupt Routine --> Pin2 Int ---> IntReturn 2.Pin2 is still High Will this create an Interupt ? My pulses will basically be 50% duty Cycle and not faster then 1 Khz, so relatively slow. This means that the pulse will definitely still be high when the IntReturn's. Edit: In fact Pin1 that caused the first Int will still be high. Regards Regards Hervey Bay Qld. |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
I will assume that you have the 2 pins set to interrupt on a low to high level change (SETPIN x,6). The answer is that it depends on how long you spend in your interrupt routine. And the time spent depends on how many statements and how complex the statements are. But to give an idea on the speed of statement execution, MMBasic will execute simple statements like c=c+1 at a rate in excess of 15000 per second. And more complex commands will execute in excess of 7000 a second (and these are fairly worse case with 4 PWM outputs running, the settick command operational and 10 pins being checked for level changes). If you keep your interrupt routines simple (eg clear a count and set a flag for example) then in the scenario you described you will not miss any pin change conditions. regards Gerard (vk3cg/vk3grs) Regards Gerard (vk3cg/vk3grs) |
||||
| Dinosaur Guru Joined: 12/08/2011 Location: AustraliaPosts: 311 |
Hi all Gerard the code will be very simple as it only needs to increment a counter. The code outside the Int will be more complex, but by the sounds of it, it will spend less then a mSec in in the Interupt routine. When I get the unit, I will test it and give you guys some feedback. Regards Regards Hervey Bay Qld. |
||||
| seco61 Senior Member Joined: 15/06/2011 Location: AustraliaPosts: 205 |
Hi. I have been doing some playing with 2 input pins fed from the same 1kHz signal, with a 20%, 50% and 80% duty cycle. Both were set to interrupt on a low to high transition. The interrupt routine just increments a counter. While it is possible (I can not guarantee though) that the 50% duty cycle was captured correctly by both interrupts, the other duty cycles were definitely not. I have done a rewrite of the pin change code so that the checking is done in a timer routine and updates a count every time the appropriate transition occurs. The new code will reliably handle 5kHz signals provided that the high and low states are at least 100uS. The check interrupt routine now checks for a non zero count and invokes the interrupt routine if this is the case. The count value is stored in the MM.PCNT psuedo variable and the count value is then zeroed. This ensures that when the interrupt routine for a pin is executed, if more than one transition has occurred the number that have occurred since the interrupt routine last ran is available in the MM.PCNT psuedo variable. This modified code reliably handled all my above test cases - and I did find that on some of the calls to the interrupt routines the count was 2. Regards Gerard (vk3cg/vk3grs) Regards Gerard (vk3cg/vk3grs) |
||||
| Bob Regular Member Joined: 11/08/2011 Location: United KingdomPosts: 41 |
Thanks Gerard, It's rather as I expected. It's a pity that the pins 11-14, which connect to the chip External Interrupts 1-4, have not been given 'special' treatment so that the chip's hardware interrupt system can deal with them "in the twinkling of an eye" rather than the much slower and far less predictable response from "software differentiation". Then these 4 pins would have 'instant' response to edges, even though there would clearly be latency before the interpreter would honour the action at the end of the current statement (or even after the 'n'th statement if several such interrupts occurred). This would IMHO be a very desirable enhancement and would serve to extend the functionality without changing the broad-brush behaviour. From your description of the sequential servicing of these interrupts it is also clear that there would be the possibility of interrupts from high-numbered pins never being honoured if frequent interrupts occur on lower-numbered pins. Pity it's not a 'round-robin' scheme or re-entrant check or something that might prevent this - obviously with some considerations of its own. Bob Bob Dalley http://www.m0rjd.co.uk |
||||
| Page 1 of 7 |
|||||
 Print this page |
