Comments on The Manual.

[jglenn]

Finally managed to print out and read Manuals 1 and 2. The PICAXE is a remarkable family of chips, currently I am working with the 18X on a control system solution. Overall the quality is excellent, and the interesting posts and suggestions here are often very useful, keep it up.

1. Manual 2, page 20. Math functions. Seem to be missing < and >.
Pretty important from my view. Knew they were there, as have seen in the code. An explanation of using the = sign with them would be nice..

2. The I2C appears to be the most efficient way to do extended I/O. Can add chips without using more pins on the chip. What is the best expander chips for dig in and dig out uses? Availability and cost.

3. SPI seems complex, glad I started with I2C, got a quad DAC running ok.

4. What is up with servopos? Does it work with all servos? Does running that background timer system reduce program reliability? I have not used it yet, but understand you cannot also run pwm with it, or maybe serial at the same time. Fortunately my requirements are simpler right now. Thanks for any suggestions.

 

[manie]

Jglenn: Adding to your comment on PWM, my recent post in this regard where Readadc/Readadc10 seems to fall down while PWM is on. If PWM is used to generate a current through a load, and you try and read that current, the PWM duty cycle is altered, at least on my 28x1 controller project. Any readadc, of the current or other adc input pin all produce this alteration. Will try and get 'scope images of this and post them.
Manie

 

[kranenborg]

Hi jglenn,

Concerning your issue 2 (most suitable i2c i/o expander chip) there are several options of course, since there are several factors that may play a role in your design, amongst others:

- cost & ease of getting them
- current/power draw (consider scenarios like: idle, normal use, max allowed total current when all outputs are actively driving a load; note that this value is generally lower than the sum of all individual output maximum load currents!)
- minimum Vcc operational level
- flexibility (programmability, interrupt support, ...)
- the kind of load they should drive
- etc. etc.

My favourite for "standard" digital I/O is definitely the MCP23008 & MCP23017, the latter as the successor of the MCP23016, which are very modern and powerful yet cheap and commonly available chips, but there are many others around that perform similar functions.
When driving LEDS / still a digital output, eh ... / I particularly like the MAX69xx family, specially the MAX6955, MAX6956, MAX6959 and have used some of these successfully.

A fully agree with your choice of the 18X, it is still my favourite because it is so extremely flexible, see for example http://www.picaxeforum.co.uk/showthread.php?t=9289

Like said earlier, others have different favourites based on their requirements. Hope this helps a bit.

Best regards,
Jurjen

 

[Dippy]

Well, Issue no.1 will get Westy agitated , but I have often said that the Manuals could do with a bit of a 'spring clean'.
No doubt Westy can list all the typoes and omissions... he doesn't get out much
But, in fairness, he and others have spotted quite a few.

Just hope that hippy doesn't write it because it'll end up longer than War & Peace

I can't comment about Servopos but with my experience with PIC I'm not surprised that some of these things get their knickers twisted. Quite frankly I'm surprised at the excellent performance as it stands.
Slightly at a tangent: remember, whatever firmware is limited to PIC hardware. Many commands require interrupts (hardware peripheral, timer etc) and I assume for some functions (including download??) the interrupts are used with enthusiasm. Interrupt handling can be a bit of a swine sometimes, so my hat is doffed.

 

[hippy]

SERVO and SERVOPOS

The SERVO command does a number of things -

1) Sets the servo position value
2) Configures the I/O pin as needed
3) Notes the I/O pin as a servo channel
4) Configures and activates the background timing handler
5) Starts the background servo handler running

The last three make for the complicated part because the chip has to be right for servos to work as expected. The end result is that a SERVO command restarts the 20ms servo frame. This doesn't cause a problem when SERVO commands are far enough apart but when people try to use them too closely together the frame gets restarted, the servo never sees complete frames and may not behave as desired.

The SERVOPOS mechanism allows the required servo position value to be set without re-initialising the internal hardware or restarting the frame so physical servo operation is not adversely affected.

It would be theoretically possible to have the PICAXE be 'much smarter' and know when it has to initialise the background timer, monitor when servos I/O's are overridden by HIGH and LOW and choose an appropriate SERVO or SERVOPOS behaviour as was necessary at any time using just the SERVO command. However, it is not that simple in practice, there is more to it than I have described in simplistic terms. On a constrained device like a PICAXE it is not easy to add additional complexity without having to sacrifice something else.

It was probably never imagined that the PICAXE would be pushed to its limits and used in some very complicated, multi-I/O and high-speed applications as it is now, and while SERVO is entirely usable by the majority of PICAXE developers, SERVOPOS has been provided for that section of the PICAXE community who need more demanding control. It is a compromise solution, but a better one than the available alternatives.

Similar issues are why PWMOUT has been enhanced with PWMDUTY.

As to the PICAXE's inability to handle SERVO and PWMOUT simultaneously, and interactions which can occur when using background processes, this is down to the hardware available and internal chip design plus the fact it is a single processing core which can only do one thing at a time. Where the internal timers can control PWMOUT or servo operation it is not possible to use both without one adversely affecting another, a timer simply cannot run at whatever kHz PWM has been chosen at any particular time and at a fixed 50Hz for servo frame timing.

