Picaxe vs PIC and compiler

[BruceM]

Working on some software for my 120VDC battery bank controller I finally ran into a stumbling block with the Picaxe 40X1; it is limited to 16 bit unsigned integer maths.  Alas, for state of charge (SOC), calculated every couple seconds throughout the day, this just won't do it.  I need 32 bit integer or at least 32 bit floating point.  

There are about 8 compiler choices (Basic or C) that support the same 16F887 processor, so I won't have to change my processor board, but I will miss the utter simplicity of the Picaxe as I wade through compiler and programmer choices.

[Mad_Labs]

Does your compiler have the ** and  */ functions? You  can fudge 32 bit maths with those to some degree.

Do you really need 32 bit math for SOC? How exactly are you doing it?

I have been using an awesome uC called the Propeller. Great for these kinds of projects, it has 8 independent proccessors and all the math you need. It can run a VGA monitor by itself, no PC required.

Jonathan

[BruceM]

Hi Mad Labs, welcome.
Propeller sounds interesting, I'll check it out. 

For this project, power consumption is a big issue, thus the PIC 16F or 18F processor selection.  The problem with 16 bit unsigned integer math (no overflow for addition and subtraction) is that integrating the current inputs (PV, Generator, Wind) and outputs every couple seconds over relatively long periods of time leads to rather gross errors.

I can mitigate this somewhat by averaging the net currents over larger periods, but that is complicated by the variable sample rate.  Variable sample rate (but with accurate interval time) is an artifact of the rather limited real time capabilities of the Picaxe basic, and the need to "sleep" the processor much of the time to reduce power consumption.

I think I'll migrate to BoostC, which is cheap. It supports both a floating point library as well as 32 bit integers (signed or unsigned).  It will also allow me to better use the onboard timers and have a fixed frame rate for calculations.

Best Wishes,
Bruce M

[mobile_bob]

it wasn't until i had developed my method of a multiprocessor architecture, the propeller was just
getting a good start in sales, and i really didn't want to step away from my work with this system
to learn another programming laguage, however

the propellor is very fascinating, and reasonably priced, and when you factor in the support from
the manufacture and the forum, wow!  quite a value in my opinion.

but what do i know, i am no programmer!

the bs2 stamp is so well documented, so well supported, and so many folks working with it
and the fact that the programming laguage (pbasic) is very intuitive to me, its hard for me to
want to look at anything else. Even though i am somewhat limited with interfacing video and data logging
(no fault with the controller, the fault is all me, i got to learn the programming to get there), i find that
basically about a dozen code/commands will do everything i need done to run a master with multiple slaves
communicating on a wide buss using simple on/off control.

the downside is higher cost in hardware, but the upside is me not having to take a course in programming
and code thousands of lines and then try and debug the whole thing.

that propellor is so neat though, hopefully there will be some application of it within this group, i would really like
to see it in use controlling an AE system.

bob g

[BruceM]

The Parallax Propellor looks interesting. One of the more original uC chips out there. Very odd architectural choice to share an internal bus to peripherals, but I assume they've somehow managed to avoid I/O bottlenecks.  I hope they've allowed I2C device expansion, perhaps that's handled in the I/O. 

Very interesting, and now I'm afraid I'll find some application for it!

Thanks, Mad Labs.

[BruceM]

Jonathan, is it true that the Propeller doesn't have analog inputs?  I couldn't find any reference in the manual.  This seems so odd that I must have missed something.  

Likewise, I don't see any I2C support except for an external EEPROM (optional).
That rules out other peripheral chips to solve the lack of analog inputs, plus I/O expansion, real time clocks, etc.  It again seems so obviously needed that I must have missed something.

Back to the Picaxe; it does support ** and */  for multiply. No overflow for addition or underflow for subtraction, however.  I did find some Picaxe basic code for 32 bit unsigned math on the Picaxe forum. It uses peeks and pokes to processor registers, to get under/overflow info and then do the math. Crude but effective, I may stick with Picaxe since the only problem was SOC calculation.

