Adding a uM-FPU V2 chip to your PICAXE

westaust55

Moderator
Having spent some days "playing with the microMega corp uM-FPU V2 floating point math coprocessor chip I decided to pen a few words that might hopefully add to the existing microMega documentation specific to the PICAXE chips.

A Search here found that in the past there have been a number of threads about the uM FPU V2, and the more powerful V3, coprocessor chips most about problems experienced.

In the attached tutorial type document, I hopefully clarify a few issues and help newbies to this chip get under way even faster.

My work has been done using the i2c comms connection although SPI comms is also possible for "M" series PICAXE chips.

I have tried not to duplicate what is already covered in the microMega documentation to any great extend so it is still necessary to download the various documents from MicroMega to become fluent in the use of the uM-FPU V2 chip.

The uM-FPU chips are available from Rev Ed's TechSupplies online store in the UK and from MicroZed here in Australia.

Little Bird Electronics also stocks the V3.1 chip but my attached tutorial does not specifically cover that "bigger" chip.

Maybe more PICAXE users will look into the uM-FPU chips .. .

EDIT:
Realised I could assign the value in register A to that in register B (ie reg A = reg B) for any register A = 1 to 15,
so attach a Rev B version of the words with the necessary adjustments.


Have fun in a PICAXE world :cool:
 

Attachments

Last edited:

westaust55

Moderator
uM-FPU V2 - creating an IDE programming interface

After doing some further experiments and test with the microMega-FPU V2 chip, my conclusion is that to have the FPU program code within the PICAXE chip can improve the accuracy and resolution issues but by passing the instructions over to the FPU chip as required will always result in more PICAXE program space being used and certainly also a reduction in overall speed.

For example a program that occupies around 520 bytes in an 18X to perform the calcs for a HOPERF HP03S barometric pressure sensor occupies around 800 bytes in the 18X to have the FPU code within the PICAXE.


So currently have started to look at programming the necessary formula into the uM-FPU V2 chip as functions that are stores within the FPU chip.
The PFU chip can save up to 64 function blocks on-board within a total of 1024 bytes of flash memory.

The standard AXE027 programming cable can be used but there is a need to invert the serial data lines. Since we are talking about TTL levels here, the simplest way is to just use a 74HC04 hex inverter chip, a PICAXE type 3.5mm programming socket and a resistor or three.

With the AXE027, a single 10kOhm pull up resistor is optional but I have included for when the AXE027 cable is not plugged in to pull the uM-FPU V2 chip TSIn line high and thus not in Debug/IDE mode.

For those using an RS232 based comms link, you just need to add a 10k and 22k resistor as per the standard PICAXE programming circuit – tried that for myself and it works.

As can be seen from my attached schematic, and part of that also includes a DS1338/DS1307 RTC chip (since I have my RTC on the same module/board), it is all very simple. The interface to enable programming of function blocks into the uM-FPU V2 is in the bottom left of the drawing.

Note that for the Rev Ed "standard“ (well at least those sold by MicroZed here in Australia as teh Rev Ed agents) 3.5mm stereo programming socket actually has switching between the rear pins. When there is no programming plug inserted, the two ground pins are bridged together and the two Serial-In pins are bridged together.
When a programming plug is inserted, the two bridges/connections mentioned above are electrically broken and the plug is connected to the two outer most pins at the rear of the socket.
I have used this feature to switch a 10 kOhm pull up resistor in and out for the circuit for the TSIn external comms line into the FPU chip.


The uM-FPU chip is programmed at 57600 baud but I have found there is no need to even change the default AXE027 parameters from the 9600 baud default. The microMega IDE software must be making all the necessary changes within software and communicates correctly with the FPU chip via the AXE027 cable.
 

Attachments

Last edited:

westaust55

Moderator
Adding a uM-FPU V2 chip to your PICAXE - Part 2

Attached is a Part 2 on using the microMega uM-FPU V2 chip. This time using the microMega IDE V2 software to generate the program code for the PICAXE chip.

Also covers some further examples on creating you own user defined function blocks using the IDE software.

Also included are some comparisons on the PICAXE program space required for the examples provided which demonstrate that;
- for more complex (eg trig based calcs) that manual program coding can save PICAXE program space when the entire uM-FPU control code is held within the PICAXE chip.
- that use of the user-defined function blocks can save PICAXE program space and may even achieve speed improvements.

EDIT:
Rev B tutorial document added with a couple of typo fixes and mention of the PICAXE variable usage limitations within the IDE software as I noted below in post 5
 

Attachments

Last edited:

westaust55

Moderator
Using the uM-FPU V2 IDE - a PICAXE variable limitation

Realised in the light of another day that I had also failed to mention a limitation of the microMega IDE software with respect to the PICAXE chips.

