markaeric said...
Commercially, QNX is designed to be used in real-time, mission-critical embedded computer systems. For those of you who have never tried it, I think it's worth a shot. From my experience, it's certainly more stable than the various BSD and Linux distros I've tried.
I can't speak for the 4.x flavours but the QNX 6.x flavours had a rather nasty flaw when trying to share an IRQ.
One heavily promoted and used mechanism for servicing interrupts was to have the driver, all drivers are user-level in QNX 6.x, receive an event from the kernel when it's registered interrupt had been activated. The kernel made no attempt at masking the device and didn't have a callback mechanism for the driver to do it. The kernel would instead mask the IRQ itself and then go back to scheduling tasks with, hopefully, that very driver being next on the list. The unmasking of the IRQ was entirely up to the driver's discretion as to when it happened. And, naturally, had little concern for any other device that might be trying to activate the same IRQ.
The other available interrupt servicing mechanism, of inserting a small callback interrupt function, was capable handling shared interrupts but it was frowned upon as "not being clean" because it ran with kernel privilege and naturally extremely limited calls and timing considerations.
I've not looked to see if they've done much to rectify the situation in the last few years. They may have now implemented something. I speculated on PCI having a standard for masking device IRQ sources, but failing that QSS would have to rewrite all their drivers to use the alternate mechanism if they wanted them to be shareable without the tell-tale glitching.
A reliable workaround was to make sure all devices had individual IRQs.
markaeric said...
... come the year 2075, I think finding SPI memory or, USB/flash sticks will be impossible anyways, so what's the point?
I wouldn't be so sure about that. Serially connected storage is rather convenient. It saves on pin count while bursting at respectable speeds.
Aside from single chip solutions I doubt SPI will stop being used. SPI is about as low level as can be done. The only possible improvement I can think of that might supplant SPI is a simple modulated protocol that incorporates the clocking on the same signal. This reduces the bit-rate but has a distinctly stronger coherence - allowing greater distances to be spanned and is simple to bridge through other mediums.
Thing is, these modulated comms have always existed but haven't been adopted for inter-chip comms. Maybe the popularity of SPI and I2C have stifled them. Time will tell I guess.
Yes but, 2075 is 65 years away. Looking at how technology has moved in the last 65 years, I might not expect anything resembling SPI or USB to still be around outside of museums.
Assuming we get past 2012 that is.
Happy new year all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I certainly won't be arround and I seriously doubt my kids (25-28) will be much interested then either.
However, I do not expect anything like we use today to be around at all. If you look back over the last 40 years and how Moore's Law has continued to work and the advances made, there will be some other modulation method for sure.
Maybe they will be growing organic chips by then ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Midnight here. Time to crack out the eight-track and slide projector ... [noparse]:)[/noparse]
SPI as a recognised name isn't all that old compared to the UART and it's various wrappers. SPI is somewhat simpler than the UART. And it's purpose is to cheapen board designs, particularly in small boards. It has excelled at this function and will keep doing so imho.
The computer industry is several decades old now and has effectively become a monopoly like arrangement that likes to keep moving the goal posts to keep everyone upgrading. Yet, for example, there is one area in the PC that uses SPI - the AC97 codecs. SPI performs this function beautifully and efficiently. The DRM czars may be hard at work changing it but even then the physical layer can still stay as SPI, just with encrypted data streams across it.
Hehe, of course, I've been using SPDIF almost since I got my first PC. The external cables are modulated from a SPI source I suspect. The SPI source is called I2S but that'll be because there is a defined format and control layer on top of the hardware layer.
A bit off topic ... Just threading my way through a bunch of questionable Wikipedia articles and come across the statement that the Java compiler and VM is stack based! It's like WHAT! Why would a company so heavily based around pipelining/superscalar CPU structures go and put such a big battering-ram right through it all!? And I thought Java was only suffering a bad case of bloatware ... [noparse]:([/noparse]
Compilers for modern CPUs should be using as little stack as possible. Well, except for the decrepit x86 maybe since it has such a limited register set. AMD64 fixes that particularly long held flaw.
Evanh: Keeping as much as possible in registers is a good idea for any compiler. Local variables, parameters etc. But lets face it when you have a mass of software calling functions, calling functions, calling functions to some unknown depth, not to mention recursion, not to mention that your local vars in an object oriented language can be huge objects in themselves, I don't see how you can handle all that with out a stack based system.
Or am I missing something?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Basic principle is to pass all function parameters by register - only the return address goes on the stack. This can happen all the way down the call tree. Using different registers where appropriate. Obviously, there is object and list and stream data that is too big for the registers but this is usually processed as a block using pointers held in registers, so no real issue there.
The reason why this methodology (big word) works so well is tied to the nature of pipelining. If a compiler can identify parallel sequences within the procedure of the source code and then assemble them as interleaving instructions of multiple sequences, this will reduces the number of pipeline stalls that would otherwise occur.
This is obviously already done with C/Pascal compilers but I'm getting a distinct feeling that Java/C# compilers make no such attempts.
Part of each function definition defines what registers it expects parameters in and what registers it returns results in and what registers it trashes.
This can apply to the wider APIs and system calls too. Once it's done at this level then the compiler writers soon catch on. [noparse]:)[/noparse]
How about just using another Propeller for development? It'd act like a Propplug from the target Propeller point of view, and would require no extra hardware magic.
Or it could even emulate an EEPROM.
Do you know if there will be some way to share data between 2 cogs without going to the hub? Also, any timeline? Is it something expected soon? Or in a couple of years?
There will supposedly be a very high speed serial mode, with a few pins that would work; there was also some talk of implementing some internal-only "I/O ports", which may help.
Remember, hub accesses will happen every eight clock cycles, and there will apparently be a read/write quad long instruction - so the effective data rate will go up a lot.
No idea about the time line, I really wish I knew...
As you can tell from my site, I develop commercial products based on the Propeller, and would love to get Prop2 as soon as possible - but I think it won't happen soon.
jmspaggi said...
Do you know if there will be some way to share data between 2 cogs without going to the hub? Also, any timeline? Is it something expected soon? Or in a couple of years?
Flash on the chip would be real nice, even just a small amount
like 128kb.
A serial number is a nice feature. You could use it to only allow
your code to run on boards you made. Of course there is really
no hard security on any uController available to the general public.
At least none that I am aware of.
Post Edited (HollyMinkowski) : 5/13/2010 5:03:09 AM GMT
What constitutes hard security? The SX has a lock bit that will produce gibberish when trying to dump the contents of the flash area. I guess there's some way around that?
There are disreputable companies that for a fee
break the protection of controllers.
What a sleazy way to make a buck.
If you google around you can probably find out who will
break that protection and how much $ it would cost.
The only good security seems to be when your hardware has to
phone home and be authorized to run. What a pain in the butt.
It would be like MS and the activation you go through to keep
windoze running.
The only good security seems to be when your hardware has to
phone home and be authorized to run.
Meh.. firmware patches take care of that. Your best bet is to make your product reasonably priced and well supported. People may clone what you have, but you have the first market advantage and can stay ahead of the pack.
Anything man can create, man can undo. I spent many hours in disassemblers and debuggers patching out "phone home" checks in old security and access control equipment where the manufacturer had gone bust and left customers out in the cold.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Are you suggesting coconuts migrate?"
Yep. We've even seen baby steps on this for the newest quantum secure communications.
One thing to always keep in mind regarding security is it all comes down to reward / (risk * cost) ratio. There is no absolute security, only cost, risk and the reward. Really, this can be expressed as either just risk or cost, as the two equate to dollars and those really factor down to time, which is our fundamental unit of value and wealth.
Labor applied to materials over time equals value, just FYI.
So then security is just time / reward, and that's the core realization to operate on.
If it's effectively a PITA to clone, and or the reward for cloning is not significant, the security will be effective. For very high rewards, no security will be effective, and that's just the way of things.
Legal means can be used to increase the potency of even modest security, as can adding material value that isn't software related. Products that depend on a data service, or that operate through contracts, or specialized materials all can significantly reduce the reward, while not impacting end user value, or in the best case, enhancing end user value. Social elements play here too. The reputation of the supply entity may well trump cloning, due to effective marketing, or early market penetration that can reinforce the value of the original over the clone. Simple human elements work too. Customer service, attachment to popular agendas, warranty, service, etc... all factor into the value proposition. Increasing the value perception in the minds of the people that will select the product can do a lot of damage on this problem, particularly if there is some risk inherent in the niche where the product will add value.
Ah well, if someone wants to pay big bucks to crack my code, let them have at it. I'll just tell them they could have bought it from me for half as much. [noparse];)[/noparse]
Comments
One heavily promoted and used mechanism for servicing interrupts was to have the driver, all drivers are user-level in QNX 6.x, receive an event from the kernel when it's registered interrupt had been activated. The kernel made no attempt at masking the device and didn't have a callback mechanism for the driver to do it. The kernel would instead mask the IRQ itself and then go back to scheduling tasks with, hopefully, that very driver being next on the list. The unmasking of the IRQ was entirely up to the driver's discretion as to when it happened. And, naturally, had little concern for any other device that might be trying to activate the same IRQ.
The other available interrupt servicing mechanism, of inserting a small callback interrupt function, was capable handling shared interrupts but it was frowned upon as "not being clean" because it ran with kernel privilege and naturally extremely limited calls and timing considerations.
I've not looked to see if they've done much to rectify the situation in the last few years. They may have now implemented something. I speculated on PCI having a standard for masking device IRQ sources, but failing that QSS would have to rewrite all their drivers to use the alternate mechanism if they wanted them to be shareable without the tell-tale glitching.
A reliable workaround was to make sure all devices had individual IRQs.
Aside from single chip solutions I doubt SPI will stop being used. SPI is about as low level as can be done. The only possible improvement I can think of that might supplant SPI is a simple modulated protocol that incorporates the clocking on the same signal. This reduces the bit-rate but has a distinctly stronger coherence - allowing greater distances to be spanned and is simple to bridge through other mediums.
Thing is, these modulated comms have always existed but haven't been adopted for inter-chip comms. Maybe the popularity of SPI and I2C have stifled them. Time will tell I guess.
Assuming we get past 2012 that is.
Happy new year all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
However, I do not expect anything like we use today to be around at all. If you look back over the last 40 years and how Moore's Law has continued to work and the advances made, there will be some other modulation method for sure.
Maybe they will be growing organic chips by then ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
SPI as a recognised name isn't all that old compared to the UART and it's various wrappers. SPI is somewhat simpler than the UART. And it's purpose is to cheapen board designs, particularly in small boards. It has excelled at this function and will keep doing so imho.
The computer industry is several decades old now and has effectively become a monopoly like arrangement that likes to keep moving the goal posts to keep everyone upgrading. Yet, for example, there is one area in the PC that uses SPI - the AC97 codecs. SPI performs this function beautifully and efficiently. The DRM czars may be hard at work changing it but even then the physical layer can still stay as SPI, just with encrypted data streams across it.
Or am I missing something?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The reason why this methodology (big word) works so well is tied to the nature of pipelining. If a compiler can identify parallel sequences within the procedure of the source code and then assemble them as interleaving instructions of multiple sequences, this will reduces the number of pipeline stalls that would otherwise occur.
This is obviously already done with C/Pascal compilers but I'm getting a distinct feeling that Java/C# compilers make no such attempts.
This can apply to the wider APIs and system calls too. Once it's done at this level then the compiler writers soon catch on. [noparse]:)[/noparse]
Is there somewhere we can have a summary of PropII specifications?
Thanks,
JM
Thanks,
JM
Or it could even emulate an EEPROM.
There will supposedly be a unique serial number, implemented as some "write once" fuse bits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
JM
Remember, hub accesses will happen every eight clock cycles, and there will apparently be a read/write quad long instruction - so the effective data rate will go up a lot.
No idea about the time line, I really wish I knew...
As you can tell from my site, I develop commercial products based on the Propeller, and would love to get Prop2 as soon as possible - but I think it won't happen soon.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
But I'm "propelling" for only few months, so I'm probably not the best one to say what should be added to the Prop2 [noparse];)[/noparse]
JM
What about OTP ROM ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Tony
http://zuzebox.wordpress.com/
There will be 32 (or was it 64?) fuse bits, and that's it - or at least that's the last I read in the other threads.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
like 128kb.
A serial number is a nice feature. You could use it to only allow
your code to run on boards you made. Of course there is really
no hard security on any uController available to the general public.
At least none that I am aware of.
Post Edited (HollyMinkowski) : 5/13/2010 5:03:09 AM GMT
break the protection of controllers.
What a sleazy way to make a buck.
If you google around you can probably find out who will
break that protection and how much $ it would cost.
The only good security seems to be when your hardware has to
phone home and be authorized to run. What a pain in the butt.
It would be like MS and the activation you go through to keep
windoze running.
Meh.. firmware patches take care of that. Your best bet is to make your product reasonably priced and well supported. People may clone what you have, but you have the first market advantage and can stay ahead of the pack.
Anything man can create, man can undo. I spent many hours in disassemblers and debuggers patching out "phone home" checks in old security and access control equipment where the manufacturer had gone bust and left customers out in the cold.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Are you suggesting coconuts migrate?"
One thing to always keep in mind regarding security is it all comes down to reward / (risk * cost) ratio. There is no absolute security, only cost, risk and the reward. Really, this can be expressed as either just risk or cost, as the two equate to dollars and those really factor down to time, which is our fundamental unit of value and wealth.
Labor applied to materials over time equals value, just FYI.
So then security is just time / reward, and that's the core realization to operate on.
If it's effectively a PITA to clone, and or the reward for cloning is not significant, the security will be effective. For very high rewards, no security will be effective, and that's just the way of things.
Legal means can be used to increase the potency of even modest security, as can adding material value that isn't software related. Products that depend on a data service, or that operate through contracts, or specialized materials all can significantly reduce the reward, while not impacting end user value, or in the best case, enhancing end user value. Social elements play here too. The reputation of the supply entity may well trump cloning, due to effective marketing, or early market penetration that can reinforce the value of the original over the clone. Simple human elements work too. Customer service, attachment to popular agendas, warranty, service, etc... all factor into the value proposition. Increasing the value perception in the minds of the people that will select the product can do a lot of damage on this problem, particularly if there is some risk inherent in the niche where the product will add value.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!