[Mad_Labs]

Bruce, Bob, All,

First, let me say I do some beta testing for Parallax. I don't get paid, they were very supportive of my hydrogen fuel cell robot project and I love their stuff. So I'm not unbiased.

Bruce, you are right, there are no analog inputs on a Prop. This was a design selection and the why's are OT for here. I was resistant, but now see why and agree. It does however support I2C, and you can stack on the same pins used for the eeprom (or any other pins). The external eeprom was another interesting choice, but again this isn't the place. The Prop can be programmed in ASM and a unique and a little odd language called Spin. I really like it now and it was very easy to pick up.

The truly fantastic thing about the Prop is the 8 cores tied together with a central hub. It is completely deterministic. This thing can truly walk and chew gum at the same time. For example, at my old place I had a Prop:

getting the time from a GPS
Broadcasting the time locally via RF
Displaying the time on Nixie tubes
Displaying hot tub temp on nixie tubes
triggering garden watering valves
Running my solar powered hot tub, which uses panels and a wood burning stove, as well as a propane back up
Gathering weather data
Logging all data on a thumb drive
displaying all the data on a VGA monitor and interfacing with a mouse for GUI and menus

So simple to do all that stuff at once. No interrupts. You can set up a core to read your ADC or whatever. No matter what, you know how many samples/sec you are getting. The user can interface changing settings or whatever, and the data is compeletly unaffected. You can hook up a mouse, keyboard, vaga monitor for inetrface, whatever you want.

Bob, the support for the Prop is booming and the object exchange is getting big. Spin is a little harder than PBASIC, but not much, and it is way more powerful. And the Prop makes getting some stuff SO much easier. For example:

I do Sumobots with students all the time. With a Basic Stamp or PIC it is a challenge to do everything that needs to be done, check opponent and line sensors, run the servos and so on. Students have found it hard to squeeze their ideas into into the long loop that is the program.

Enter the Prop. Set up a core to handle sensors. Make a core to handle the servos. Now I can program a core that does nothing but make descions. So simple for students to work with.

Anyway, as you can see, I'm a fanboy, so take this with whatever size grain of salt that suits you.

Jonathan

[BruceM]

Jonathan,
Good to hear that I2C is supported, that takes some of the sting out of lack of Analog input, at least for larger scale projects.

How is a bottleneck in I/O access avoided, and how is it prioritized?  That must be a very fast parallel internal bus is you're feeding VGA video while doing other I/O. 

It's good to see Parallax is doing something novel.   The stamps don't look very good compared to the Picaxe chips, but the Propeller is neat.

Best Wishes
Bruce

[mobile_bob]

its going to be very interesting seeing what everyone comes up with, its too bad however
that some basic architecture could not be agreed to, so that several people could develop
different aspects of a total system and have it all plug and play together.

it just seems way over my pay grade to figure out how to integrate 3,4 or more different processors
using as many or more different programming languages, and perhaps as many different communications
protocols, good lord the variations get way to complex for me to even conceptualize.

now if the group could agree to a standard, that was fairly simple, perhaps we could work out a system
that could be adapted to each specific use?

then there is this question(s)

i read alot about wanting data logging, and call my cell if you have a problem, and computer screen interfaceing
and all that,

all that seems really cool, but is it really necessary?  we have quite complex computer control over our cars and we
have no vga screen to give us a user interface?  we get a check engine light that tells us the system has an issue
that needs attention,, could that sort of thing work as well for our needs?

i guess basically the question is,
is all the data logging, and user screen interface a "want" or a "need"?

i don't know, thats why i am asking

a system that i personally see as a need would be one that scan's all my loads, does some scheduling and load management
scans my power sources (batteries, solar, wind, generator) and decides which source or combination of power sources can
fit the needs of that load, and then make the necessary connections (battery>inverter>load, or Engine>ST head>load, or
solar>battery>inverter>load, etc)

