Next Gen Prop timeline?
Jeff Pagel
Posts: 1
Has there been any talk of a timeline for the next Propellor?
Months, Years, Anything?
I am specifically interested in the 'security fuse' talked about in the 'Protecting IP' threads.
Thanks.
Months, Years, Anything?
I am specifically interested in the 'security fuse' talked about in the 'Protecting IP' threads.
Thanks.
Comments
It's been made clear that there will be no more revelations of features that will be included and there's
been nothing said about whether there will actually be any IP protection features.
The Propeller is one of the most exciting things to have happened to micro-controllers in a while!
Most microcontrollers try impressing you with the number of timers and if it has and ADCs on board.
The propeller does it with Video generaters, large 32k of on-chip memory (large for a MCU) timers and counters good for ADC and DAC. [noparse]:)[/noparse]
Over a year later I'm still impressed by this small little package.
If there was one thing I would like it would be more RAM, but I'm not going to start beating that subject to death again. *lol*
See parallax out did themselfs. By making a micro-controller so interesting and powerful... It's no longer seen as a micro-controller all together and more like a small computer platform.
The propeller is like the cross over point.
--Andrew Arsenault.
I don't know if what I do is typical, but I have six of the cogs in my application each running a different piece of assembly code. The assembly cogs are loaded, started, and then run forever.
If the DAT sections containing the assmbly code could be collated, then once all the cogs have been started that memory could easily be re-used as a contiguous block of free memory (especially if it was placed at the end of the memory map!).
Doing this would probably require a new section eg. ASM as opposed to DAT. This is so that blocks of data, or assembly that may be re-invoked at a later stage can be excluded from the collating mechanism.
Supporting all of this, it would probably be easy enough for the compiler (Propeller Tool) to generate some magic variables along the lines of clkfreq:
StartOfASMBlocks
EndOfImage
EndOfRAM - which is obviously a constant at the moment.
Any thoughts?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you use a 64KB EEPROM(or an additional EEPROM), store just one of them in the Data section, then when you've activated it and don't need the block of code anymore, load the next one from the upper portion of the EEPROM and store it in that same Data area. Boot the next COG with this code, rinse, repeat...
Should save you a fair bit of space...
(I think... haven't tried it myself)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Allowing 'pointers to functions' and being able to use them could also remove a lot of otherwise unnecessary code overhead.
It would be convenient if 'if var <> 0' could be optimised to just 'if var', and 'var := 0' / 'bitVar := 1' could be optimised to 'var~' / 'bitVar~~' as appropriate if that would save space. That could also automatically give best optimisations for 'var := K' where K were a constant, 0 or 1. ( I'm in the wrong OS at present so cannot check what the Propeller Tool actually does in these cases, so apologies if already implemented ).
The main issue I have is that without conditional compilation directives, any debugging code has to be physically commented out to regain space, simply putting it in an 'if DEBUG' doesn't optimise away unused code. Without conditional compilation it's not easy to switch between small arrays during debugging and larger arrays for production releases as an example.
It's also a royal pain when trying to create a single object which delivers functionality for two different applications.
I haven't run into this problem with the Propeller yet, but where there's no room to include all debugging code together, one ends up switching between selections of debugging code. On the Propeller that could be an awful lot of editing in various object files.
It would be nice if the Propeller Tool could remove PUB and PRI methods which are not called. PRI in all cases, PUB perhaps only in the top-level if doing so in sub-objects presents a problem.
That only works in the limited cases where a Cog is only ever loaded after a re-boot ( after that it's assembly code would have been overwritten ), but for such a case, then yes, I'd agree.
Adding some 'align to boundary' statement for DAT would be useful. At present it is necessary to prefix a padding array of worse-case size in all cases, and that's most often wasteful, plus it incurs an extra longmove or wordmove to ensure runtime alignment, plus an overhead to ensure that is only executed once. A means of being able to easily tell where data had been placed would allow data to be manually re-ordered to achieve minimal memory usage.
Functionality seems to rule at Parallax... and Parallax does seem to have a reasonable approach to the kinds of functionality that they will accept.
After about a year of lurking and posting, I am still convinced that: "Whatever cannot be done with one Propeller can probably be done by two or more Propellers."
Many times solutions are not obvious to us. What I would suggest is that if anyone has a real world problem, for which the Propeller seems inadequate, post it as a challenge. If it is important enough... there is probably a way to do it... very inexpensively.
I am very interested in the timeline for the next demo board... any leaks out there?
Rich
Viz. good ideas but however much they are in a state of to add a simple function to the manual management of Com of ports where Tools must send it think that are in a state of to add such developed ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
I think we all appreciate there are many things happening within Parallax, many things competing for resources, and many priorities. It can however be frustrating when our priorities are not the same as Parallax's.
Perhaps we need an 'ideas and suggestions' box for the Propeller Tool where all things we would like to see could be collated together, and what the most important changes perceived could be identified ?
My problem is it that Propeller is not what I only work with on my computer.
And automatic search disturb to me action of other programs which are to me necessary.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
For suggestions to the Propeller tool, it could be best to e-mail Jeff Martin directly (jmartin@parallax.com). With his workload we don't expect him to be able to read everything on the forums. He's receptive to input from our customers so please feel free to contact him directly.
As for the next version of Propeller, please don't expect it for a year or three. Even the shortest time period I quoted is not likely. Based on what I observed with the first Propeller design process, and how portions of the device are still undergoing design changes, it'd be useful for all of us to work with the "A" version for now without holding out for the next one. Your experience will be transferrable.
Sincerely,
Ken Gracey
There was a good method to terminate discussions on a theme Propeller Tools.
But or for you that familiarity one what this second does?
I said about problems to Paul and had a hope that it will reach the proper person as soon as it is a that enterprise.
Ps. I still wait to have answer from he.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
I'll alert Jeff to this forum thread and I'm sure he'll read it. We'll do the best we can to address the COM port issue and other suggestions, trust me. Just recently we've been able to offload at least four tasks from his workload to other engineers in Parallax, with the sole purpose of increasing the time for Propeller IDE improvements. From a management perspective we're aware of the resource limitations, and from a technical standpoint we can count on Jeff to address the key technical points in order of priority. He's been doing that properly for 11 years already.
Sincerely,
Ken Gracey
Thanks.
For guick replay.
There are hopes that you will decide this problem.
There are a few anxieties with Propeller Tools but that would untie part of those other.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Thanks for your input; as Ken indicated, it is all appreciated by me.
I keep track of a lot of suggestions for things like the Propeller Tool and address them as soon as possible.· Recently my task list is changing in great ways that will ultimately lead·me to focusing on the things we all want me to focus on (the Propeller and BASIC Stamp tools and documentation).
There are a lot of significant enhancements on the way, I assure you.· And they will start occuring more frequently, soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Jeff Martin
· Sr. Software Engineer
· Parallax, Inc.
Thanks for replay
Com port a problem must be as first.
Simple function to the shutdown of Autoscan and elections of port manual.
I have one more problem but this I email to you in the nearest time
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha