I've just run across this tasty little sucker on the Flex mailing list:
formatting link
In summary: 32-bit IEEE 754 floating point operations, 32-bit long integer operations, uses both I2C and SPI interfacing, provides a serial interface as a debugging aid and for general use. Application notes are available here:
formatting link
There's also a newly announced 64 bit version.
Picaxe
formatting link
is the UK agent and is flogging the 32- bit version for a tenner. I wonder if anybody has built an RPi expansion board for it yet.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Not sure why you would - I'm fairly sure the Pi will be faster. Much faster. (Even without the GPU)
These are really aimed at small embedded devices - ATmega/PIC etc.
Factor in the time to serialse the data and send it to the device, along with a "program", get the result back again and you could probably have done 10x the calculations on the Pi.
But on an 8-bit microcontroller - then you'll have an advantage as all the floating point calcs would otherwise be in software...
Having recently dealt with an FP coprocessor interfaced to an 8-bitter, I can confirm that the time required to communicate with the coprocessor totally dominates the actual computation time.
And while the speedup on divide and transcendentals is significant, FP add and subtract are not much faster than good software after communication is factored in.
--
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon
Does this imply that there's an appreciable overhead in talking to
*anything* via I2C or SPI?
As well as attaching this coprocessor to an RPi, I'd wondered about using it with an existing 6809 system to provide a fast serial port, possibly linked in turn to a serialethernet adapter such as a Lantronix Xport or a Radicom LSHM-200 so the old box is accessible via telnet. Or is this a really silly idea?
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Yes. I2C runs at 400KHz in 'normal' mode. For most one-off transactions you need to write address+data, so you're looking at about 40 bits to transfer a 32 bit payload. So that's about 100us just to make the request. Meanwhile your 16MHz processor could have executed 1600 instructions.
SPI is quicker (~20MHz) but you still only get one bit per clock cycle.
Why would you want floating point in a serial port?
Anyway, staring at the datasheet a bit, there are various hints that this is just a PIC programmed up with some firmware to do floating point. At a guess it's something like dsPIC33FJ12GP201 which has roughly the right pinout.
Yes, the market for this part has got to be small. There are medium sized MCUs that come with IEEE floating point built in. Rather than glom a floating point coprocessor onto a small MCU, why not just use an MCU that includes it? I suppose you can add an SPI peripheral to an existing board but this device is so slow it won't be a good fit for many projects.
I was originally pointed at a advert fro these chips on the Parallax site: as well as AVR, the Parallax Basic STAMP units are also slow enough to benefit from these chips. The fact that PICAXE is the UK agent should also have been a clue about comms overheads.
Thanks to all who responded for confirming that I2C and SPI data transfer is even slower than I realised.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
But it depends if you use the kernel SPI driver or if you "bit-bang" the hardware directly.
Using the kernel, there is a somewhat high startup latency which results in a limit of just over 8K transactions/sec. The bus itself can be clocked at 32Mb/sec (maybe more, but that's the fastest I've found reliable), but lots of small transactions kill the effective throughput.
You can get a lower latency if you poke the hardware directly - at the expense of more CPU cycles to stuff the data into the FIFO, monitor the signals, etc.
The Pi also has an odd feature in that every 8th clock pulse is "stretched" by about half a clock. This doesn't affect the data transmission as its synchronised to the clock, just adds on half a bit more time per byte.
I2C is better, from my "quick & dirty" tests the latency is lower, but so is the clock speed - 100Kbps, although I have run the Pi's I2C at up to 1.2Mb/sec - it's a somewhat interesting signal at those speeds...
Not sure how a FP chip would implement a fast serial interface, but if you want Ethernet on an 8-bit micro, I reckon its better to off-load it to something designed for that purpose - e.g. a Wiznet module, although these run on SPI, so having a micro with a good SPI interface seems a good idea.
The background to this idea is that I still have a 6809 box I built in
1979. It runs the Flex OS on top of my own rombug firmware and uses the SS-50 bus architecture. Its main drawback, seen at this distance, is that its terminaal I/O is via an ASCII-parallel keyboard attached to a PIA and a memory mapped (24*80 6845-based) display that feeds composite video to a monitor. Its only other i/o port is another PIA interface to a printer, so as far as getting data to or from its disks go, its a bit of a locked box, bit does have one vacant SS-50 slot. I'm looking at ways of filling that with, preferably, a ethernet interface as simply as possible. The obvious way would be to add an ACIA connected to a Lantronics Xport. Supporting it would require extensions to the firmware, but there's space in the EEPROMs for that.
In parallel, as an alternative approach, I'm writing an Linux emulator that should be able to access both the native Linux filing system and Flex disk images which I'm fairly certain can be made with a combination of dd, fdparm and the standard floppy drivers: I've used this approach to read OS/9 disks in the past. Any comments or suggestions will be gratefully received.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
I did use a 6809 + Flex system way back - probably 1980 or so...
The only suggestion I can think of is that the hardware won't last forever, so looking at an emulator might be a good idea - sooner rather than later... You could use the parallel port to dump the disks to a Linux box, I guess, but adding in a serial port might be handy - then you could simply use a USB serial port off a Pi to connect into it - assuming you can do the neccessary changes to the EEPROMS to run off a serial terminal rather than the on-board one..
(and then use ye-olde kermit, etc. to dump the disks up to the Linux side)
Saying that I have a couple of old Apple II's that are still going strong, although a 3rd lost the magic smoke from its PSU a while back and I've not opened it up to change the capacitors out yet...
My SSB 6809 running OS/9 still works :) As does my BBC B. My Archimedes A310 died, as did my Risc PC. I Think the quality of electrolytics declined during the 80's.
The quality of electrolytics back in the late 70s was terrible. By now they've all leaked of the electrolyte has dried out. Modern ones would appera to be a lot better. I have a Quad 33/303 stereo system I bought in the late '70s which began to sound horrid about 8 years ago so I took it back to IAG (the Quad successor company) for an overhaul which, they told me, basically amounted to replacing all the electrolytics. The transformation in sound quality was remarkable.
I'm certain that exactly the same thing will apply to any and all electrolytics in old computers.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
It would be a damn small library: the BS2 STAMP has storage for only around 600 lines of code and 32 bytes of RAM. The BS1 is smaller in both departments. Maybe there are more capable STAMPs now: I haven't looked at them for a while. If I needed similar capability now, I'd use a PICAXE because they are smaller, lighter and have a bit more useful 'stuff' built into them. Small and light is important because they'd be used as multi-function timers in small high performance free flight model aircraft.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
On Wed, 27 Aug 2014 21:43:47 +0000 (UTC), Martin Gregorie declaimed the following:
What is modern? My 6-7 year old Samsung 40" LCD TV started taking multiple reboots before being 4 years old, and finally reached the stage where it took over an hour of power-cycling before the display would be clear of "fixed" pixels. 18 months ago I took it into a shop (I'd delayed so long as I'd run out of unemployment benefits a few months prior -- and finally received a job offer)... They replaced 5 electrolytics...
A year later, the even less aged sub-woofer started buzzing... Another set of electrolytics...
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.