and it needs to run on multiprocessors in my opinion, running all this on a single processor could certainly be done by a smarter
guy that me, but any glitch and the total system fails. running on a master/and multiple slaves seems like it could be done
so that there is a failsafe fall back position coded in to where the master could be replaced by  another underutilized slave
(by coding it to do so) and maintain if not full functionality certainly a decent level of limp mode?

everything done on a single processor looks to me like if there was ever a glitch or some wierd loop that locks the processor, you
would have no load managment, no power source selection, basically a complete system shutdown.  "houston we got a problem" sort of
event.

what i am thinking basically would work like this for example
the master monitors many things one of which is battery charge condition, and it sends a start command
out to the slave that is in charge of engine/genset startup,, if the master continues to work as designed
and the battery gets down to a programmed 12.4 vdc it sends a startup command, the slave starts the engine
and starts the charge controller, and all is good,

if however the master was to fail, the coding in the slave controller could have a fallback position where it monitors
the battery voltage and if it see's the voltage drop to a programmed 12.2volts and it can then send a pin high on
the buss back to the master (sort of a wake up call, or "hey are you there?") if it does not get the command back
to start in a predetermined length of time the slave takes over and does the job without the master being involved.
and sets  "check engine" light (ok, not really a check engine, but in this case check the friggin master processor
its either dead, locked, or ?)

i don't know how you do all that on a single processor, and i don't know how one gets all this done using a variety
of processors and programming language, and communication protocols,,, without having some sort of standards
in place that everyone can build to.

if the basic architecture is simple enough, perhaps many people could work toward developing a really useful system

failing that, we all get to reinvent the wheel over and over again?

lots i don't know, and even more i would like to know



bob g

[Cornelius]

I would say that a Picaxe (with a current price of £1.5-£4.5) would cover most of the 'needs'; monitoring vitals, and it could play 'Jingle bells' and turn on some lights when something are wrong.
It could also cover most of the 'wants' by itself, and by adding external memory, an lcd with a menu system, and connecting it permanent to a pc for logging/monitoring etc.; all for little money and relative simple assembly. (thebackshed.com have some interesting projects there...)

My opinion.

[rcavictim]

Not that there is anything wrong with tinkering but you need to choose where your interest lies - engine, electronics, alternate energy or what. One person can't do it all.

Jens

I usually try 'to do it all', but microprocessor control is something I have never gotten any experience with.  On my current VAWT project I am just now starting to think about how I can put together a relay logic controller to make the thing behave without my direct supervision.  I've even designed in a dual coil relay to operate as an analog comparator so far. I need to monitor wind resource and use that info to tell the machine when to start, provide only enough from the starter battery bank to speed up the turbine to match the wind condition at that moment, not waste energy in a up to full rotational speed start, and control the shutdown and brake when conditions merit, like too much wind, excessive vibration, etc.

[BruceM]

The data logging thread isn't here, guys.  It's in the realm of research, not automation, anyway.  No one would seriously propose a PC as necessary for  non-hobby, non-research genset operation, I hope.  

Bob, When you get more programming experience, you'll find that everything you have suggested for power management can certainly be done with a single, very modest processor. (I'm doing it in a puny PIC 16F/18F part.) How often do the decisions have to be made for battery/power management? Once per second seems fast.  Once every 3 seconds seems acceptable.  This sort of performance doesn't need much muscle.

Just line up your "tasks", and put them in a big loop. Variations on this theme have been used for miltary flight simulators since the days of drum storage.  I'd be glad to help you with this, email  me.

The Basic stamp is weak at this, many I/O commands don't use hardware and thus tie up the processor.  Some commands don't have timeouts, and can hang the processor if something goes wrong.  

The Picaxe 28X1 or 40X1 (or new 40X2) are (barely) suited for real time work as they do have hardware serial I/O and hardware I2C/SPI.  They also support I2C slave functions, so multiple processors can be used as master and slaves. I say barely because of the relatively slow speed of an interpreted basic (as the stamp is).