The definitions (aliases) for PICAXE variables are limited to word variables W0 to W5 or byte variables B0 to B11.

You could always manually alter the resulting code that you would cut and paste from the IDE into the PICAXE programming Editor to enable the final program to use other PICAXE variables.

I will look to updating the part 2 pdf file soon to reflect this IDE limitation.
 
Last edited:

Linzmeister

New Member
Thanks for cutting through a great chunk of information in a clear and concise manner.

Yesterday I printed out the Instruction Set Manual, the IDE Manual, and a couple of other manuals too. I started reading last night and got several different kinds of scared at the prospect of working with the co-processor, but your description simplified it greatly.

I spotted the PE reserved keyword conflict straight up and figured on a similar name change to resolve it.

I will still have a good noggin scratch to figure out the solution to my problem, but getting the basics of using the tools out of the way is a good thing.
 

westaust55

Moderator
Great to see that there are others experimenting with / using the uMFPU chips.
Hope that the information I provided proves useful to you.
 
Last edited:

geoff07

Senior Member
I also appreciate the tremendous work that Westy has done. The use of an FPU is a nightmare otherwise, with much more design detail needed than any other Picaxe program. However, for me, despite spending much time on it, this is still too much work! Although I want to use an FPU for a specific project, I can't devote the time needed to creating the custom code. So, has anyone built on Westy's work to the next level and created some higher-level primitives? What would be specifically useful would be some matrix manipulation code. Clearly, with an FPU you need to keep the FP data within the FPU until solution, so this is more than simple multiply or divide logic, but includes management of all the registers, tracking of the intermediate results, convergence, and sending the final results to the Picaxe. Not trivial at all. Intellectually, I expect/hope I could crack it. In reality, not a chance due to time constraints.

Meanwhile, Picaxe development continues. I wonder how long until a Microchip microcontroller has FP built in?
 

Linzmeister

New Member
Geoff, there is a way of cheating!!!

Doing your original test calculations in Excel using Named Ranges - Check the Excel help file if you are not familiar with them, then copy and paste your Excel formulas into the UM-FPU compiler, create variables with the same names as your named ranges and throw some function wrappers around the formulas... and yes I did a quick check that Excel can handle matrix functions and it has 3 - Minverse, Mmulti and MDerterm - not as many as the uM-FPU, but it's a start.

Then you only have to write picaxe code to load the data, run the functions and read the results.... using the docs that Westy wrote or the templates that Micro Mega provide..

I worked this way simply because I hadn't bought the chip when I was trying to figure out the functions I needed and wanted to know that I could perform the calculation correctly before buying the chip.. It turned out to be a very productive way to work.. because the spreadhseet is designed for "What If.... ? " calculations, you can see the errors immediately, you don't have to wait for the processor to call the function and throw an error to know you 've made a mistake... and I can assure that I made quite a few.. Even bad code will compile.....

In fact had I used named ranges from the start, the work in Excel would have gone quicker as I had a cell reference error - B18 instead of B19 - which when you are trying to figure out where the Sun will be at a given date and time can really throw a spanner in the works.... It took me 3 weeks very part time to find that cell reference error. It was as I was naming the cells that the error became obvious..

Having figured out this little scheme, I then used the same process to calculate Julian Day Numbers and convert Degrees, minutes, seconds and fractions of seconds into Decimal Degrees.. which is trivial in comparison to the first excercise, but the process proved very useful none the less..

Having said that, if anyone wants to know where the sun will be at any date and time, for a given location on the surface of this planet, my Picaxe and uM-FPU code can calculate it for you... or you can look it up on the web... either way ;)
 
Last edited:
I am using a um-FPU to calculate angles from an IMU (inertial measurement unit), which is part of a headtracking setup I use with a flight simulator. I can safely say the above notes have been invaluable as I was finding it very heavy going: the Micromega IDE saves a huge amount of development time.

However, I have found accessing the FPU via the 57600 baud link to be very problematic. I did, eventually, persuade the chip to accept five functions which it carries out at the PICAXE's behest. It now won't accept any further functions (although it sometimes allows readback of the five already in there). The RS-232 line driver is a must (I had no joy with the resistor network at all) and I will admit I have not tried the AXE232 download cable as yet.

Ian
 

westaust55

Moderator
@Ian,

Welcome to the PiCAXE forum.

Certainly there is a need for signal inversion and while a MAX232 type chip can be used, I found using a couple of logic gates from a 74HC04 hex inverter worked well.

With respect to your problems downloading/reading function blocks into the user program space, are you ensuring that the TSin pin is held at the correct level prior to power up of the FPU to enter programming mode. That is high for "normal" operation and low to enter Debug/IDE mode (to program function blocks).
 
Thanks for the welcome.

