Jump to content

Dave

Administrators
  • Content Count

    2,046
  • Joined

  • Last visited

Everything posted by Dave

  1. If you provide a complete but small program that demonstrates this problem I'll take a look. Regards Dave
  2. What display are you talking about exactly??? Regards Dave
  3. Nothing received, where did you send it? Regards Dave
  4. IanM, Appologies. This was a mistake on our part, a batch of the Maplin Standard License versions were incorrectly labelled. We have a list of the serial numbers of those CD packs affected. We offer a free upgrade to the Full license to anyone who purchases one of these CD Packs. Please send an email with your name, the complete product serial number, the activation key name and activation key to support@sourceboost.com. Once we have checked the serial number we will send you an upgraded key. Regards Dave
  5. Jamie, Recursion will work but strange things may happen if you use function arguments and local variables as these will be modified on reentry as the same software stack locations are used (the software stack is static). It maybe that your code correctly handles the reentrency issues, so creating an error during the project build for this condition may not desirable. Regards Dave
  6. Benj, Glad this issue is resolved and that it turned out not to be a compiler problem :-)I have received the ECIO modules, and have added them to my stock as I don't now need them for test. If I had know what you where going to send exactly I could have used one out of my stock - never mind. Regards Dave
  7. This would suggest that if the two semaphores in above example were being waited on by two different threads, then only one of them would be moved to the wait queue? Or has the behavior chanced since this description was written? Looking at the source code its looks like the documentation is out of date. I remember once trying to implement at ultra lightweight SysSignalSemaphoreIsr function, but this caused too many other issues. Regards Dave
  8. Both calls to SysSignalSemaphoreIsr(); are significant as they affect different semaphores. Even if they both operated on the same semaphore they would still be significant because the semaphores are of a counting type, so two calls to SysSignalSemaphoreIsr(hSem1); would cause the hSem1 value to be increased by 2. Regards Dave
  9. Hi All, It goes like this; at SourceBoost Technologies we don't have this target device to see the problem and we don't have a great deal of USB experience either. We will help where we can. Normally we help when someone provides code examples that do not work because the compiler has generated erroneous code Regards Dave
  10. Morlan, No, you bought a compiler license and thats what have the key for. Regards Dave
  11. Also Note: Its best to wrap code in code tags in the forum post to preserve the formatting. Regards Dave
  12. What aspect of the compiler do you think is wrong ?? Regards Dave
  13. Sounds reasonable, depending on the type of op amp used you could use much higher resistance values to reduce the loading effects. The assumption is that load of the potential dividers connect to each end of the shunt is insignificant, so as mentioned above you may want to pick high resistance values. I would typically want the current flowing down each divider to be 1/1000 of the current that would be flowing through the shunt. Depends on the range you want to cover and how accurate you want it to be. Regards Dave
  14. Here are a couple of pieces of code to do the job. One counts all edges and so gives a higher resolution. bit a_prev; int encoderCount; void TrackEncoderLowRes() { bit a = portb.4; //channel A bit b = portb.5; //channel B if( a_prev == 0 && a == 1 ) { if( b ) encoderCount--; else encoderCount++; } a_prev = a; } bit a_prev; bit b_prev; int encoderCount; void TrackEncoderHiRes() { bit a = portb.4; //channel A bit b = portb.5; //channel B signed char toAdd = 0; if( a_prev == 0 && a == 1 ) // A rising edge { if( b == 0 ) toAdd = 1; else toAdd = -1; } if( a_prev == 1 && a == 0 ) // A falling edge { if( b == 1 ) toAdd = 1; else toAdd = -1; } if( b_prev == 0 && b == 1 ) // B rising edge { if( a == 1 ) toAdd = 1; else toAdd = -1; } if( b_prev == 1 && b == 0 ) // B falling edge { if( a == 0 ) toAdd = 1; else toAdd = -1; } encoderCount += toAdd; a_prev = a; b_prev = b; } I hope that helps. Regards Dave
  15. Tim Zim, Assuming your shunt is on the positive side, connect a high resistance potential divider on either size of the shunt to ground (to scale down the voltage into the range of your monitoring circuit). Connect the potential dividers into a differential amplifier (instrucmentation amplifier configuration). Use this output to feed into your analog input. You can now also have your voltage measurement potential divider connected, no need for any isolation. I hope that makes sense Regards Dave
  16. An optical rotary encoder won't need any debounce. Debounce in this case would only lead to limiting the maximum input frequency that can be processed without missing pulses. Regards Dave
  17. What do you want to know, speed or position ?? One of the key things here is you need to detect on which input the rising or falling edge occurs, to do this you need to keep the last states For position you would need the following (this is pseudo code to demonstrate the logic not real code):. A_rising_edge = (A_prev == 0 and A == 1); A_falling_edge = (A_prev == 1 and A == 0); B_rising_edge = (B_prev == 0 and B == 1); B_falling_edge = (B_prev == 1 and B == 0); A_prev = A; B_prev = B; if( A_rising_edge and B == 1 )then pos = pos + 1; if( B_rising_edge and A == 0 )then pos = pos + 1; if( A_rising_edge and B == 0 )then pos = pos - 1; if( B_rising_edge and A == 1 )then pos = pos - 1; I hope that helps. I have never actually done this, but I just worked through the logic Regards Dave
  18. schneiderj, BoostLink file is encrytped as part of the licensing control of the software. Detection as malware or a virus is a false alarm! Regards Dave
  19. russ_hensel, The CLOCK_FREQ is used by the linker to give correct results from the software delay delay functions. So you need to set it to the processor clock rate not a perihperal devices clock rate. Regards Dave
  20. philb, The result do look somewhat odd. It was never intended that a user would access Int1Context in there code, so use of the linker internal data flies under the radar.To do what you want to do reserve you own location for interrupt context storage in an unbanked area of memory eg: char myInterruptContext[ 4 ] @ 0x10; I'll add this to the bug list so that we prevent access to these internal variables. Regards Dave
  21. Looks like it could be an inversion issue, the bits match when bit shifted and inverted: 0x39 = 00111001 0x63 =01100011 Regards Dave
  22. It won't help if you mungle the name as the mungling is done by the linker during the linking phase rather than the compiler.The only option I can thing of is to place the restart function at a fixed address and do an asm goto a fixed address. Regards Dave
  23. drumanart, Some changes of the format of .obj and .lib files mean that they are not compatible with older versions.You need to make sure that all .obj files in the project are rebuilt with the lastest version compiler. Also make sure that any libraries in the project are the latest supplied versions, and not pointing at an older version/copy of the previously supplied libraries. Regards Dave
  24. JRJ, Which part of the manual are you looking at?? int x; x = 19%10; // give a result of 9 This limitation is because PICs don't have a stack like other processors. This means that local variables are create on a software stack (determined when your code is linked), this makes functions non-reenterant. So any function may cause corruption problems if called in both main and interrupt threads. Regards Dave
  25. Use linker command line option -hexela as documented in the BoostC compiler reference manual. Regards Dave
×
×
  • Create New...