Temporary leave...
Ravenkallen
Posts: 1,057
So... First i want to say that you have all been great. One of the best forum "families" i have known:). But the time has come for me to get over my fear of C/ C++. I have now pledged most of my spare time to learning C/ C++ using an Arduino(And then moving on to ARM's, Mbeds, AVRS and all that). I am not completely abandoning the Propeller, but rather taking a extended "holiday" from it. So, this means that work on PASos has been discontinued, as well as the text editor program. The C3 seems to be losing popularity anyways... I may still work on Spaceace! though and be watching over the forums occasionally to.
To Cluso... I am still planning on using the CPUBlades in my soldering iron project.. It might be one of my last Prop projects for a while
To WBA Consulting... I think your DIP40 modules have promise. I still have one embedded on my Rover5 platform.
To Martin Hodge... I still have not gotten around to using the ASC compatible in a project. I am still thinking of a good project to use it with. I had an idea though. I could write a SPIN program for most every Arduino project that i do, To see if we can get more shields successfully interfaced with the ASC?
To Ken, Chip and Parallax... You guys are a very good example of what a company should be like. Honest, open, modestly priced products, community support. Never give up:)
@everybody else.... I still LOVE the Propeller and it is still very relevant, but i have to break out and look at what else is out there. AND I HAVE to learn C, even if it kills me:) C is the language that the computer world seems to be leaning towards and i have put off learning it to long. I just feel like i will get left behind if i don't act now. Who knows, in a year from now the Propeller 2 could be out and a real C compiler developed for it. I hope to see you all again soon... RK
PS... If anybody is interested, i am selling my used C3(Excellent condition) for $60(Compared to $129.99 new)
To Cluso... I am still planning on using the CPUBlades in my soldering iron project.. It might be one of my last Prop projects for a while
To WBA Consulting... I think your DIP40 modules have promise. I still have one embedded on my Rover5 platform.
To Martin Hodge... I still have not gotten around to using the ASC compatible in a project. I am still thinking of a good project to use it with. I had an idea though. I could write a SPIN program for most every Arduino project that i do, To see if we can get more shields successfully interfaced with the ASC?
To Ken, Chip and Parallax... You guys are a very good example of what a company should be like. Honest, open, modestly priced products, community support. Never give up:)
@everybody else.... I still LOVE the Propeller and it is still very relevant, but i have to break out and look at what else is out there. AND I HAVE to learn C, even if it kills me:) C is the language that the computer world seems to be leaning towards and i have put off learning it to long. I just feel like i will get left behind if i don't act now. Who knows, in a year from now the Propeller 2 could be out and a real C compiler developed for it. I hope to see you all again soon... RK
PS... If anybody is interested, i am selling my used C3(Excellent condition) for $60(Compared to $129.99 new)
Comments
Now is exactly the wrong time to be giving up the Prop for PICs, AVRs and Arduinos just so that you can learn C/C++.
Just now when the Catalina C compiler is maturing to perfection and there is the imminent arrival of the GCC C and C++ compiler.
As an old hand I would suggest you start out learning C/C++ on your PC. That will make experimenting and picking up the language a lot easier. If you have a Linux machine you are all set to go. If you are on Windows get a free compiler from MS or use Code::Blocks or Cygwin. Perhaps others have better advice there.
Get yourself the white book by Kernigan and Ritchie a couple of other books and a compiler and you are set.
With that under you belt you can turn to C on micro-controllers. Probably GCC for the Prop will be ready to go by then or Catalina.
Anyway having become profficient in C on the PC at no cost other than time you will be in a good position to evaluate whatever C running hardware you fancy.
Meanwhile you can still have your Prop projects on the back burner.
P.S. Did you know the first C compiler whose output ran on the Prop was the BDSC C compiler for the Intel 8080.
It runs on the Prop under the CP/M OS under Z80 emulation.
It is still the only C compiler that can compile code actually on the Prop, no PC required. So if you are really keen you can be doing all of your C studies on the Prop alone:)
(Not recommended).
-Tor
#include <stdio.h> /* Get access to printf() & friends */ /* * Compile and link with : gcc -Wall -o executable-file source-file.c * -Wall means 'All warnings ON' * -o means 'output file' */ int main (int argc, char *argv[]) { printf ("Hello, world\n"); printf ("You entered %d space-separated argument(s)\n", argc-1); printf ("Now figure out how to write them out from argv[]\n"); printf ("The first, implicit argument is the name of the executable: %s\n", argv[0]); return (0); /* All is good */ }So, in terms of actually learning C, warts and all, the Arduino is not the best place to start.
I don't belive there is a human being alive who fully understands the ramifications of the complexity on offer by C++. (Seriously).
Languages come and come and come and go again....if you know a procedural language and can put together algorithms in that, your good to go when someone throws a new procedural language at you...Object Oriented design and thinking under your belt...then you're good for the most part in that area....ever try Lisp? Haskell? Prolog, Smalltalk......the tower of babel is tall...learn how to program, how to structure your thoughts, how to get requirements out of a user (or yourself).....odds are good you'll show up to the dance with the wrong language a lot of times.
...at least that's my theory after too many years of learning different languages.
Whatever you decide to do, good luck!
Leon - That cannot be true. For the Arduino you might send a char to a serial port with ser.tx('A') or some such, I can't remember exactly now. It is very definately C++ that you are writing for the Arduino.
That's just too much for us to tackle at this point.
-Matt
You are calling a C++ library function, but you have to use C. If you try using C++ in a sketch I'm quite sure that you will get an error message when you try to compile it.
That is not true.
You cannot call a method of a class from plain C with the dot notation as in the example I gave. Ergo it is C++ you are writing.
I imagine there is nothing stopping you defining your own classes in Arduino sketches.
Good luck, hope you find what you're looking for. And I bet you won't be gone for long. This is a great group for a variety of reasons. Worth keeping in touch just for moral support. Peace out for now!
Sketches can only contain functions, AFAIK. You can't use classes and all the usual C++ stuff in them, as you can when writing library functions.
Arduino sketches co-op AVR-GCC, which is an open source toolchain for C/C++. Yes, it's C. Yes, it's C++. Most sketches remove the technicalities by using pre-defined macros and functions that simplify the majority of work. I'd say 90% of Arduino users have never directly used a C++ construct. Instead, they import objects from libraries, instantiate them using example code they've copied, and they never know the difference.
An example is Serial, which is a predefined function for working with the chip's UART. After initializing the UART with something like:
Serial.begin(9600);
The constructor creates the Serial object and does all the necessary port initialization. Users then interact with it using something on the order of
Serial.print('A');
The Serial object includes methods for checking if bytes are available, peeking at the buffer, retrieving bytes, etc. It's C++, but only under the hood.
All this said, if you want to learn C, it's much easier using a free compiler and editor, and doing it on your PC. External hardware like microcontrollers just add to the aggravation. Microsoft gives away their entry-level C# and C++ tools for .NET, and they have excellent features for code writing and debugging. If you don't like MS stuff there's Mono, and the tools for it.
-- Gordon
That's true, as .pde sketches are intended to be wrapped internally at compile time to make them real C programs (adding void main, making loop() an infinite for statement etc.). The tabbing feature of the IDE allows you to create and use included files while you're working with a pde sketch, however, and these can be .cpp, c, h, etc. files.
-- Gordon
Absolutely!!!
I now do Basic Stamp, Propeller, and Arduino projects. There's no need to choose just one. In fact I find the skills from one transfer to the others.
Anyway, C on a PC - C is really good for writing operating systems on workstations. If you have a powerful PC and need an OS or make changes to the OS, C is a good way to go.
For micro controlers, maybe its a different story. If you need to listen to sensors and talk to actuators, and then have your micro controller talk to a workstation, maybe you don't need C. But there are several options that are easier and more fun. The best reason to use C on a micro controller is if you already master C, and want move to micro controllers. If you don't already know C, there are other tools that might be better suited. If you have 20 years of experience in assembler, then assembler is the way to go. But folks don't tend to talk about "assembler" and "fun" until after a long learning curve.
Right tool for the right job. What's the real job? "Just learning C" would be best on a workstation. Moving to beyond spin or to a more mainstream environment might not mean
C.
Consider the nxp line dev kits are about $99.00 via Avnet, have c compiler (Code Red) all tied up in a nice Eclipse environment. Wish they had multi core though; just can't replicate that feature easily........
Frank
I may indeed have a sharp temper, but last time I looked there was still only one of me
However, I agree - Ravenkallen, why not try Catalina before you decide to leave the Prop altogether? All the fun of C, plus the best microcontroller on the planet. I'll even throw in a 50% discount!
I do think it would be a good thing to learn C before you decide to leap into the gaping chasm that is C++. C is really all you can usefully use on a microcontroller anyway (flameproof suite firmly zipped!), but if you really do decide you need to go beyond C, then GCC C++ is not too far away.
Ross.
The NXP LPCXpresso boards are under $30.
Yes, they are. I attended a USB/NXP seminar for my $99.00. Included lunch, good discussion with peers, and top it all off by a guest appearance (call it a 2-fer for a captive audience) by the Tyco team promoting their USB connection solutions and a box of a wide range of multiple usable samples in a nice kit. Sure, it was probably more than just buying a couple boards, but it was a good jumpstart and a way to meet and work with their local FAE.
It may be worth noting that there is an NXP device with fully integrated CAN on it. Including transceivers.
Frank
Deliverables from the course:
LPCXpresso LPC11U1X
LPCXpresso LPC1343
NGX Baseboard for LPCXpresso Lots of goodies on this one.
Free 128K code size limited ‘C’ compiler
Printed lab handouts
Oh, the LPCExpresso 4 by Code Red environment is happy in whatever OS you put it on.
RK- Definitely take Ross up on his discount - what a deal! (He's never offered that to me - 'course I'm too old now. I only got through A and part of B...
/bad jokes = off
-Matt
Come to think of it, I was thinking of leaving too. Two questions:
1) What am I offered if I stay?
2) What am I offered if I leave?
I'll weigh my options carefully.
/* * TankBot and IR Compound Eye program * Copyright 2011 Martin Heermance, portions of this program are copy, * paste, and rewrite of code from Gordon McComb's ArdBot samples, * concepts from OddBot's Mr General, and Andy Lindsay's frequency sweep. * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see <http://www.gnu.org/licenses/>. */ // Include the library code: #include <Servo.h> // Pin number definitions. const int RServo = 6; const int LServo = 7; const int TiltServo = 8; const int PanServo = 9; // Switch debounce constant, useful for bump sensing. const int debounceDelay = 50; // Controls how close before it is considered a near contact. const int THRESHOLD = 3; // Servo constants. const int PAN_TRIM = 6; const int TILT_TRIM = 140; // Create servo objects to control movement and tilt/pan. Servo servoRight; Servo servoLeft; Servo servoTilt; Servo servoPan; // Volatile state variables int panAngle = 90 + PAN_TRIM; int tiltAngle = 0 + TILT_TRIM; #ifndef IrEye_h #define IrEye_h /* * IrEye - wraps ann IR compound eye to drive output pins, read results, and compute * distances */ class IrEye { public: // constants used to index into arrays enum EyeZones { EYE_TOP = 0, EYE_RIGHT, EYE_BOTTOM, EYE_LEFT }; // Constructor to create dynamic memory and bind to member variable. IrEye() { _eyeFrequencies[0] = 38500; _eyeFrequencies[1] = 39250; _eyeFrequencies[2] = 40250; _eyeFrequencies[3] = 41500; _eyeFrequencies[4] = 42500; // Set the led pin high during initialization and calibration. for(int jdx = 0; jdx < FRAME_COUNT; jdx++) for(int idx = 0; idx < EYE_ZONE_COUNT; idx++) _irFrames[jdx][idx] = 0; _currentFrame = 0; _objectDistance = 0; } // Configure and initialize the eye. void attach(int eyeIrSensor, const int eyeTop, int eyeRight, int eyeBottom, int eyeLeft) { _eyeIrSensor = eyeIrSensor; pinMode(_eyeIrSensor, INPUT); _eyePins[EYE_TOP] = eyeTop; _eyePins[EYE_RIGHT] = eyeRight; _eyePins[EYE_BOTTOM] = eyeBottom; _eyePins[EYE_LEFT] = eyeLeft; // Set the led pin high during initialization and calibration. for(int idx = 0; idx < EYE_ZONE_COUNT; idx++) { pinMode(_eyePins[idx], OUTPUT); digitalWrite(_eyePins[idx], LOW); } } // Reads all the sensors and sets the state variables void readFrame() { // Read each zone for (int idx = 0; idx < EYE_ZONE_COUNT; idx++) { readZone(idx); } // advance to the next frame. _currentFrame = ++_currentFrame > 3 ? 0 : _currentFrame; // zero out the distance and compute the running average. _objectDistance = 0; for (int idx = 0; idx < EYE_ZONE_COUNT ; idx++) { _irAverageFrame[idx] = 0; for (int jdx = 0; jdx < FRAME_COUNT; jdx++) _irAverageFrame[idx] += _irFrames[jdx][idx]; _irAverageFrame[idx] = _irAverageFrame[idx] / FRAME_COUNT; // Add all zone distances. _objectDistance += _irAverageFrame[idx]; } // Take the average by divding by 4 (bit shift right 2). _objectDistance = _objectDistance >> 2; } // Reads a single zone. void readZone(int pinIdx) { // null out the distance counts _irFrames[_currentFrame][pinIdx] = 0; // Perform a frequency sweep for (int idx = 0; idx < EYE_FREQUENCIES_COUNT; idx++) { // Send an IR burst at the frequency for 1 ms _irFrames[_currentFrame][pinIdx] += freqout(_eyePins[pinIdx], _eyeFrequencies[idx], 1); // Delay to give the sensor a chance to reset. delayMicroseconds(600); } } // freqout - outputs a specific frequency to an I/O pin for the stated duration. int freqout(int outpin, long freq, int t) // freq in hz, t in ms { long hperiod; // calculate 1/2 period in us long cycles; hperiod = (500000 / freq) - 7; // subtract 7 us to make up for digitalWrite overhead cycles = ((long)freq * (long)t) / 1000; // calculate cycles // transmit square wave for t ms for (long i=0; i<= cycles; i++) { digitalWrite(outpin, HIGH); delayMicroseconds(hperiod); digitalWrite(outpin, LOW); delayMicroseconds(hperiod - 1); // - 1 to make up for digitaWrite overhead } // Don't read right away, give the sensor a chance to state transition. delayMicroseconds(280); return !digitalRead(_eyeIrSensor); } // getter for the average distance int objectDistance() { return _objectDistance; } // getter for the left right delta of an object. int deltaHorz() { return (_irAverageFrame[EYE_RIGHT] - _irAverageFrame[EYE_LEFT]) / 2; } // getter for the up/down delta of an object. int deltaVert() { return (_irAverageFrame[EYE_TOP] - _irAverageFrame[EYE_BOTTOM]) / 2; } // Displays the eye's state to the console. void displayDiagnostics() { char buff[32]; for(int idx = 0; idx < EYE_ZONE_COUNT; idx++) { sprintf(buff, "%s = %d, ", eyeZoneToString(idx), _irAverageFrame[idx] ); Serial.print(buff); } // Advance to the next line. Serial.println(""); } char * eyeZoneToString(int eyeZone) { switch (eyeZone) { case EYE_TOP: return "Top"; case EYE_RIGHT: return "Right"; case EYE_BOTTOM: return "Bottom"; case EYE_LEFT: return "Left"; } } private: // define the number of zones, ir zones, and frames. static const int EYE_ZONE_COUNT = 4; static const int EYE_FREQUENCIES_COUNT = 5; static const int FRAME_COUNT = 4; // A set of frames used to accumulate data, and a running average. int _irFrames[FRAME_COUNT][EYE_ZONE_COUNT]; int _irAverageFrame[EYE_ZONE_COUNT]; int _currentFrame; int _objectDistance; //const long EYE_FREQUENCIES[5] = {37500, 38250, 39500, 40500, 41500}; long _eyeFrequencies[EYE_FREQUENCIES_COUNT]; // Trigger pin int _eyeIrSensor; // Bind the pins array subscripts to correct values. int _eyePins[EYE_ZONE_COUNT]; }; #endif // IrEye IrEye irEye; // Perform one time initialization. void setup() { Serial.begin(9600); // set pin high during initialization. digitalWrite(13, HIGH); // Attach the servo object to their respective pins. servoRight.attach(RServo); // Right server pin D6 servoLeft.attach(LServo); // Left servo pin D7 servoTilt.attach(TiltServo); // Right server pin D8 servoPan.attach(PanServo); // Left servo pin D9 // Stop the servos and set tilt/pan to a neutral position. moveStop(); servoTilt.write(tiltAngle); servoPan.write(panAngle); // Pause to let the servos adjust to their home positions. delay(500); // Set eye sensor pin and set it. irEye.attach(2, 11, 13, 12, 10); // Pause to give the human operator an chance to observe. delay(1000); // Initialization and calibration completed, so set the led pin low. digitalWrite(13, LOW); } // Main loop void loop() { irEye.readFrame(); irEye.displayDiagnostics(); moveRobot(); delay(100); } // moveRobot - computes movement based upon sensor state. void moveRobot() { // Adjust tthe vertical position of the robot's head within limits. if (irEye.deltaVert() > 0 && tiltAngle < 90) tiltAngle++; else if (irEye.deltaVert() < 0 && tiltAngle > 0) tiltAngle--; // Adjust the horizontal position of the robot's head within limits. if (irEye.deltaHorz() > 0 && panAngle < 135) panAngle++; else if (irEye.deltaHorz() < 0 && panAngle > 45) panAngle--; servoTilt.write(tiltAngle); servoPan.write(panAngle); // Compute the distance delta and remove some bits to prevent thrashing. int deltaDistance = (irEye.objectDistance() - THRESHOLD); // if the object is too close, then back up. if (deltaDistance > 0) moveBackwards(); else if (deltaDistance < 0) { if (panAngle >= 135) turnLeft(); else if (panAngle <= 0) turnRight(); else moveForward(); } else moveStop(); } // Motion routines void moveStop() { servoLeft.write(90); servoRight.write(90); } void moveForward() { servoLeft.write(180); servoRight.write(0); } void moveBackwards() { servoLeft.write(0); servoRight.write(180); } void moveRight() { servoLeft.write(180); servoRight.write(90); } void moveLeft() { servoLeft.write(90); servoRight.write(0); } void turnRight() { servoLeft.write(180); servoRight.write(180); } void turnLeft() { servoLeft.write(0); servoRight.write(0); }I am about to (over the weekend or next week at the latest) run Catalina 3.3 on my new RamBlade3 boards - it's a commercial project so I cannot talk much about it, but I will definately be sharing what I find out with Catalina. Here is an insight that I can say. I have a handheld device (keypad and LCD) driven by a prop pcb (has the same 1"sq CpuBlade at its center) and communicates serially to another module that has 2 props. One prop is a RamBlade3 (prop, eeprom, 512KB SRAM, microSD and RTC w battery) and the other is an IO controller prop. The RamBlade3 will be running a mix of Catalina C, spin and pasm.
As we already have Catalina 2.x C running the user interface between the keypad and LCD screen, complete with a large number of menus, I have no doubts about the capability of Catalina C. The latest version 3.x simplifies the spin and pasm interfaces.
So, I would definately recommend you check out Catalina 3.3 C before you move on. If I am not mistaken, you already have the hardware to run Catalina. IMHO this would give you the best of both worlds... get to learn and program in C and at the same time remain with the prop chip you love. And we dont have to find a new Best Hair replacement!
If you don't come back, we'll sell your hair to the circus...