If everything goes like expected, some board will be available to sell. A price is not determined yet, as those are prototypes and the boards and assembly is quite expensive. We will see, related to the work that has to be done in development of firmware, the hardware just doesn't count. ;-(
The boards have arrived. Now we will check all functions and test Cluso99's Prop-OS. Flash XMC firmware (must be adopted to the newly selected chip) and ...
I was just re-reading some of your early posts about this trying to figure out how you intend this to be used and notice that you say the ARM has 64k of flash and 32k of that will be used to emulate the EEPROM that normally is used to boot the Propeller. Is that correct? Did you overlook the fact that the actual QuickStart board has a 64k EEPROM and that many applications depend on using the upper 32k for data storage? How will you handle that on your module?
This is a weak point, resulting from selecting the XMC. With the next revision we will switch over to a ST324F410, which is already placed in the "landing zone", but not connected. This chip brings much more features and is a better companion for our GOP (good old Propeller)!
This is a weak point, resulting from selecting the XMC. With the next revision we will switch over to a ST324F410, which is already placed in the "landing zone", but not connected. This chip brings much more features and is a better companion for our GOP (good old Propeller)!
XMC is flashed with the initial version of the flash emulator, that means: the first propeller can use the XMC as 32k flash. Next we boot the second prop from the first and try to install Prop_OS.
Nuvoton: OK, I have to confess: fighting hard in hopeless situation doesn't mean, I am brave, only: lightheaded. So, in this case I can't imagine to rely on another new chip, that is not open source and where I don't now the people behind. Event with ST I am not absolutely confident. ;-) After the infineon experience I prefer know to sail in calm waters ;-)
In my history I several times run into problems, just because parts didn't do what was expected or described. With the propeller you have a system that is open in this manner: you can do everything in software and the opcodes are complete and orthogonal. So you can do, what is possible. With the XMC e.g. you are bound to what the designer thought do be important and what he could do in the time line. I2C for example can be configured to accept every device address, so after the device address is read, we supposed, we can decode following information to emulate different devices. But it turned out, that the interrupt can not be switched on the fly, so in the end, those effords failed. With the propeller we would not run into those problems, because you are indeed free to do, what you want and the only limits are speed and memory. Therefore I will never switch over to chip from a new company when there is a proven and accepted alternative to save a $. My brain is just limited ;-)
This is a weak point, resulting from selecting the XMC.
If you already have XMC code working, and more code is an issue, (& you prefer to avoid new MCUs) why not just use one of the available 128k or 200k versions of XMC ?
At most, that is just a package change.
Quite simple: the xmc didn't keep, what it promised, so I am a little disappointed. Next: the st is just cheaper. The xmc-code is written in C, most is portable. Those parts, specific to XMC (mainly USIC) is worth to be thrown away! OK, you see, I'm not really friend to the chip family ;-) Also ST chips are more familiar to most, so the entry threshold should be lower. But: most value comes from the prop and the goal of this development is to create a grid of props. ARM is only a companion.
I2C for example can be configured to accept every device address, so after the device address is read, we supposed, we can decode following information to emulate different devices. But it turned out, that the interrupt can not be switched on the fly, so in the end, those effords failed.
I'm not following ? You have this working ?
I have found most MCUs i2c hardware to be something of a pain to work with, as they seem to all use a State engine design in order to implement the i2c Slave operation, and user software is forced to follow whatever state sequences the designer chose.
Erna,
I am very pleased that PropOS is working for you. If you have any questions please ask.
I have a new version coming.. just trying to find an elusive bug.
I use a separate boot program that no longer relies on the OS. It is also posted on the PropOS thread. This means that it does not require updating when the OS gets updated.
Indeed, there are many questions. I understand, you are moving Michael Parks compiler to the prop. That means, we could finally have a self contained system. I remember when he presentes Sphinx system at the first UPEW. I couldn't believe this to be possible and it was so far ahead of what I did. My feeling is, we can forge everything together. But the timeline is tough, as we have to be ready before Chip finishes P][. The race is open ;-)
No, we could not switch the slave address on the fly. But it looks we were the first to use XMC as an slave, there was no demo for this mode to find (what in the end was better). Now we plan to memory map the functions. Means: lower 32K address emulated flash, higher addresses address dedicated functions, but that is to decide.
I can not imagine to have a second batch of revision A boards, as potential users are all bound to P][, what is good, and Rev B now will take some time.
First call for contribution: This moment 4 boards are available to be send to those, which believe they can contribute. We will send them to Parallax and Ken agreed to distribute them by local postage. I can imagine, Parallax will keep one to tear down ( ;-) ), so three are free to give away. Numbers may change a little.
We are in a brainstorming period. One contribution is to use tools consistantly. As I know many drawbacks of the propeller, this is true for CMapTools. But to me it is the best known way to share ideas and knowledge and to support colaboration. So before I think about work to be done, I would very much appreciate to find someone who gets aquainted with said software. Just ignoring, it is JAVA.
I own spinneret boards, but never used it. Now I start to analyze spinneret hard and software to see, how to move it to PRIME and the Parallax Quickstart compatible Ethernet board. In the end I wish to have a real plug and pray system, where not software modules are connected by linking, but by attaching hardware blocks running those modules. An old dream of mine.
In the meantime I have discovered, how many OS developments were started, but nobody can say: mission accomplished.
No, it is a tool to draw concept maps, something similar as mindmapping, but not limited to hierachical data, but also for networks. It's from IHMC at Pensacola university. I like it, also because children can use it. cmap.ihmc.us/
I would very much appreciate to find someone who gets aquainted with said software. Just ignoring, it is JAVA.
I'm a good Java developer, but I suppose that only matters if we're hacking on CMapTools itself right? Or is CMapTools a library which is used for programming maps (as opposed to what I imagine it being: a graphical tool that can be used to draw maps).
Is this the right stuff? http://cmap.ihmc.us/cmaptools/
Currently I am looking to spinneret and to support my brain, I created this maphttps://submesh.de:8080/rid=1PX9YMW8F-SJ3Y7B-LML/Spinneret.cmap Here you can take a first look. But if you have installed CMaptools, you can open the map and edit. OK, I never tested it, but I believe, there is also a web interface! (it looks as if this only works in a cloud)
But if you give it a try, I PM you information how to gain access
Quit simple: I'd like to see progress in creating a operating system for the propeller. Up to now some solutions exist, but they are rarely used. I believe that the prop needs a OS that is distributed and delivers services. How to do this is not defined. But different ways are sketched, now they need plaster. I have different stones lying around and try to fit them together. By documenting the progress (hope not to run in circles) your question may be asked.
Quit simple: I'd like to see progress in creating a operating system for the propeller. Up to now some solutions exist, but they are rarely used. I believe that the prop needs a OS that is distributed and delivers services. How to do this is not defined. But different ways are sketched, now they need plaster. I have different stones lying around and try to fit them together. By documenting the progress (hope not to run in circles) your question may be asked.
Ah, that helps a lot. Thank you. I will ponder on this for a while and peruse your existing documentation. Seems like a lot to bite off right away, but I'm sure it will become more clear once I look at what you have already completed. If I can find a small bite to start with, I may give it a go.
I believe that the prop needs a OS that is distributed and delivers services.
This certainly sounds appealing. The trick will be to find a very lightweight way of doing this. The Propeller has very limited memory for an 8 core processor so finding a way to use it efficiently but still provide a powerful framework will be tricky. You say you have some ideas in mind. Is this what you're using CMapTools for? Are there any documents you can point to that outline your current approach?
I moved the cmaps to another server and the links are broken. And all this work was running at low priority. Now it pops up and step by step there will be updates and improvements. Currently I do not care about resources as I can attach a new propeller every quarter of an hour is I save the time squezzing the code. So we will see, how things are going
Comments
http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1577/LN1938
There is also this family
http://www.nuvoton.com/export/sites/nuvoton/files/product-related-information/M451_Brochure.pdf
Comes to 256KF, and has Wide Vcc and allows level shifting interfaces, which could be very useful in a 3V prop.
Could open some Stamp targets ?
PR claims "The NuMicro M451 series starts at the competitive price of 0.89 USD per unit (M451MLC3AE)." ( 40KF ?)
Downside is this family is quite new, so not easy to get yet. Digikey stock Nuvoton parts
Nuvoton: OK, I have to confess: fighting hard in hopeless situation doesn't mean, I am brave, only: lightheaded. So, in this case I can't imagine to rely on another new chip, that is not open source and where I don't now the people behind. Event with ST I am not absolutely confident. ;-) After the infineon experience I prefer know to sail in calm waters ;-)
I'm not sure where you find a new chip that is open source, but if you meant the tools, then look at
http://www.coocox.org/
that Open Source tool chain, supports both STM32 and Nuvoton parts.
http://www.coocox.org/code/home.php?componentId=206&componentName=M451
http://www.coocox.org/code/home.php?componentId=263&componentName=STM32F410Cx_CUBELIB
At most, that is just a package change.
Even Prop, which has quite limited capture features on the Timers.
I'm not following ? You have this working ?
I have found most MCUs i2c hardware to be something of a pain to work with, as they seem to all use a State engine design in order to implement the i2c Slave operation, and user software is forced to follow whatever state sequences the designer chose.
I am very pleased that PropOS is working for you. If you have any questions please ask.
I have a new version coming.. just trying to find an elusive bug.
I use a separate boot program that no longer relies on the OS. It is also posted on the PropOS thread. This means that it does not require updating when the OS gets updated.
I can not imagine to have a second batch of revision A boards, as potential users are all bound to P][, what is good, and Rev B now will take some time.
I own spinneret boards, but never used it. Now I start to analyze spinneret hard and software to see, how to move it to PRIME and the Parallax Quickstart compatible Ethernet board. In the end I wish to have a real plug and pray system, where not software modules are connected by linking, but by attaching hardware blocks running those modules. An old dream of mine.
In the meantime I have discovered, how many OS developments were started, but nobody can say: mission accomplished.
Cool! I know what those words mean!
I'm a good Java developer, but I suppose that only matters if we're hacking on CMapTools itself right? Or is CMapTools a library which is used for programming maps (as opposed to what I imagine it being: a graphical tool that can be used to draw maps).
Is this the right stuff? http://cmap.ihmc.us/cmaptools/
But if you give it a try, I PM you information how to gain access
Ah, that helps a lot. Thank you. I will ponder on this for a while and peruse your existing documentation. Seems like a lot to bite off right away, but I'm sure it will become more clear once I look at what you have already completed. If I can find a small bite to start with, I may give it a go.