The Prop may not be worth the added trouble, but it's important that you don't conceptually add trouble where it really doesn't exist. Nobody claims that the Propeller is the solution to almost anything, but it seems to be well designed and built ... you may not agree with some of the design decisions made, but they were not made arbitrarily. The company is in the business for the "long haul" and has a real history of doing so.
Some people in this community have a thinner skin than others. We all try to keep discussions civil, but we all have "hot buttons". In addition, the forum structure is not the same as a conversation and things meant one way may be misunderstood. Be patient, be gentle, try not to be too dogmatic, Read and re-read what others have said and read what you've said in reply before you click Post. It helps.
A detailed I/O block schematic really wouldn't be helpful for the sorts of things you're interested in. The components that would be used don't exist the way you might think of them. There are also a lot of "parasitic" relationships, both thermal and electrical, that wouldn't show up ... another part of the transformation from a chip layout to a functional schematic. I suggest you make up a list of the sorts of things you need ... in priority order ... and send a private message to Beau Schwabe about them. He may have some informal measurements that you could make use of. I'm thinking of things like output voltage high vs. current output or output voltage high vs. chip temperature and supply voltage. These are things that are very resource intensive to do formally where you need to sample chips and characterize them over a wide variety of conditions, but he may have done some spot checking that he could share.
BTW, Parallax does have a "shrink ray" in the form of an electron beam probe that was used to debug the Prop. You might read "Why the Propeller Works" here if you haven't already.
my thinking behind the schematic would be to see the values of represented components (on die) and then simply do the math to find their collective resistance at the tip of a pin (which I could then add to the resistance of my traces, on up to the next component and so on......)
it is pretty common to be able to do that for other IC's and that information is available from most other manufacturers.....TI is really the best about it (including full on die schematics of ALL replicated components)
now if someone was willing to simply tell me the ambient shift in resistance, and it's equivalent output voltage swing....well then that certainly saves me a lot of trouble....and would be most appreciated (i might even send that person a dozen roses)
this was my concern about standard deviation and what are the acceptable shifts/swings......I know that it is virtually impossible to provide a fractional percentage of consistency in a $8 chip.....for that we need to employ aerospace technologies and possibly a security clearance (half joking) , and I have looked into those resources.....I can't afford to build a $3000 micro-regulated power supply.....in terms of sanity, expense and practicality......unless a few of you offer to buy one from me (har har)
It provides a quick way to implement a thermostat:
tooHotfan := temperature >= 79 ' turns on fan when temperature exceeds 79
Yes, but it also modifies temperature, replacing a quantity with a Boolean, which is almost never a reasonable side effect. In most cases, the following would be more appropriate:
tooHotfan := temperature > 79
unless you really wanted temperature to be changed to 0 or -1 in the process. Also, > works if temperature is a method call; >= does not.
Easy mistake. Happens. (happens too much sometimes, and usually when I go some time between prop sessions)
Completely agreed on a quantity being changed to a boolean, but then again, it's all just bits, right? So then, just knowing that's gonna happen is the key thing. What people do with it may well pay off, and I suppose that's my greater point. Better to have the tool than not.
Of course, that runs counter to our long running, "make spin easy for newbies" vs "make spin powerful" discussion we've had over the years Phil. On that note, I agree with you, but am glad it's in there just the same.
One of the things that's different about semiconductors compared to other types of components is that things vary widely from part to part. In something as simple as a transistor, the gain can vary by more than an order of magnitude. Often that's spec'd only in terms of a minimum. You simply have to design on that basis and choose your circuits so the variation gets swamped by passive component values that can be more tightly controlled.
I think you'll find that the values shown on microcontroller's datasheets are, in general, ideals ... only approximations to the actual values on-chip and that those values vary widely, are temperature sensitive and often supply voltage sensitive. The reason why you're getting so much resistance to the idea of a schematic is that it's only a very coarse approximation to what is present on any given chip and you can't really do what you describe (figure the on chip values into calculations of circuit behavior) unless the particular values involved are laser-trimmed or somehow measured on a per-chip basis.
No, that was directed your way Ari. COG start time is significant, as is fetching overlays. LMM helps here, because it's possible to execute and fetch at a low latency, requiring only a small kernel to be running in what I like to call the "supervisor" COG. That supervisor can provide services to the running LMM program, which is really just a subset of PASM residing in the HUB, instead of in the COG. Services could be threading, I/O, math, etc... The resulting program is PASM, with custom opcodes, understood by the kernel. Necessary for jumps at a minimum.
I don't understand how the "allocator" could reside in central memory. The only place things are executed is in the COG space. Everything else must either be fetched into the COG, using a HUB operation (LMM), or pins (XMM), or interpreted byte code style (SPIN, others...). Unless that allocator is really just one COG acting as the control COG, which is probably what you meant.
As for the code in the OBEX, it's MIT, so do what you will, but also do consider contributing back to the pool for others. That's the default expectation with the OBEX and the code found there.
You can shave some time off the COG init time with a higher clock. The reference clock is 80Mhz, but our shared experience basically shows Propellers running nicely at 100Mhz. Parallax sells some 6.25 Mhz xtals for this purpose. (thanks Bill Henning for pushing that). The alternative is probably 96 Mhz with a standard 6Mhz xtal.
Just talking Prop stuff. That's what we do. Not a challenge, or anything else. You will find this group kind of synergistic that way. It's natural for people to toss in what they know, because there is a lot of interesting things to know, that might not be obvious at first glance, compared to a more traditional CPU. That's all.
In particular, the idea that programs only execute in the COG memory space is worth noting. It's missed by a lot of people new to the Prop, as is the init time. One of the most common misunderstandings is that HUB / COG relationship, with the idea that the COG executes directly from the HUB, which is why I wrote what I did just now.
I do understand the relationship, but thank you for further re-enforcing that understanding....what i meant was that the allocator resource (program or whatever my hybrid approach is called) could reside in hub memory....and it's chunks could be called by ALL cogs to complete a logical operation......
the idea being that this would be much faster than calling from external memory? am I correct in that assumption?
my concept behind "chunks" and "program bouncing"...is that large callable objects would be broken up into many smaller callable objects.....those smaller callable objects could then be called (first in line) as a nested operation within other process (actually flip flop that?).....for example....a timer could be called by invoking a counter and another operation.....
the final output of ALL of those small chunks would be one large chunk....thereby distributing the load across ALL available resources....rather than things sitting idle.....
now from what I am gathering from this thread....that may not be necessary, because certain systems can be shut down to save power....this is entirely unlike other MCU's I have dealt with...
the concept is still employable though, when you have an operation that would govern ALL cogs (such as my complete power regulation platform)....
my goal here is to build a cheap highly configurable, highly regulated power platform....that can be used to drive a variety of subsystems....such as a fluid injector and atomizer....a light display.....a heater coil etc etc etc.....this project is the basis and foundation of all my projects to come....
in a nutshell, I want a smart power supply as a modular building block for the future....and I want to learn some things along the way
"rather than things sitting idle" ... You can do Propeller programming that way. One of the forum members has a task scheduler that runs in a cog (or in several cogs). I think it's in the Object Exchange. On the other hand, one of the advantages of the multiprocessing that is the Propeller is that you really can let things sit idle if that helps to simplify your program and make it more reliable. An idle cog draws very very little current. It's essentially stopped (turned off) and can restart at full speed within a system clock cycle either based on time or an I/O pin status change. If you have fewer simultaneous tasks than you have cogs, it may really simplify your program to have each task completely occupy a cog.
Look at some of the graphs on the Propeller's datasheet. They show current drain per cog based on system clock speed and temperature. They also show the current drain for the shared hub memory and logic and for the system clock itself. The Propeller can easily change it's global clock frequency to control power consumption. Programs with timing constraints may have to recalculate wait times and, if you're keeping a real-time clock, there'll be a little slippage as the clock stabilizes over a few milliseconds. Most programs and objects are written to use a system clock speed set once when the program initializes itself, not one that changes frequently. Most of the time, the normal power consumption drop when a cog waits for some condition is more than enough to get low power drain.
I don't know if that assumption is valid or not. Not sure I've seen that kind of program structure presented on the Propeller. A distributed supervisor, that keeps track of state, callable by any COG finished with it's task is perfectly doable though.
On power management, Props can select their own internal clock, 12Mhz or so, depending on that particular chip, and do so in software. I, along with some others, have used it for things like hardware autodetect, where the slow clock is used to probe the pins to determine the operating board in use, then select the clock and parameters appropriate for that board, running full speed from there, by way of one example.
COGs not being used don't consume power. Very slow clocks can be used too. If you want, you can put the whole thing pretty much asleep, but for some minor league watch dog process that can fire the chip up quick, when warranted. A cog doesn't use much power when waiting on a pin either. Some people have done some pretty cool, "how low will it go" tests that were pretty impressive for solar applications and such.
It may be that you want things sitting idle when power use is a concern. That all depends on the compute and throughput requirements at any one time.
One of the things that's different about semiconductors compared to other types of components is that things vary widely from part to part. In something as simple as a transistor, the gain can vary by more than an order of magnitude. Often that's spec'd only in terms of a minimum. You simply have to design on that basis and choose your circuits so the variation gets swamped by passive component values that can be more tightly controlled.
I think you'll find that the values shown on microcontroller's datasheets are, in general, ideals ... only approximations to the actual values on-chip and that those values vary widely, are temperature sensitive and often supply voltage sensitive. The reason why you're getting so much resistance to the idea of a schematic is that it's only a very coarse approximation to what is present on any given chip and you can't really do what you describe (figure the on chip values into calculations of circuit behavior) unless the particular values involved are laser-trimmed or somehow measured on a per-chip basis.
this was my concern around tolerances.....thank you very much for addressing it.....it really changes some fundamentals of my efforts....game changer
there are in fact fully spec'd chips available (especially power regulation semi's)....they are spec'd on a per chip basis....but their cost and availability are unreasonable (I can't purchase 1000 at a few hundred dollars each)
I have seen better documentation from most (on common chips) than Parallax....and I have been able to derive predictable outcomes (using simple math) before my circuit is built, but I do understand your points....hence your mention of highly parasitic value shifts....do you think some of those shifts can cause on-board structures to change in nature....for example....a thermal high could cause an improper gap tolerance in a transistor, and cause the transistor to become a capacitive resistor? this is just theory and not relevant to my needs or this discussion about SPIN (but it fascinates me)
so I will have to live with the ideal values published by Parallax...that is concerning, as i want to reduce/remove ANY controllable inefficiency from my platform....i would ideally like more precision than that....without having to rely on external buffers....maybe that's a lost cause on my part
Ari - Start a new thread detailing what you need. The community will then be able to help. People like talking about complex things tarround here. It's what we derive value from.
1) "on-board structures" ... I'd consider a chip to be faulty if it didn't behave as described over the operating conditions specified. I don't care what happens internally as long as the external behavior is what I expect. It may be that a "change in nature" of an internal structure is a planned part of how the chip is able to function over the range of operating conditions. After all, a Zener diode is an ordinary diode that is designed to go into a non-destructive avalanche state at a specified voltage given that the avalanche current is externally limited.
2) Power control semiconductors have particular reasons to be tightly spec'd. A 1% difference in some parameter may result in destruction of the device or a very expensive inefficiency. Obviously the premium handling is worth quite a bit to someone.
3) In a non-ideal world with realistic components that vary widely in values, you have to be clever about how you find and create efficiencies. Sometimes the solutions don't involve precision. I'm amazed by how little power my iPhone uses. The processor inside, when turned on, is a power hog, gets quite warm. It has to in order to do processor intensive work. On the other hand, the software is written to ruthlessly shut down portions of the system when they're not needed and to idle as much as possible.
1) "on-board structures" ... I'd consider a chip to be faulty if it didn't behave as described over the operating conditions specified. I don't care what happens internally as long as the external behavior is what I expect. It may be that a "change in nature" of an internal structure is a planned part of how the chip is able to function over the range of operating conditions. After all, a Zener diode is an ordinary diode that is designed to go into a non-destructive avalanche state at a specified voltage given that the avalanche current is externally limited.
2) Power control semiconductors have particular reasons to be tightly spec'd. A 1% difference in some parameter may result in destruction of the device or a very expensive inefficiency. Obviously the premium handling is worth quite a bit to someone.
3) In a non-ideal world with realistic components that vary widely in values, you have to be clever about how you find and create efficiencies. Sometimes the solutions don't involve precision. I'm amazed by how little power my iPhone uses. The processor inside, when turned on, is a power hog, gets quite warm. It has to in order to do processor intensive work. On the other hand, the software is written to ruthlessly shut down portions of the system when they're not needed and to idle as much as possible.
yes....there are some amazing "high end" MCU's out there....specifically directed at governing power....and VERY applicable to my needs.....but they are beyond the realm of sanity (in terms of expense)
my ideal is to replicate those systems (and find a happy middle ground) at a more reasonable cost (by cost I mean expense plus or minus other associated variables....such as my own sanity)
yes the fact about Zeners is interesting....I have seen and have employed Zeners as simple low-efficiency power regulators....as their voltage drop is predictable, measurable and consistent over their lifespan
the fact on i{HONES is interesting.....i have mine in an otter box (hard case) and the case causes the device to go into thermal shutdown constantly (when using it for long periods of time)....I do understand that this is beyond Apple's control, as the case is 3rd. party.....but these are the EXACT issues I wish to combat in my design....i would like to minimize the thermal impact of the system running at full tilt....which i suppose is every engineers dream, and often their downfall....
as you said maybe software is a better approach, in terms of cost....after all chasing ideals with no variable control in reality...is HIGHLY illogical....
First off, my apologies if I seemed rude or my tone a little negative. That's not my intention. This is a programming language debate and such discussions do tend to get a little heated.
I think we can agree about "WORD". It has the usage you describe. Word length can change from machine to machine depending on the number of bit's of it's ALU etc. However, as I point out, "WORD" has been pretty much been welded to 16 bit's in the micro-processor world. Even the Intel 8080 came with an assembler that used "db" to define bytes in memory and "dw" to define 16 bit data even though the "word length" of the processor was only 8 bits! So it's understandable that Parallax would choose WORD for 16 bit items in Spin.
Also we seem to agree that Java and .NET are not useful on the Prop.
I can't understand what relevance it is that the Arduino IDE is written in Java. That IDE runs on a PC, the source language one edits with it is C++ and it generates machine instructions for the AVR chips on the Arduino boards.
I had a look at the document you linked to about the Java, .NET, networking and the Hydra. Again I don't see how it is relevant. Those guys did not use any Java or .NET on the Propeller itself only on the attached PCs that did the actual networking.
Am I being reactionary toward you? Well yes, but not personally or particularly. This is a forum, we discuss, pick each other up on facts, try to sway each others opinions. Hopefully we all learn something along the way, and have a lot of fun.
Now, whilst I'm being reactionary:
DavidM,
SPIN is both a LANGUAGE and an IDE as far as I am concerned, AutoComplete to me seems a logical addition when using dot notation.
If you are hearing this a lot then maybe people like It!
Well I can see how you feel like that. But technically the language is "Spin" and the IDE is "Parallax Propeller Tool" (or whatever, I have not seen it for years)
This is an important distinction. Especially now as we have at least four ways to get code written in Spin the language compiled and running on the Prop. The Propeller Tool, BST, HomeSpun and Sphinx. I migh say five ways because BradC provides a command line compiler and loader, BSTC and BSTL.
Yes auto complete is a logical addition to an IDE and a lot of people like it. Still I think one should be aware of the difference between IDE and language features. If Parallax adds a feature to the IDE, like the indentation block marking, that has no effect on the language. mpark, BradC and all don't have to scramble to modify their compilers to keep up with the "standard". But if Parallax added a new language feature, structures for example, this would cause work for all authors of Spin compatible compilers.
Bill Henning,
Hmm... Spin is closest to Python methinks
You are joking I hope Bill:)
The white space indenting gives a very superficial similarity between Spin and Python.
Can you do this in Spin?:
A = 2332983171085498759745843601764976508365786396239859865 * 987492698629169129139863986398649863986298712976347121298628712
print A
And get a correct result?
Not to mention all the other big features Python has.
First off, my apologies if I seemed rude or my tone a little negative. That's not my intention. This is a programming language debate and such discussions do tend to get a little heated.
I think we can agree about "WORD". It has the usage you describe. Word length can change from machine to machine depending on the number of bit's of it's ALU etc. However, as I point out, "WORD" has been pretty much been welded to 16 bit's in the micro-processor world. Even the Intel 8080 came with an assembler that used "db" to define bytes in memory and "dw" to define 16 bit data even though the "word length" of the processor was only 8 bits! So it's understandable that Parallax would choose WORD for 16 bit items in Spin.
Also we seem to agree that Java and .NET are not useful on the Prop.
I can't understand what relevance it is that the Arduino IDE is written in Java. That IDE runs on a PC, the source language one edits with it is C++ and it generates machine instructions for the AVR chips on the Arduino boards.
I had a look at the document you linked to about the Java, .NET, networking and the Hydra. Again I don't see how it is relevant. Those guys did not use any Java or .NET on the Propeller itself only on the attached PCs that did the actual networking.
Am I being reactionary toward you? Well yes, but not personally or particularly. This is a forum, we discuss, pick each other up on facts, try to sway each others opinions. Hopefully we all learn something along the way, and have a lot of fun.
It always blows my mind how passionate people can be about one of the least human things man has created. Maybe someday we will design a chip and language that argues with itself....
I love the fact that programming and hardware, and logical language (binary) has no place for conjecture or argument (well arguably....lol)
What I mean by this is, on a physical level...the switch is on or off....oh wait I am not entirely correct....there is the issue of ethernet which lives in a zero state until it sends a high or low...but that isn't as simple as I am making it out to be, and I could argue that it's outcome is still pure binary....I digress
Ok, so by my own tokens (pun) I have to admit that there is a place for debate here, and maybe it's healthy, but I have a real problem with hurtful/insulting words. I don't mind people being blunt with me...as I am blunt with most people (get's me in a lot of trouble)...but as soon as thing digress into $hit slinging I usually bow out. Life is far to short, agreed?
I digress....enough of my pseudo-philosophical soapboxing
On the issue of the term WORD...I can't pose any argument that you are 100% correct about the attributable usage of the word in modern IDE's. In fact it would be foolish to change it's syntax, because we would be having to rewrite a lot of existing code to account for such a change.
I do still scratch my head (however) about how illogical terms make it into the syntax of a logical language....seems a bit awkward to me....an apple is an apple unless it's an orange, and if it's an orange then the answer is clearly avocado :blank:
Java and .NET are utterly useless on an MCU, as they are nothing more than frameworks...i know we agree on this. The waste of resources to use a framework to execute low-level function on chip would be truly epic. This is however not what I want these tools for. What I would like is the capability to use java objects in the SPIN compiler....maybe I have been poorly articulating my wishes. That's my fault.
The relevance of arduino using java is for the reason I stated above. I do not wish to have any MCU now or in the future use native OO language. I don't even see how that would be possible. At some point this has to migrate to simple functions. Why do that on chip. ?!?! (can't decide if that is a question or statement)
The reason I brought up the HYDRA project, is not to try and show that somehow .NET is running on a chip level....it's to show the interaction between multiple disciplines (in relation to propeller)....this is all I want to do....I have no problem with everything being ported to PASM at some level....but I would really like my interaction on screen to be something familiar and portable....but I can see where the problems lie with that concept (applied to propeller)
With a common architecture and movable jumpers, the PIC chips and dev. boards have managed to do exactly what I describe....they have truly portable function and can ingest from many sources...this is all I wish for with propeller....I can see it's nearly impossible though...
This does not change my opinions about SPIN and prop though....in fact it re-enforces them. Everything I have said remains true about SPIN....it is truly proprietary and not at all portable....that is a huge problem for me....it doesn't make me think any less of the products, but it does take them out of the hands of many large scale development teams....and I am beginning to see that maybe that is a good thing
So i retract my statements about prop being simply a "toy" and I have admitted that my use of the word "professional" is probably far to loose....if anyone has been offended along the way, I am sorry....but I am sticking to my guns here....my opinions about the problems that exist have not changed....it simply can't be used by established code bases and can't be used as a product revision tool....
I hope you gentleman can see how that leads me to my earlier statements....and as I said before, I am not here to troll or sling mud....I am not a reactionary person...I speak plain and blunt and I do not mind people responding in that fashion....but flat out insults will not do
I do not wish to have any MCU now or in the future use native OO language. I don't even see how that would be possible.
Easy.The Arduino, for example is actually programmed in C++ compiled with GCC. That's about as object oriented as it gets.
You can even run C++ programs on your Propeller. Just compile them with the GCC for the ZPU processor and run them under the Zog ZPU virtual machine.
Java and .NET are utterly useless on an MCU, as they are nothing more than frameworks..
Except that Java is actually a language not a frame work. Google uses Java for the Android operating system but it is a totally different "frame work". Android does not even use the Java virtual machine.
.NET on the other hand does seem to be a frame work. The major language in use there being C# I believe.
I might have to review by opinion that Java is big, slow, and generally useless on MCUs soon. The AVR32 has a hardware Java virtual machine.
I'm stunned yet again at the patience and forbearance exemplified on this forum. When a poster demanded a schematic to the Prop, said that he couldn't proceed without it, and that every other processor he'd ever worked on had full schematics, I laughed myself silly. I'm not sure a schematic even exists for the processors I use daily - I think they went straight from Verilog to photomask, via EDA. Any schematic that might exist must be in the form of billions of bits on a hard drive somewhere.
Come to find out, he fritzed a couple chips out of ignorance and/or 'descuido' and now he's upset at Parallax. Realistically, it would be hard to find a less fussy chip to keep happy than the Prop. A couple caps and a crystal constitute the deluxe set-up.
In one instance, I have a prop pin going directly to a 10kW SSR w/o a hitch. I fire pottery that way.
In one instance, I have a prop pin going directly to a 10kW SSR w/o a hitch. I fire pottery that way.
I understand that caps can help if the prop suddenly draws more current and the voltage regulator cannot react fast enough. But what if there is a voltage spike, for example due to an environment rich in EM radiations and a circuit that's not shielded? How do you protect from this?
Caps can help blunt an induced voltage spike as well as make up for brief voltage outages. Shielding sensitive circuitry including filtering where leads enter the shield is an important protection. You have to balance filtering out noise against filtering out the signals themselves.
I'm stunned yet again at the patience and forbearance exemplified on this forum. When a poster demanded a schematic to the Prop, said that he couldn't proceed without it, and that every other processor he'd ever worked on had full schematics, I laughed myself silly. I'm not sure a schematic even exists for the processors I use daily - I think they went straight from Verilog to photomask, via EDA. Any schematic that might exist must be in the form of billions of bits on a hard drive somewhere.
Come to find out, he fritzed a couple chips out of ignorance and/or 'descuido' and now he's upset at Parallax. Realistically, it would be hard to find a less fussy chip to keep happy than the Prop. A couple caps and a crystal constitute the deluxe set-up.
In one instance, I have a prop pin going directly to a 10kW SSR w/o a hitch. I fire pottery that way.
wow you really know how to twist peoples words....I plainly said I fried one chip trying to find a maximum voltage (which I pushed until it fried on purpose, knowing full well it was going to fry)....no one ever "demanded" a schematic.....and here is a common chip with proper documentation http://ww1.microchip.com/downloads/en/DeviceDoc/41350E.pdf
if it helps anyone in the future, I pushed the propeller to 3.9 volts with no trouble at all.....and it lasted at 9 volts for about 4 or 5 seconds
the prop plug kept working even after I slammed it with 9 volts....and didn't die until well after 14 volts went into it
what stuns me more than the patience of this forum, is the willingness of some people to SPIN other peoples words, in order to grandstand on the internet.....there is no winner in that scenario....
thanks to everyone that has been helpful....but enough is enough.....good luck to all with their projects and Propeller efforts
You may not have consciously demanded a schematic but from your posts it sure reads that way, even without anyone trying to "spin" your words. Even I am beginning wonder if you are just trying to wind us up. For example here is a selection of your statements:
Still the problem remains....NO detailed schematic or electrical specs. are available...
.it's real flaw is just the lack of object ingestation and a full schematic....
If the Prop. could utilize Java and or C objects....and a full schematic was made available....I think it could go toe to toe with anything on the market, and I see no reason why large development teams couldn't pick it up....
...almost every other solution on market has a full on die schematic in their data sheet...
...but the total lack of schematic (that is acceptable for me to work from) is daunting.
...on the issue of "schematic". I come from an engineering background. So i use the term in the most raw sense possible. This is why I used the term "on die" schematic. I have no use for any data off the chip pins,
... and the failure to ingest industry standard objects makes it nearly impossible for an established development team to build their existing applications on...
You comments about "professionals" were also inflammatory, never mind basing professionalism on monthly turn over, we have:
...when I say professional I can't count small teams building short run niche devices...
Which is very disrespectful toward the huge number of very professional engineers are satisfying the needs of all kinds of niche markets all around the world. Many of which the "consumer" will never know about and neither should they have to.
I do hope that you can adjust your attitude a little and make use of all the expertise, advice and encouragement available on this forum that thousands of others have benefited from in the past and continue to do so.
P.S. I had a look at that PIC data sheet, no schematic there either:)
I am wondering just exactly what Ari was planning to USE a prop chip for, Asking for PURIST SPECIFICATIONS, seems a bit much, maybe some kind of Military device, MEdical device etc?
It's a bit like the hot chick at the other end of the bar, everybody else ( of all types) is chatting with her, except him ( ari) all he has to do is go up to and talk to her and say hello, she won't bite, and might actually talk back.
I warned you guys about feeding the troll 3 days ago on page 8 of this thread. Of course, I have to admit that Ari isn't a troll. He's more like a child that demands something, and he won't listen to reason no matter how hard you try.
Good grief. I don't see this any different from entering a room, getting a bad read on the people in there, stubbing a toe or two, then just leaving because that's easier.
my idea for external clock was an oscillator and a NTP polling program....then a simple comparator for both....a corrector would be beyond the scope of my engineering know how....
Find a GPS module with a PPS (pulse per second) output, and make a PLL out of that.
....but these are the EXACT issues I wish to combat in my design....i would like to minimize the thermal impact of the system running at full tilt....which i suppose is every engineers dream, and often their downfall....
Propeller has been shown running solidly at 80Mhz, at 190C. Datasheet says up to 125, but you're probably good to 150, as long as you can handle variations in the frequency of whatever oscillator you use. You could, certainly, attach an external thermometer to the prop, and use the rating curve on Page 31 of the datasheet to compensate vs whatever temperature you design your device at.
Just call it High Level and give some simple (syntax highlighted?) examples, include the sizes [Source.Code.Kernal.Library]
A picture is always worth a thousand words.
my thinking behind the schematic would be to see the values of represented components (on die) and then simply do the math to find their collective resistance at the tip of a pin (which I could then add to the resistance of my traces, on up to the next component and so on......) <snip>
Can you be clearer in what you actually expect here ?
Do you want a Spice or IBIS model of the pin-driver ?
Most mosfet pin drivers are pretty simple, and model as a P+N FET pair ?
Comments
Some people in this community have a thinner skin than others. We all try to keep discussions civil, but we all have "hot buttons". In addition, the forum structure is not the same as a conversation and things meant one way may be misunderstood. Be patient, be gentle, try not to be too dogmatic, Read and re-read what others have said and read what you've said in reply before you click Post. It helps.
my thinking behind the schematic would be to see the values of represented components (on die) and then simply do the math to find their collective resistance at the tip of a pin (which I could then add to the resistance of my traces, on up to the next component and so on......)
it is pretty common to be able to do that for other IC's and that information is available from most other manufacturers.....TI is really the best about it (including full on die schematics of ALL replicated components)
now if someone was willing to simply tell me the ambient shift in resistance, and it's equivalent output voltage swing....well then that certainly saves me a lot of trouble....and would be most appreciated (i might even send that person a dozen roses)
this was my concern about standard deviation and what are the acceptable shifts/swings......I know that it is virtually impossible to provide a fractional percentage of consistency in a $8 chip.....for that we need to employ aerospace technologies and possibly a security clearance (half joking) , and I have looked into those resources.....I can't afford to build a $3000 micro-regulated power supply.....in terms of sanity, expense and practicality......unless a few of you offer to buy one from me (har har)
Yes, his use of >= that way was quite legitimate. It was his explanation of what it did that was off.
Yes, but it also modifies temperature, replacing a quantity with a Boolean, which is almost never a reasonable side effect. In most cases, the following would be more appropriate:
unless you really wanted temperature to be changed to 0 or -1 in the process. Also, > works if temperature is a method call; >= does not.
-Phil
Easy mistake. Happens. (happens too much sometimes, and usually when I go some time between prop sessions)
Completely agreed on a quantity being changed to a boolean, but then again, it's all just bits, right? So then, just knowing that's gonna happen is the key thing. What people do with it may well pay off, and I suppose that's my greater point. Better to have the tool than not.
Of course, that runs counter to our long running, "make spin easy for newbies" vs "make spin powerful" discussion we've had over the years Phil. On that note, I agree with you, but am glad it's in there just the same.
I think you'll find that the values shown on microcontroller's datasheets are, in general, ideals ... only approximations to the actual values on-chip and that those values vary widely, are temperature sensitive and often supply voltage sensitive. The reason why you're getting so much resistance to the idea of a schematic is that it's only a very coarse approximation to what is present on any given chip and you can't really do what you describe (figure the on chip values into calculations of circuit behavior) unless the particular values involved are laser-trimmed or somehow measured on a per-chip basis.
I do understand the relationship, but thank you for further re-enforcing that understanding....what i meant was that the allocator resource (program or whatever my hybrid approach is called) could reside in hub memory....and it's chunks could be called by ALL cogs to complete a logical operation......
the idea being that this would be much faster than calling from external memory? am I correct in that assumption?
my concept behind "chunks" and "program bouncing"...is that large callable objects would be broken up into many smaller callable objects.....those smaller callable objects could then be called (first in line) as a nested operation within other process (actually flip flop that?).....for example....a timer could be called by invoking a counter and another operation.....
the final output of ALL of those small chunks would be one large chunk....thereby distributing the load across ALL available resources....rather than things sitting idle.....
now from what I am gathering from this thread....that may not be necessary, because certain systems can be shut down to save power....this is entirely unlike other MCU's I have dealt with...
the concept is still employable though, when you have an operation that would govern ALL cogs (such as my complete power regulation platform)....
my goal here is to build a cheap highly configurable, highly regulated power platform....that can be used to drive a variety of subsystems....such as a fluid injector and atomizer....a light display.....a heater coil etc etc etc.....this project is the basis and foundation of all my projects to come....
in a nutshell, I want a smart power supply as a modular building block for the future....and I want to learn some things along the way
Look at some of the graphs on the Propeller's datasheet. They show current drain per cog based on system clock speed and temperature. They also show the current drain for the shared hub memory and logic and for the system clock itself. The Propeller can easily change it's global clock frequency to control power consumption. Programs with timing constraints may have to recalculate wait times and, if you're keeping a real-time clock, there'll be a little slippage as the clock stabilizes over a few milliseconds. Most programs and objects are written to use a system clock speed set once when the program initializes itself, not one that changes frequently. Most of the time, the normal power consumption drop when a cog waits for some condition is more than enough to get low power drain.
On power management, Props can select their own internal clock, 12Mhz or so, depending on that particular chip, and do so in software. I, along with some others, have used it for things like hardware autodetect, where the slow clock is used to probe the pins to determine the operating board in use, then select the clock and parameters appropriate for that board, running full speed from there, by way of one example.
COGs not being used don't consume power. Very slow clocks can be used too. If you want, you can put the whole thing pretty much asleep, but for some minor league watch dog process that can fire the chip up quick, when warranted. A cog doesn't use much power when waiting on a pin either. Some people have done some pretty cool, "how low will it go" tests that were pretty impressive for solar applications and such.
It may be that you want things sitting idle when power use is a concern.
this was my concern around tolerances.....thank you very much for addressing it.....it really changes some fundamentals of my efforts....game changer
there are in fact fully spec'd chips available (especially power regulation semi's)....they are spec'd on a per chip basis....but their cost and availability are unreasonable (I can't purchase 1000 at a few hundred dollars each)
I have seen better documentation from most (on common chips) than Parallax....and I have been able to derive predictable outcomes (using simple math) before my circuit is built, but I do understand your points....hence your mention of highly parasitic value shifts....do you think some of those shifts can cause on-board structures to change in nature....for example....a thermal high could cause an improper gap tolerance in a transistor, and cause the transistor to become a capacitive resistor? this is just theory and not relevant to my needs or this discussion about SPIN (but it fascinates me)
so I will have to live with the ideal values published by Parallax...that is concerning, as i want to reduce/remove ANY controllable inefficiency from my platform....i would ideally like more precision than that....without having to rely on external buffers....maybe that's a lost cause on my part
2) Power control semiconductors have particular reasons to be tightly spec'd. A 1% difference in some parameter may result in destruction of the device or a very expensive inefficiency. Obviously the premium handling is worth quite a bit to someone.
3) In a non-ideal world with realistic components that vary widely in values, you have to be clever about how you find and create efficiencies. Sometimes the solutions don't involve precision. I'm amazed by how little power my iPhone uses. The processor inside, when turned on, is a power hog, gets quite warm. It has to in order to do processor intensive work. On the other hand, the software is written to ruthlessly shut down portions of the system when they're not needed and to idle as much as possible.
yes....there are some amazing "high end" MCU's out there....specifically directed at governing power....and VERY applicable to my needs.....but they are beyond the realm of sanity (in terms of expense)
my ideal is to replicate those systems (and find a happy middle ground) at a more reasonable cost (by cost I mean expense plus or minus other associated variables....such as my own sanity)
yes the fact about Zeners is interesting....I have seen and have employed Zeners as simple low-efficiency power regulators....as their voltage drop is predictable, measurable and consistent over their lifespan
the fact on i{HONES is interesting.....i have mine in an otter box (hard case) and the case causes the device to go into thermal shutdown constantly (when using it for long periods of time)....I do understand that this is beyond Apple's control, as the case is 3rd. party.....but these are the EXACT issues I wish to combat in my design....i would like to minimize the thermal impact of the system running at full tilt....which i suppose is every engineers dream, and often their downfall....
as you said maybe software is a better approach, in terms of cost....after all chasing ideals with no variable control in reality...is HIGHLY illogical....
First off, my apologies if I seemed rude or my tone a little negative. That's not my intention. This is a programming language debate and such discussions do tend to get a little heated.
I think we can agree about "WORD". It has the usage you describe. Word length can change from machine to machine depending on the number of bit's of it's ALU etc. However, as I point out, "WORD" has been pretty much been welded to 16 bit's in the micro-processor world. Even the Intel 8080 came with an assembler that used "db" to define bytes in memory and "dw" to define 16 bit data even though the "word length" of the processor was only 8 bits! So it's understandable that Parallax would choose WORD for 16 bit items in Spin.
Also we seem to agree that Java and .NET are not useful on the Prop.
I can't understand what relevance it is that the Arduino IDE is written in Java. That IDE runs on a PC, the source language one edits with it is C++ and it generates machine instructions for the AVR chips on the Arduino boards.
I had a look at the document you linked to about the Java, .NET, networking and the Hydra. Again I don't see how it is relevant. Those guys did not use any Java or .NET on the Propeller itself only on the attached PCs that did the actual networking.
Am I being reactionary toward you? Well yes, but not personally or particularly. This is a forum, we discuss, pick each other up on facts, try to sway each others opinions. Hopefully we all learn something along the way, and have a lot of fun.
Now, whilst I'm being reactionary:
DavidM,
Well I can see how you feel like that. But technically the language is "Spin" and the IDE is "Parallax Propeller Tool" (or whatever, I have not seen it for years)
This is an important distinction. Especially now as we have at least four ways to get code written in Spin the language compiled and running on the Prop. The Propeller Tool, BST, HomeSpun and Sphinx. I migh say five ways because BradC provides a command line compiler and loader, BSTC and BSTL.
Yes auto complete is a logical addition to an IDE and a lot of people like it. Still I think one should be aware of the difference between IDE and language features. If Parallax adds a feature to the IDE, like the indentation block marking, that has no effect on the language. mpark, BradC and all don't have to scramble to modify their compilers to keep up with the "standard". But if Parallax added a new language feature, structures for example, this would cause work for all authors of Spin compatible compilers.
Bill Henning,
You are joking I hope Bill:)
The white space indenting gives a very superficial similarity between Spin and Python.
Can you do this in Spin?:
And get a correct result?
Not to mention all the other big features Python has.
It always blows my mind how passionate people can be about one of the least human things man has created. Maybe someday we will design a chip and language that argues with itself....
I love the fact that programming and hardware, and logical language (binary) has no place for conjecture or argument (well arguably....lol)
What I mean by this is, on a physical level...the switch is on or off....oh wait I am not entirely correct....there is the issue of ethernet which lives in a zero state until it sends a high or low...but that isn't as simple as I am making it out to be, and I could argue that it's outcome is still pure binary....I digress
Ok, so by my own tokens (pun) I have to admit that there is a place for debate here, and maybe it's healthy, but I have a real problem with hurtful/insulting words. I don't mind people being blunt with me...as I am blunt with most people (get's me in a lot of trouble)...but as soon as thing digress into $hit slinging I usually bow out. Life is far to short, agreed?
I digress....enough of my pseudo-philosophical soapboxing
On the issue of the term WORD...I can't pose any argument that you are 100% correct about the attributable usage of the word in modern IDE's. In fact it would be foolish to change it's syntax, because we would be having to rewrite a lot of existing code to account for such a change.
I do still scratch my head (however) about how illogical terms make it into the syntax of a logical language....seems a bit awkward to me....an apple is an apple unless it's an orange, and if it's an orange then the answer is clearly avocado :blank:
Java and .NET are utterly useless on an MCU, as they are nothing more than frameworks...i know we agree on this. The waste of resources to use a framework to execute low-level function on chip would be truly epic. This is however not what I want these tools for. What I would like is the capability to use java objects in the SPIN compiler....maybe I have been poorly articulating my wishes. That's my fault.
The relevance of arduino using java is for the reason I stated above. I do not wish to have any MCU now or in the future use native OO language. I don't even see how that would be possible. At some point this has to migrate to simple functions. Why do that on chip. ?!?! (can't decide if that is a question or statement)
The reason I brought up the HYDRA project, is not to try and show that somehow .NET is running on a chip level....it's to show the interaction between multiple disciplines (in relation to propeller)....this is all I want to do....I have no problem with everything being ported to PASM at some level....but I would really like my interaction on screen to be something familiar and portable....but I can see where the problems lie with that concept (applied to propeller)
With a common architecture and movable jumpers, the PIC chips and dev. boards have managed to do exactly what I describe....they have truly portable function and can ingest from many sources...this is all I wish for with propeller....I can see it's nearly impossible though...
This does not change my opinions about SPIN and prop though....in fact it re-enforces them. Everything I have said remains true about SPIN....it is truly proprietary and not at all portable....that is a huge problem for me....it doesn't make me think any less of the products, but it does take them out of the hands of many large scale development teams....and I am beginning to see that maybe that is a good thing
So i retract my statements about prop being simply a "toy" and I have admitted that my use of the word "professional" is probably far to loose....if anyone has been offended along the way, I am sorry....but I am sticking to my guns here....my opinions about the problems that exist have not changed....it simply can't be used by established code bases and can't be used as a product revision tool....
I hope you gentleman can see how that leads me to my earlier statements....and as I said before, I am not here to troll or sling mud....I am not a reactionary person...I speak plain and blunt and I do not mind people responding in that fashion....but flat out insults will not do
Easy.The Arduino, for example is actually programmed in C++ compiled with GCC. That's about as object oriented as it gets.
You can even run C++ programs on your Propeller. Just compile them with the GCC for the ZPU processor and run them under the Zog ZPU virtual machine.
Except that Java is actually a language not a frame work. Google uses Java for the Android operating system but it is a totally different "frame work". Android does not even use the Java virtual machine.
.NET on the other hand does seem to be a frame work. The major language in use there being C# I believe.
I might have to review by opinion that Java is big, slow, and generally useless on MCUs soon. The AVR32 has a hardware Java virtual machine.
Come to find out, he fritzed a couple chips out of ignorance and/or 'descuido' and now he's upset at Parallax. Realistically, it would be hard to find a less fussy chip to keep happy than the Prop. A couple caps and a crystal constitute the deluxe set-up.
In one instance, I have a prop pin going directly to a 10kW SSR w/o a hitch. I fire pottery that way.
I understand that caps can help if the prop suddenly draws more current and the voltage regulator cannot react fast enough. But what if there is a voltage spike, for example due to an environment rich in EM radiations and a circuit that's not shielded? How do you protect from this?
wow you really know how to twist peoples words....I plainly said I fried one chip trying to find a maximum voltage (which I pushed until it fried on purpose, knowing full well it was going to fry)....no one ever "demanded" a schematic.....and here is a common chip with proper documentation
http://ww1.microchip.com/downloads/en/DeviceDoc/41350E.pdf
if it helps anyone in the future, I pushed the propeller to 3.9 volts with no trouble at all.....and it lasted at 9 volts for about 4 or 5 seconds
the prop plug kept working even after I slammed it with 9 volts....and didn't die until well after 14 volts went into it
what stuns me more than the patience of this forum, is the willingness of some people to SPIN other peoples words, in order to grandstand on the internet.....there is no winner in that scenario....
thanks to everyone that has been helpful....but enough is enough.....good luck to all with their projects and Propeller efforts
You may not have consciously demanded a schematic but from your posts it sure reads that way, even without anyone trying to "spin" your words. Even I am beginning wonder if you are just trying to wind us up. For example here is a selection of your statements:
You comments about "professionals" were also inflammatory, never mind basing professionalism on monthly turn over, we have:
Which is very disrespectful toward the huge number of very professional engineers are satisfying the needs of all kinds of niche markets all around the world. Many of which the "consumer" will never know about and neither should they have to.
I do hope that you can adjust your attitude a little and make use of all the expertise, advice and encouragement available on this forum that thousands of others have benefited from in the past and continue to do so.
P.S. I had a look at that PIC data sheet, no schematic there either:)
I am wondering just exactly what Ari was planning to USE a prop chip for, Asking for PURIST SPECIFICATIONS, seems a bit much, maybe some kind of Military device, MEdical device etc?
It's a bit like the hot chick at the other end of the bar, everybody else ( of all types) is chatting with her, except him ( ari) all he has to do is go up to and talk to her and say hello, she won't bite, and might actually talk back.
Dave M
Is it really that hard?
Good grief. I don't see this any different from entering a room, getting a bad read on the people in there, stubbing a toe or two, then just leaving because that's easier.
Propeller has been shown running solidly at 80Mhz, at 190C. Datasheet says up to 125, but you're probably good to 150, as long as you can handle variations in the frequency of whatever oscillator you use. You could, certainly, attach an external thermometer to the prop, and use the rating curve on Page 31 of the datasheet to compensate vs whatever temperature you design your device at.
-Phil
Just call it High Level and give some simple (syntax highlighted?) examples, include the sizes [Source.Code.Kernal.Library]
A picture is always worth a thousand words.
Strange effect...
Correct, anything that can change what LOOKS perfectly sensible, into a nasty fish-hook, should be quickly deprecated and replaced with a fix.
These two should be operationally, and content identical :
as that is what 99% of software writers, students and teachers would expect.
If a BOOLEAN operator or typecast is needed, it should be simply added, not hidden under a valid maths operator!
.
Can you be clearer in what you actually expect here ?
Do you want a Spice or IBIS model of the pin-driver ?
Most mosfet pin drivers are pretty simple, and model as a P+N FET pair ?