Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About AllanL5

  • Rank

Profile Information

  • Location
    Somewhere near Washington, D.C.
  • Interests
    PIC and SX microcontrollers, Robotics, Stamp and Stamp compatible controllers, PC's, Software Engineering, Science Fiction, Space, Education.
  1. The RC Servo motor people tend to use for these purposes (because they're cheap and simple to interface) have a simple interface signal. That is -- the signal is normally low. It has a 'high' pulse of from 1 mSec to 2 mSec duration, which specifies the desired position of the output shaft. 1.5 mSec being 'centered'. This signal is then repeated every 20 mSec to 50 mSec, to 'refresh' the servo electronics so they 'hold' the commanded position. And most servo's let you 'sweep' only 180 degrees using these pulses. Superficially, this does meet the requirements of a "PWM Signal", but it's kind of misleading to call this a PWM signal. Most "PWM Signals" are specified by percentage of time high and low, and are used for speed control of DC electric motors. The Servo motor wants specifically the signal explained above. Now, some people have "modified" the servo, by 'fixing' the feedback resistor inside the servo into it's middle position, and disconnecting it from the output shaft. Once this is done, a 1.0 mSec pulse causes the servo to spin continuously one way, a 2.0 mSec pulse to spin the other way, and a 1.5 mSec pulse to stop. However, once this is done, you lose the ability to command the servo to a particular position. The "modified" servo makes a very nice inexpensive and simple to interface robot motor. But to position it exactly you then need to add some external position encoder.
  2. You MIGHT use this on VC++ if you wanted to talk directly to the PC hardware registers. Note that under Win 2K or above the 'INP' and 'OUTP' instructions are PRIVELEGED -- you need a device driver to get around this. Otherwise, talking directly to a MEMORY location is a no-no. The Windows run-time and VC++ run-time control heaps of memory. If you talk to memory outside your process space you get a run-time error. Thus, using the C 'pointer' "*" operator, and the address-of "&" operator, are the way you do this sort of thing. The actual address is assigned and controlled by the language run-time and the OS runtime.
  3. Well, actually Pavel you CAN do this in 'C', as long as you properly wrap it in: #ifndef xxx #define xxx .. do stuff .. int MyGlobal; #endif This should define MyGlobal as an int only ONCE, no? If anyone else tries to #include the above file, 'xxx' will have been defined, and so the re-definition should be skippped, no?
  4. On reset, the hardware sets itself to 00, which is almost always wrong. A 'perfect' part would use $80, which puts the oscillator in the center of its 'range'. Most parts I've used are around $80 -- 7F, 7E, 81, 82, etc. You could start with $80, use the part to blink an LED, and 'tweak' the value to get a better value. And I agree with writing the number on the underside of the chip, BTW.
  5. As far as I know, only MPLAB programmer's actually protect the last two locations before programming. All others just erase the calibration value just before the first programming -- or use an MPLAB programmer like PICStart. So, if you want to use the calibration value, you'd better 'read' the chip first thing, write the value on a piece of paper, then program the PIC. The oscal is factory set by microchip during manufacture. Your programmer should maintain this factory set value by reading it back, programming the device, then re-writing it to the device. If your programmer doesn't do this, buy a different programmer! <{POST_SNAPBACK}>
  6. And -- did you create a 'project' for this? It doesn't look like it.
  7. Perhaps you gave the project a long name? As I recall, project names should be kept to 8.3 file naming format, if you are using MPASM 5.7 or below -- and probably BoostC, as well.
  8. With small PIC processors, address 3FF is supposed to hold a RETLW xx, where XX is a number from 00 to FF, which is a Microchip-calculated calibration value for the internal oscillator. Usually, I've erased this part of the chip by the time this code runs, so I simply hard-code an OSC_CAL = $xx in my code. The other approach, with MPASM tools (which don't erase that location when programming) will allow the user to not have to record the 'xx' value for each processor they program.
  9. I've created an array of CHAR in memory. I can put a set of characters into that array. Now, I want to 'pass' that array to another PROCEDURE, so I can output that set of characters in that procedure. How do I declare this? PROCEDURE MyProc(MyString : ??? ) VAR I : CHAR; BEGIN FOR I := 1 to 6 DO putchar(MyString); END; Is it "MyString : ARRAY OF CHAR"? "MyString: ARRAY"? "MyString: ARRAY[1..6] OF CHAR"?
  10. Neat, I was able to download the update. However -- when unzipped, I get a few files, which look like executables. Should I copy those executables into the SourceBoost directory? How then do I integrate the new compiler command lines into the IDE? Thanks, Allan.
  11. OK, C2C is set up for really-really small processors. We're talking 390 bytes RAM Maximum, and 8K words of flash rom. They have not implemented all the 'Standard C Library' stuff that you are used to from the big world. However, there's nothing stopping you from implementing your own string handling. Just be aware that C2C has those limitations.
  12. I think it's supposed to be 'Unary'. A 'Unary' operation is one that takes a single operand -- like negating a value, the negative sign only operates on the number following it. The error message probably indicates an extra or missing character somewhere in your file, which is being interpreted by the compiler as an operand where it does not expect an operand.
  13. The D'10' syntax is 'old' MPASM, meaning the '10' inside is a decimal number. It's only for 'literal' numbers though, so it should not have put the D'...' around the variable name. It's needed because the default can be changed, and apparently the default for C2C code is hex -- H'...'
  14. And, the: #ifndef MYFILE_H #define MYFILE_H .. .. code .. .. #endif Is called a 'Header Wrapper'. It's used so you don't get 'Duplicate Definition' errors, should the same header file be #included by two files. It's not really so you CAN'T compile the code twice, it's to insure that the code WON'T be compiled twice (which would lead to lots of duplication errors)
  • Create New...