When executing time critical commands, INFRAIN, INFRAOUT, SERIN, SEROUT, PULSIN, PULSOUT, 1-wire bus and the others, timing has to be maintained which means the background processing has to give. In most cases this is not a problem, as the number of conflicts for processing are few if any but, where multiple timing critical commands are used, conflicts become more frequent and the affects can be more noticeable, similar to getting poor browser response while burning a CD, downloading a multi-MB movie, collecting your email, while backing up your files across a network. Everything gets more 'jittery' as each competes for a slice of available time.

These are issues which all processors face and simply having more speed doesn't necessarily solve them, critical I/O operations still take the same length of time and cannot be interrupted, conflicting demands will cause something to not happen. Like people, though they may be able to do many things, that doesn't mean they are capable of doing all those things at the same time.

 

[westaust55]

Finally managed to print out and read Manuals 1 and 2. The PICAXE is a remarkable family of chips, currently I am working with the 18X on a control system solution. Overall the quality is excellent, and the interesting posts and suggestions here are often very useful, keep it up.

1. Manual 2, page 20. Math functions. Seem to be missing < and >.
Pretty important from my view. Knew they were there, as have seen in the code. An explanation of using the = sign with them would be nice..

< (less than) and > (greater than) are not really math functions but comparators.
As such you will find that they are included at other pages such as Manual 2 page 75 under the IF...THEN function.

Also at page 40, page 77 etc

 

[jglenn]

I see, <> and variants are there on pg. 75 with if/them. That is ok, I was just expecting one master list of the math/logic functions for easy ref, I will make my own. OR and the others are really logic, not math! Regardless of their functions, when programming I like to have the whole group in the forefront for easy consideration.

Manie: I remember the reports of pwm drift possibly caused by adc reading. Appears to be an effect of multitasking. I will carefully plan such operations to take place one at a time if possible.

Jurjen: Thanks for the chips, will check out. Also the package is important. I just had to fix an error on a TSSOP package pin, a bit hard to solder even with paste and hot air, and I have been trained (nasa, medical people). Found it by pushing against the side of pin with tweezers to see if it moved. I tend to go light on the paste to avoid shorts under the chip (blow it out from ends). I like SOIC chips, small but not too small.

Hippy/Dippy: I had no idea there was so much going on behind the curtains. Timing and multitasking are now scary topics! Due to not fully understanding the servo output operation, I have set up an alternative means to do it, just to have things under local control. My quad DAC can run 4 servos, variable is 0-255, and there are never any glitches. A raw PIC12C671 chip I program with assem reads the 0-5V DAC output, and generates the 50HZ signal. It has nothing else to do, so is happy. $1 each, a little room. When I want to change position, I just spit out one I2C word, then the PICAXE is not burdened until the next change.

I am running servos on a model plane, it's ok if it crashes, built to take it, but the goal is eventually autonomous flight. Right now just working with the elevator, and various sensors to determine attitude. I will be having some coding questions for sure in the future. I like the idea that I can add many more servos, without more pins on the PICAXE (I2C rocks!). Going to multiprocessor solutions could be a way to augment PICAXE utility, while preserving reliability and programmers sanity.

One amusing thing in the manual was the way to get around not having decimals, for example if you want to divide by 5.7. They show how to multiply by 10, then divide by 57, which does the same thing. I had to actually do this on paper to verify, sounded funny, but it is true. Reminds me of about the only trick we assem progs have, using bit shift to multiply or divide by 2. Simple CPUs and heavy math simply do not go together well!

 

[hippy]

You're right about simple CPU's and complicated things not always mixing well. The PICAXE does a great job of hiding complexity and making things easily doable and it's often easy to forget there are limitations to what can be achieved. Sometimes issues can be worked round with different software and hardware designs or by off-loading work to another chip, PICAXE or other, but I bet I'm like everyone else and would like to do it all, and flawlessly, on a single 8-pin chip at zero cost and with minimal effort

 

[jglenn]

I stick with simple micro solutions, leave the hard stuff to a PC or embedded high power processor. We use Freescale cpu's at work, on engine controls, CAN bus with baffling data standards, the eng tinkers with that. He says we will use the ColdFire soon. Big deal, runs on 3V which is bad, already enough static and noise immunity problems in use with 5V chips. Many engine sets run on trucks or trailers, insulated from ground by tires, they refuse to have ground straps, so high charge builds up from spinning junk like 8 V-belts in parallel (looks like a van de graf generator to me) turning a compressor. When somebody touches the keypad or keyswitch, it draws an arc that fries things. "Eng" applies TVS diodes, but not in the way I would like to see. You guys have it easy with your hobby boards. When they break people don't call up and scream.

 

[manie]

Have you ever phoned yourself to complain about ANOTHER problem ?? i felt like it once !

 

[jglenn]

Adding to the list will not make money. My job exists due to things breaking, and the dumb designers we used to have, no degrees or real experience. Have a real engineer now. Fortunately the other test guy answers the phone. In fact, I P'd off a cust so bad once I am not supposed to talk to them. He blew out 3 of the same circuit boards in a row, and I said "you should figure out the problem before hooking up the next one". He called 5 people at the plant and complained, but they all said I was right, which made him madder.

Life as a solderjockey is good...banging bits and bytes. Finding gremlins and terminating them.