Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by AllanL5

  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)
  15. You get the warnings because the C2C compiler is uber-intelligent. It KNOWS if you never call a function, it doesn't have to include it in the output code. So, it doesn't include it, but it issues this warning that there is source you've included that SHOULD have been compiled, except it is never used, so it ISN'T being compiled. There is an optimization switch you can use to disable this -- but why would you? Most compilers only let you 'conditionally include' code like this if you have a single object file, or you are using a library file. The C2C compiler does this for actual source.
  16. Well, the bad news is that I could never figure out how to get the Simulator to properly step the chip. The 12F675/12F629 don't have a 'PORTA', 'PORTB', instead they have a 'GPIO'. I was never able to get the simulator to recognize the GPIO register.
  17. You know, if the new C has typedef, structs, and allows pointer passing, and is robust and reliable (of course), then the C++ can wait a bit as far as I'm concerned. A PIC is a small memory-spaced object. That they have a C++ run-time with objects and methods that works at all on something this size is very impressive. Plus, I can do stuff with 32-bit longs, and signed math. The 'floats' would be nice -- but again, it's a small device. How much library space do you want to use up?
  18. That's because a PIC processor doesn't HAVE a 'stdio.h' file. 'stdio.h' is to support the Standard Input/Output model -- you know, disk drives, terminal screens. These don't apply well to a PIC microprocessor. No disk. No terminals. And, C2C does not have a 'printf' statement -- though it is not hard to create. It does have a putc, though. Create a new C2C Project. Select '.C and .H file'. Insert the 'int i' stuff I mentioned in my earlier post -- these ARE supported by the C2C compiler. THEN Compile. THEN Assemble. Note I believe the standard file has something like: #include <system.h> This has a #define for each supported PIC processor. When you choose a processor in the IDE, the #define is defined. Then, the <system.h> file uses the processor #define to memory map the names of the processors registers. Just please don't use <stdio.h>. Doesn't apply to this new small world of PICs.
  19. You need to add to your project a .C file, like: main() { int i; i++; } Then, compile that. This will generate the .ASM file. (IF the 'C' program has good syntax. Otherwise, the ASM file won't be generated.) Assemble that. This will generate the .LST and the .HEX file (IF you've downloaded the www.microchip.com MPLAB package, and gone in to 'Tools, Options' and set the assembler to point to the MPASM program.) Note it helps if your are using MPLAB 5.7 or older, that you name your project an 8 character name. Any more than that, and the compiler can have a hard time finding the output files.
  20. Note my previous example is compileable and simulate-able under C++ under the 16F84 model -- which is always available. Try it out.
  21. 1. I don't think C2C++ supports 'typedef' yet. 2. Yes, this can work, if you do something like: #include <system.h> #define MyDataPtr struct MyData * struct MyData { int Data; MyDataPtr Next; }; // Note MUST have 'semicolon' here, or complains about next line. MyFunc(struct MyData * Node) { Node = Node->Next; // Works, BUT does not 'pass-back' changed 'Node'. } main() { int MyVal; struct MyData * HeadNode; struct MyData * NextNode; struct MyData * TempNode; HeadNode = new MyData; // Note 'new' assumes 'class' or 'struct' keywords. NextNode = new MyData; HeadNode->Next = NextNode; NextNode->Next = HeadNode; HeadNode->Data = 1; NextNode->Data = 2; TempNode = HeadNode; while(1) { MyFunc(TempNode); // Should work, BUT does not get modified value... TempNode = TempNode->Next; // Does work... MyVal = TempNode->Data; } }
  22. Sigh. Some people are never satisfied. Though I know what you mean.
  23. Hey, folks, with no fanfare at all, SourceBoost version 5.5.1 has been released. And here, I was using 5.4 happily. Still, I've installed it, and it works -- seems to load faster, too.
  24. I am NOT seeing the login problem -- works fine, as far as I know.
  • Create New...