For more serious work, a compiler should be used (C, Pascal, Structured Basic).  This gets you a 10-100x speed increase, and a lot more flexibility. You get true interrupts, and better control of all of the chips timers. This makes it easier to do a few things at the same time, instead of sequentially.  The price you pay is a 10x increase in complexity for the novice programmer. (Not as bad for the veteran.)  One reason I like the Picaxe chips is that at any time I can switch to a compiler, with no change to my hardware, since they are really just preprogrammed PIC processors. I also can upgrade to more memory or a faster processor without hardware change, often.

I'm trying to avoid a compiler in my battery bank controller (which regulates PV, AC charger-generator, Wind, and State of Charge), because I just don't need the speed, and don't want to buy the tools, and learn them.

As for reliability, while redundant systems are sometimes used, it's not appropriate in this case.  A multi- microprocessor system isn't going to be any more reliable.  (I like them where needed and was a pioneer in their use in flight simulation.)  The solution to reliability is good EMC design, and overbuilding whenever practical.

I've found the PIC (and Picaxe) chips to be extremely tolerant of abuse, and I've NEVER had a failure or bad part.  

Given the increasingly more common inclusion of I2C serial communications bus support in microprocessors and compilers, I'll be surprised if the Propeller becomes popular outside of a few enthusiasts. Most designers would "roll their own" with standard, dirt cheap uP parts and I2C. Then you get to use the same programming language and the same parts you're already familiar with.

Bruce M

[AdeV]

For more serious work, a compiler should be used (C, Pascal, Structured Basic).  This gets you a 10-100x speed increase, and a lot more flexibility. You get true interrupts, and better control of all of the chips timers. This makes it easier to do a few things at the same time, instead of sequentially.  The price you pay is a 10x increase in complexity for the novice programmer. (Not as bad for the veteran.)

When it comes to willy-waving, you just can't beat Assembler. Well, other than hand-coding raw machine code with a toothpick, but that's just masochistic...

I have always wanted to build a MC68000 based real-time system. The 68K chip family are a dream to program (especially when compared to the abhorrent Intel equivalents), and even the runt of the litter (the MC68008) is properly quick & easy to use. Unfortunately, it seems that the Motorola chips have fallen very much by the wayside. It's only possible to buy surface mount versions new, and then only 68020 or 68040 which are very fast & very powerful, but with a step-change in complexity compared to the early chips.

So, it seems I will have to butcher a Sinclair QL for my 68008 projects.... No bother, I have at least 5 of them

[BruceM]

AdeV, your post brings back memories.  I was the manager of the new product line development for ICE and Bus Analyzer for the 68020 (and HC11) for Motorola Microsytems.  I wasn't allowed to use a PC host as Motorola Semiconductor sector paid our salaries and they had their head up their asses about loosing the PC wars. So our control box was 68008 running Digital Research's CPM68. (I was unimpressed with any of Motos offerings of the time.)

A couple years later I designed the system and was using half a dozen 68020's in the avionics simulation in the Advanced Apache simulator (became Longbow). We were running a stripped Unix compatible bare bones run time kernal in the slave processor boards, and Ada code to impress the Army.  All the slaves had their own private VME bus for various interfaces to aircraft gear and displays, and some custom video graphics gear. The total number crunching power and I/O of that system was amazing.  

Regarding assembler and willies: Assembler is for little willies, real men patch machine code in hex.    

Seriously, I wouldn't touch assembler code for the PIC, it's just too primitive.

I was sorry that the early Rabbit processors didn't catch on.  I'd love a single chip computer with a Z80 instruction set; I did a lot of hex hot patching in Z80 when I was a lad.  Loved the second register set for interrupt handling!

[cognos]

Wow. Now I know where the other 5 guys in the world who still use their HP 11C programmable calculators (because they LIKE RPN... ) went.