uM-FPU V3.1
- Thread starter oracacle
- Start date
BeastFromTheEast
New Member
There is a question mark over these V3.1 FPUs.
I have had three: one was DOA, one lasted about 4 days, and one wouldn't program (although you could read the registers occasionally). It's a real shame, as they are potentially a big improvement over the V2 co-processor.
Ian
I have had three: one was DOA, one lasted about 4 days, and one wouldn't program (although you could read the registers occasionally). It's a real shame, as they are potentially a big improvement over the V2 co-processor.
Ian
hippy
Ex-Staff (retired)
The V3.1 chips should be no less reliable than earlier versions or other digital chips.
It may be there is some issue with your hardware interface or your controlling software. That one worked for four days then failed and one works partly suggests this could well be the case. It is possible that later version chips are more sensitive to incorrect hardware interfacing or software issues than earlier chips which could lead to the impression that the chips are the problem when they are not.
BeastFromTheEast
New Member
Maybe, but I have used the same interface (MAX232 line driver) with the um-FPU V2, and programmed PICAXE chips through it, without any problems. I also tried reinstalling the V3 IDE twice (it is different to the V2 IDE).
Ian
i have 2 here and both seem to fine, even after one got hot and i thought i killed it.
any chance of posting the code you are using, heres a copy of a file i used to constantly increase image distance, and asked the FPU to read back the new answer, and worked fine for more than 10mins.
it maybe helpful if you try the code in the the pdf i posted, it works fine, altho when copied and pasted to the editor the formating is kinda funky.
it is worth noting that things like the FPU reset routine need to be run before you can start using it, along with the pause 10 after a sum to give it chance to finish.
however the most frustrating thing that was left out of the maker data sheet was the fact you have to point to the correct registery before reading back the data, i have not yet figured out, negatives and readbyte and alikes, i normally just use read float (fyi, when you load i have been getting results only after i added the fset0 to the initial loading of data)
any chance of posting the code you are using, heres a copy of a file i used to constantly increase image distance, and asked the FPU to read back the new answer, and worked fine for more than 10mins.
it maybe helpful if you try the code in the the pdf i posted, it works fine, altho when copied and pasted to the editor the formating is kinda funky.
it is worth noting that things like the FPU reset routine need to be run before you can start using it, along with the pause 10 after a sum to give it chance to finish.
however the most frustrating thing that was left out of the maker data sheet was the fact you have to point to the correct registery before reading back the data, i have not yet figured out, negatives and readbyte and alikes, i normally just use read float (fyi, when you load i have been getting results only after i added the fset0 to the initial loading of data)
BeastFromTheEast
New Member
All three of mine got warm - very, very unusual for a microcontroller.They also took about 100mA of current on standby which seemed extremely high to me.
I still have one of the V3 FPUs so I will give your routine a whirl and see if it wakes up.
thanks,
Ian
hippy
Ex-Staff (retired)
100mA does seem excessive, especially as the chip is meant to enter an auto-sleep low-power mode when it is not active doing calculations. Current consumption can be quite high but shouldn't remain at such highs if it's not doing anything or in standby -
http://www.micromegacorp.com/downloads/documentation/AN043-Speed and Power.pdf
A common cause of high current consumption and a chip getting hot would be an output shorted to a power rail or other output, or the chip configured wrongly so a controlling signal is driving an output rather than an input. That could cause immediate or longer term failure with use.
http://www.micromegacorp.com/downloads/documentation/AN043-Speed and Power.pdf
A common cause of high current consumption and a chip getting hot would be an output shorted to a power rail or other output, or the chip configured wrongly so a controlling signal is driving an output rather than an input. That could cause immediate or longer term failure with use.
mine got hot when all the floating legs were tied low with 1ks
the circuit needs to match the circuit of page 2 in the data sheet attatched to this post.
i have also noticed that it gets a little above ambient (ie you can feel it temp has increased with a finger) if you are making it work hard constantly doing maths without a break while @5v, no such issue at 4.5v
the circuit needs to match the circuit of page 2 in the data sheet attatched to this post.
i have also noticed that it gets a little above ambient (ie you can feel it temp has increased with a finger) if you are making it work hard constantly doing maths without a break while @5v, no such issue at 4.5v
BeastFromTheEast
New Member
That is the document I used to build the circuit for my 3.1's.
I notice in that wiring diagram the CS pin (#4) is held to Vdd. The link provided by hippy says this will lock the chip in sleep mode - presumably causing it to ignore any commands (or any attempt to interrogate it using the tst in and tst out pins).
Ian
EDIT: There appears to be an inconsistency in the documentation here as in the datasheet, holding CS high forces the chip to chip comms to I2C: holding it low enables SPI comms.
I notice in that wiring diagram the CS pin (#4) is held to Vdd. The link provided by hippy says this will lock the chip in sleep mode - presumably causing it to ignore any commands (or any attempt to interrogate it using the tst in and tst out pins).
Ian
EDIT: There appears to be an inconsistency in the documentation here as in the datasheet, holding CS high forces the chip to chip comms to I2C: holding it low enables SPI comms.
Last edited:
my pin 4 is held high, pin 9 low, pin 17 low, pin 14 high, pin 13 low, with a 0.1uf cap right next to 13 and 14. I2C resistor right next to the 28x2
i think it maybe best to take some of the information with a pinch of salt. while getting to a point were i could get some form of unsertandable information back from the FPU i reverse engineered their example code, and to be honset i dont think they tested it, simply due to the large number of code errors - but it was the only way i could make sense of what was needed for the FPu to work
i think it maybe best to take some of the information with a pinch of salt. while getting to a point were i could get some form of unsertandable information back from the FPU i reverse engineered their example code, and to be honset i dont think they tested it, simply due to the large number of code errors - but it was the only way i could make sense of what was needed for the FPu to work
BeastFromTheEast
New Member
I've dug out my sole remaining V3.1FPU and hammered it into my test board 
- was not expecting very much but it perked up straightaway, which I am moderately pleased about. (Existing wiring was unchanged).
I have no idea why it was not working before. It's missed its slot on the head tracker (where the V2 FPU continues to do sterling service) so I will have to think of some other nefarious job for it.
Ian
- was not expecting very much but it perked up straightaway, which I am moderately pleased about. (Existing wiring was unchanged).I have no idea why it was not working before. It's missed its slot on the head tracker (where the V2 FPU continues to do sterling service) so I will have to think of some other nefarious job for it.
Ian
BeastFromTheEast
New Member
I just had a look at the registers with the IDE software - didn't actually upload any code.
I have previously ported my headtracking program over to it - it was fairly straightforward, mainly as it supports loops and if .... else statements (which the V2 co-processor does not).
Ian
I have previously ported my headtracking program over to it - it was fairly straightforward, mainly as it supports loops and if .... else statements (which the V2 co-processor does not).
Ian
fair enough, it would cool to see a comparison to the the V2 co-processor for out an out calaculation speed
i wrote this (attatched) for finding prime numbers above 11, you know to pass the time (as you do)
i may purchase a V2 to bench compare the 2, but will have t wait for a couple of months due to finaces
i wrote this (attatched) for finding prime numbers above 11, you know to pass the time (as you do)
i may purchase a V2 to bench compare the 2, but will have t wait for a couple of months due to finaces
BeastFromTheEast
New Member
There may not be that much difference as I think both chips run at a similar speed.
When I was developing the headtracker I found the V3.1 allowed far fewer i2C calls to be made between the PICAXE and the FPU, because the 3.1 can handle loops and the V2 cannot - so when working out angles, the PICAXE has to tell the FPU which quadrant the angle is in, whereas the 3.1 can work it out on its own.
In fact, the 3.1 headtracker just required upload of the 8 raw data values (3 gyro, 3 accelerometer and 2 heading) and could work out the 3 output bytes without further intervention from the PICAXE.
I am trying to convert my 3 axis milling machine to CNC at the moment: it is a protracted job (and not being helped by my personal circumstances of having to change jobs and houses) but I can see the 3.1 playing a part in it somewhere.
Ian