I'm not sure but I think that offloading floating point from the Prop to an ARM, or any other device, will be slower than doing it on the Prop in the first place.
Doesn't it depend on what you're offloading. If you make a request to the ARM for every add, subtract, etc. then it will certainly be slower than doing the same in software on the Propeller. However, what if you offload an entire FFT?
Sorry Heater, my post wasn't too clear. David's take on it is what I meant. The ARM would perform a group of operations ( a floating point equation, an FFT, a table lookup, etc) and return a result. In some ways we already do a bit of that, even though we don't think of as such. An ARM chip displaying pictures, graphs, and other information from one or more propellers running machinery is one example.
It is all about to exit from the arm-chair ;-) We now have a basic design of a dual propeller board quickstart form factor and compatible. As the communication between prop and accompanion is serial, layout a few wires is no prob and we are free to use whatever pin due to the complete symmetry of the prop.
I can talk to the XMC1100 bootloader which very simply loads RAM and runs so it is necessary to load a Flashloader to RAM first and then load any Flash code. However running from RAM is not a bad thing either seeing that the Prop can load a file into it. My initial use is simply as an ADC but I when I get around to writing my ARM CM0 macro-assembler I will be able to assemble from SD and load'n'go. I expect to have a version of Forth rather similar to Tachyon running on this chip as well.
However since there is no hard reset pin for the chip I just use a little 5-pin SOT23 regulator with a shutdown pin. The good thing about the XMC1100 is that it is quite happy to run from 5V too. I'm just using the little 16-pin TSSOP for the moment but it still has the same 64k Flash and 16k RAM.
update: footprints are changed and verified, today we plan to order the boards for the first batch. As can be seen, using a 4 layer board allows dense mounting of the components, so there is plenty of free space. This gives the chance to expand the circuit. One idea is to place generic footprints to allow manual wiring of COI (components of interest). Any idea, what those components are? A I2C<->1-wire bridge? some type of sensor? Microphone? Audio amplifier? VGA? Proposals are welcome.
We identified the first COI: STM32F030RC Another ARM cortex M0, which seems to be better suited than the xmc and having a landing zone for this chip will open a way to implement a companion chip for the next revision.
We hope this board to be a platform to link the prop to the arm world. It starts from replacing the flash cost neutral and soon the wish was to have additional io. Selecting the xmc was not a good idea, as this chip has no crystal input, only runs from internal oscillator. ... but we have to come to a first materialization of the idea, therefor xmc will be present (firmware exists) and the landing zone for a larger chip exists. To solder a component is easy, to develop the firmware not so much.
To solder a component is easy, to develop the firmware not so much.
With PropWare finally at a release state, I feel better about taking on other projects. And the ARM world is something I've wanted to get back to for years. How can I help with the firmware side of things?
Another lazy sunday afternoon: Now the top side is a little more populated with dummy components to allow playing around...
Even if there is some unused place on bottom, the play must go on, so no more new feature. Design freeze.
Status update: boards are ordered, it will take another week. This link https://submesh.de:8080/rid=1PV32YLCY-248SQFJ-9G6/xmPropKit_Root.cmap brings you to a first block diagram. Currently the XMC only emulates flash, the idea is to use the resources of the companion chip completely, it needs discussion how this can be done best. Also of interest: how to communicate between the props transparently. In principle one should not know, which cog is located where.
Status update: boards are ordered, it will take another week. This link https://submesh.de:8080/rid=1PV32YLCY-248SQFJ-9G6/xmPropKit_Root.cmap brings you to a first block diagram. Currently the XMC only emulates flash, the idea is to use the resources of the companion chip completely, it needs discussion how this can be done best. Also of interest: how to communicate between the props transparently. In principle one should not know, which cog is located where.
When you say "XMC only emulates flash" are you really saying it emulates EEPROM? No flash is required to boot P1. Also, how can it be transparent which chip a cog resides on when cogs on the same chip share the same hub memory but cogs on different chips do not? And you pretty much need to use hub memory to synchronize operations between cogs.
As of today, the XMC's firmware is running i2c in slave mode and using upper 32 k flash of 64k to respond to i2c commands by simulating a 32 flash memory So P0 can be booted via tx/rx, the propeller stores the code to "the flash" and in a follow up reset can boot from this "flash".
But the is no other function implemented into XMC's firmware, ideas are: use as an i/o expander, ADC, ...
Cog2Cog communication I use in a standardized way with help of pointer tables placed in HUB. In a first try I mirror variables via serial transmission from hub to hub, whenever content is changed in one Prop, so the cog running an program and writing and reading hub memory actually doesn't know, in which hub of two propellers the actual data resides. Currently the mirror and communication process takes two cogs, which is a waste of resources, but improvement is on the way
As of today, the XMC's firmware is running i2c in slave mode and using upper 32 k flash of 64k to respond to i2c commands by simulating a 32 flash memory So P0 can be booted via tx/rx, the propeller stores the code to "the flash" and in a follow up reset can boot from this "flash".
But the is no other function implemented into XMC's firmware, ideas are: use as an i/o expander, ADC, ...
As soon as I get my hands on one of these boards, I can help develop some of that firmware. Sounds like fun . I'll look into getting a toolchain set up on my machine.
Cog2Cog communication I use in a standardized way with help of pointer tables placed in HUB. In a first try I mirror variables via serial transmission from hub to hub, whenever content is changed in one Prop, so the cog running an program and writing and reading hub memory actually doesn't know, in which hub of two propellers the actual data resides. Currently the mirror and communication process takes two cogs, which is a waste of resources, but improvement is on the way
Are you using Beau's Spin/PASM library for that? Sounds like exactly what he does.
I was just looking to the history and found this thread: forums.parallax.com/discussion/123630/inter-process-communication where I presented the method briefly and not really clean. I will try to find the references and start to make updates. This is only for cog to cog communication, not interprop.
And I just couldn't wait so I fixed the stencil, printed solder, placed the parts, heated with an air gun, ... and: here we go! Currently only one side, no crystal, no flash, but: the feeling of success!
USB is working, propeller detected. Enough just for now.
Now the back side is populated also, featuring the XMC 1100, Propeller, SD-card (4 data pins), and a freely available HDMI-connector as a cheap way to connect to arbitrary devices using preconfigured cables. The 10MHz crystal is a little big for the footprint, will be changed in next revision.
The lower propeller's pins go to the pin header, the upper propeller's pins to the socket header. Only some signals are in common
End of the next week we will have 10 boards. I plan to distribute 5 of them. There is no price fixed yet, as they are prototypes. PM me whoever is interested.
End of the next week we will have 10 boards. I plan to distribute 5 of them. There is no price fixed yet, as they are prototypes. PM me whoever is interested.
I'd love one but I guess I'll wait for them to be for sale because I can't guarantee that I'll have time to do much with it right away.
Comments
Sorry Heater, my post wasn't too clear. David's take on it is what I meant. The ARM would perform a group of operations ( a floating point equation, an FFT, a table lookup, etc) and return a result. In some ways we already do a bit of that, even though we don't think of as such. An ARM chip displaying pictures, graphs, and other information from one or more propellers running machinery is one example.
I think XMC come in 200k Flash models ?
However since there is no hard reset pin for the chip I just use a little 5-pin SOT23 regulator with a shutdown pin. The good thing about the XMC1100 is that it is quite happy to run from 5V too. I'm just using the little 16-pin TSSOP for the moment but it still has the same 64k Flash and 16k RAM.
Then running the Espruino JavaScript engine on it would be a dead simple flashing of the available Espruino binaries.
I know, nobody likes JS. But the Espruino is a lot of fun and is practically useful as it has code available for all kind of peripheral devices.
With PropWare finally at a release state, I feel better about taking on other projects. And the ARM world is something I've wanted to get back to for years. How can I help with the firmware side of things?
Even if there is some unused place on bottom, the play must go on, so no more new feature. Design freeze.
But the is no other function implemented into XMC's firmware, ideas are: use as an i/o expander, ADC, ...
Cog2Cog communication I use in a standardized way with help of pointer tables placed in HUB. In a first try I mirror variables via serial transmission from hub to hub, whenever content is changed in one Prop, so the cog running an program and writing and reading hub memory actually doesn't know, in which hub of two propellers the actual data resides. Currently the mirror and communication process takes two cogs, which is a waste of resources, but improvement is on the way
As soon as I get my hands on one of these boards, I can help develop some of that firmware. Sounds like fun
Are you using Beau's Spin/PASM library for that? Sounds like exactly what he does.
USB is working, propeller detected. Enough just for now.
The lower propeller's pins go to the pin header, the upper propeller's pins to the socket header. Only some signals are in common