I was aware of the requirement to hold the TST pin up at 5V initially. I haven't checked this on my setup but I believe the RS-232 / Max 232 does this anyway if the connection is idle.

Generally I can read the registers via the link, although sometimes both the umFPU and the PICAXE lock up if you pester them repeatedly. But it has been very reluctant to accept functions and usually the IDE says "no response from chip." I have tried two different USB to serial adaptors and two different MAX 232's.

The only thing I can think of is that when I was connecting it initially the adaptor forced 15V straight into the TSTIN pin which has caused some internal damage. It is fairly unusual for a serial link to fail in this way: usually they work, or they don't work, with nothing in between.

I use PPJOY (a freeware virtual joystick program) to simulate a game controller within the target PC: the PICAXE sends a sync byte and three position bytes, and three virtual joystick axes are calculated. I have used two flight simulators with this setup. One allows cockpit views to be latched onto the joystick directly, but the other only allows tracking via TrackIR (fortunately GlovePIE has a TIR emulator). There is a fair amount of fiddling required to get the headtracking to work effectively: but once it's working, it adds a new dimension to the whole business of flight simulation.

Ian
 

westaust55

Moderator
The microMega FPU chips are in reality specially programmed PIC chips.
The inputs are typically TTL level input and the voltages applied should not exceed the supply voltage under any circumstance. From most PIC datasheets, the Absolute Max voltage on an input is Vcc + 0.3 Volts.

PIC chips (as used for PICAXE by Rev Ed) are fairly robust but if you have applied 15 Vdc to the TSIn pin then there is a fair prospect that the chip could be damaged even if only in part and thus unreliable.
 
I have now built a circuit board with a couple of serial sockets built in and a MAX232 ...... no issues with the original FPU (using the serial ports on the back of the PC) although I did manage to fry its replacement :(

The only thing I am struggling with now is the inclusion of comparisons within functions. This is useful when working out angles - at the moment the PICAXE is having to assess which quadrant the angle lies in which is a trifle clumsy. But it may have been covered somewhere in the above notes.

I also have a version 3 FPU ....... haven't done anything with it as yet.

Ian
 

westaust55

Moderator
Have not used the compare function myself, but I believe you need to use the LUCOMPARE command immediately followed by a check of the Status byte.
From the Status byte by checking bits you can determine:
  • If sign bit = bit 1 is set (=1) then A < B
  • If zero bit = bit 0 is set then A = B
  • If both bits are clear then A > B
 
It is not obvious how that function can be deployed in the IDE environment. This is one of the issues with the IDE - it is far from obvious what syntax should be used to include certain functions.

For instance the POWER function (which is used elsewhere in the headtracker project) has the following IDE syntax:

outputupload=power(outputupload,1.5)

but this isn't elucidated anywhere in the documentation (although the output code is detailed in the V2 instruction set document). OK, this example is hardly difficult but for the LUCOMPARE instruction (which seems to include a loop of code which is executed if the conditions are satisfied, much like If ...... EndIf in Basic) it is almost impossible to infer exactly what to type into the input side of the IDE. (It doesn't even recognise LUCOMPARE as an instruction).

Ian
 
I have now set up the V3.1 um-FPU and have ported most of the headtracking routine over to it. While it needs its own IDE editor, it is not too different to the V2 one. (edit - SEE BELOW)

Unlike the V2, branches, loops and IF statements are all supported and well-documented. In fact I have all the number crunching on board the V3.1 - all the PICAXE does is upload the IMU data and download the three positional bytes.

I haven't quite finished it yet but it seems to work more smoothly than the previous version - and is infinitely better than the original variation where the PICAXE sent its data to a laptop which ground all the numbers in Visual Basic before sending them on to the desktop.:mad: I think if you are dealing with trigonometry the 3.1 is the one to have - although it's appreciably pricier than the 2.

Ian

EDIT: All is not rosy - the (V3.1) FPU keeps resetting itself every minute or so. Any ideas anyone?
EDIT 2: If you run it on 4 volts instead of 5 this seems to cure the problem. I also noticed it gets noticeably warm in use, which is VERY unusual for a microcontroller. In terms of the headtracker, I have now transferred everything over and the improvement over the original is very apparent - much smoother and more responsive than the V2.
EDIT 3: The chip failed after about a week - for no apparent reason. I bought a replacement 3.1 which I tested earlier today - dead as a doornail, straight out of the box. I am going to try a third one, but am starting to have very limited faith in these processors.
EDIT 4: Third chip seems to power up (RESET message on power up works, and checksum / version number comes out ok) but none of the registers will program. My patience is at an end - I WOULD NOT RECOMMEND PURCHASING ANY V3.1 FPU - THE THREE I HAVE BOUGHT HAVEN'T WORKED.

Ian
 
Last edited:
Top