The way to add wireless for low cost is to put an ESP32 onto the Propeller 2 breakout board.
That gets you WIFI and Bluetooth.
Network connectivity for less than the price of an Ethernet jack.
Not to mention a device that is increasingly familiar to millions of hackers that they can feel comfortable with.
Building this kind of "bridge" is super sensible from a marketing and application perspective. While not all applications warrant IoT connectivity, it's worth adding just to attract users.
Given the amazingly low price of ESP chips/modules I would not worry about the fact that it contains an MCU. No more than we worry that there is an MCU inside SD cards and other such devices.
Having that CPU has some great advantages:
The whole protocol stack is taken care of for you.
As is security (TLS etc)
The ESP are very popular and familiar, increasingly so.
As I said, they are a familiar hook to catch the eye of the hacker to the unknown and alien Propeller.
Speaking of familiar "hooks" that would catch the eye of millions hackers around the world I think one of the first things to do with a P2 is create a Raspberry Pi Hat board.
..in a Pi Zero form factor. Or, maybe make the rest of the HAT (for the full RPi) a break-away protoboard. Make the break an edgecard that would allow someone to move the protoboard away from the Pi using a ribbon cable.
Following up on my earlier post, I'd like to convey some of my own experience with the difficulty of getting the company I work for to use the P1. Our company largely provides technical and engineering services for the US military, though we have done some commercial applications in the past (and possibly in the future). In all cases, we fall into the low-volume category. The hardware we design and fabricate is usually in sub-thousand quantities (even sub-hundred, often). As many of you are probably aware, when it comes to military applications, component pricing is rarely a significant factor in the design process. In our case, while the customer might have specific hardware requirements, it rarely extends to the choice of specific board components (they mostly care about general things like maintainability, durability, longevity, long-term availability, etc).
Given this, I have repeatedly encountered design requirements that I thought the P1 would be well suited for. However, translating this into actual adoption has been a complete non-starter. Some of the reasons are attributable to familiar barriers, while I think some have been due to the P1 itself.
The designers already have knowledge/experience around an existing MCU/CPU that can also fit their needs. To them, P1 is (they believe) entirely different from what they know.
The designers (those that knew how to code) are used to specific high-level libraries to avoid writing low-level code. They do not want to do "low-level" programming. I think this is mostly due lack of programming experience (they're mostly "hardware people").
Because this often starts as R&D, the designers tend to err on the side of excessive resources "just in case". The 32KB of RAM was regularly seen as a limiting factor.
Every single design has had analog requirements. With the P1, this has meant that every single design would have required additional components (compared to the chips they already know).
There are no P1 product I can point to that they can recognize/comprehend in a way that will encurage them to look closer. No, I don't mean the various projects that members talk about on the forum. I mean a product I can place in their hand that shows how the P1 solve the kinds of problems they encounter.
To a lesser extent, part of the has also end up being me. I've pushed the Propeller so many times that it has now become a kind of running joke. Yes, I have actually had someone tell me "not the Propeller" even before I brought it up (though, ironically, I wasn't actually going suggest it that time).
Now, having said all that, I think the P2 will be able to address a lot of those issues. Addressing those items, in the same order:
Taking some of the "lessons learned" from the P1 design, the P2 provides more of what people are used to with popular architectures. An primary example of this is support for interrupts. (No, they don't want to do low-level programming, they sure do get focus on low-level capabilities when they are looking for excuses!)
This isn't specifically resolved with the P2. Rather, this is about the software that supports it. Providing those high-level libraries (in C/C++, mostly) is going to be critical. Ideally, I would be able to show them that the P2 is designed with them in mind, and therefore doesn't necessarily require a high-level library to be productive. But I think that will only happen after they are using the P2. In other words, I think they will want a software "easy button" to get started, then afterwards come to the conclusion that the P2 is itself an "easy button".
The 576KB of RAM (hub, cog, lut) will likely be plenty big enough to feel "sufficient" for R&D efforts. Combine that with 64 I/O pins, and I think the P2 will actually be a very popular R&D "tool". I can argue that it will be great for rapid prototyping. For this, having a module (with easy prototyping in mind) will be very helpful. If I can convince them that the P2 is the easy path for the early work, I think that will be the "foot in the door" that allows it to also be used in the final product.
Analog and Smart pins are going to be huge! US military hardware is rife with one-off "standard" interfaces. Not a single one of them is I2C, SPI, etc, meaning that the vast majority of off-the-shelf chips are incapable of supporting these interfaces (short of bit-banging with hardware that was not meant to be used that way).
When it compes to the P2, I hope I won't have to start with a "look what others did" example. Again, having a module might be helpful here. Suppose, for instance, that the module is a compact, self-contained edgecard or castellated PCB. For rapid prototyping (see earlier comment), this would be pre-mounted to a break-out board. The designer's focus will initially be on the prototyping board, not necessarily the module itself. However, when the time comes to design a more permanent board, it will quickly become obvious that the module itself could be re-used in the design. However, since these products often have to deal with harsh environmental constraints, it is also necessary to be able to easily reproduce the module's layout directly within the final design. I think most designers will see this as an easy way forward (no need to do that part of the design work themselves). Of course, this isn't quite the same as having an existing consumer product that they can relate to, but that will hopefully come with time. I just don't want to wait until that time to convince them of the value of the P2.
Now, there is also another barrier I will have to overcome, which was also due to me (sort of). I regularly talk to my co-workers about the P2. It also means that they are accutely aware of the lack of actual silicon. This is starting to approach Duke Nukem Forever proportions. Ot unicorns. Whichever you prefer. I don't want to stop talking about the P2, but I also don't want my co-workers to tune me out ("blah-blah-blah mythical propeller product blah-blah-blah"). The point is, the chip needs to be available yesterday. "Perfect is the enemy of the good" and all that!
Anyhow, I don't know if there's useful feedback in any of that. But I hope it gives an appreciation for the difficulty of convincing others (at least, in my case) to take a look at the propeller. Take it or leave it as you want.
Personally, I am salivating over the prospect of a single chip handling eight axes, each with two feedback devices, one for the actuator and one for the load.
Now if it will be possible to handle BiSS in firmware...
Do you have any real sensor examples of data packets ?
Hmm, some details of that may be outside P2 Smart-Pins, but it is certainly worth trialing...
The cable-length auto-adjust for example, might be managed with either an Async-start-bit approach, or an armed-SyncRX, waiting on a Wait-Pin trigger.
For the latter, Chip would need to indicate the SysCLK latencies for Wait-Pin SW polling -> Start RX - I think that's low single digits ?
Once properly triggered, in either approach, the serial-length becomes an issue, as BiSS needs continual RX of over 1024 bits if I read the specs right ?
That length looks to exclude Async-start, but triggered Sync serial might be able to stream continually.
Some aspects of slave cascade look to emulate a D-FF, which is also outside Smart-Pin support unless some USB details help there ?
Failing smart pin use, there is always bit-bang support, which should be good to some MBd, and it may be easiest to start with Bit-Bang code, and then see how Smart-Pins can assist. This BiSS looks like it needs a whole new thread....
I'll wish that a little more effort have been done with Ethernet.
It would greatly benefit to all those applications (robotic, motion control, test and measurement, signal processing) designed to feed data to a higher-end processor (or PC).
The benefit of Ethernet over USB is that Ethernet only requires one third (or 1/5) the R&D effort on software development (not to mention the benefits of not needing a new driver with every new Windows version).
Think that any USB application will need drivers for at least three platforms (Windows, Mac, Linux, all of them x86). Nowadays people is also asking for USB Raspberry Pi and Android drivers (both ARM).
With ethernet you don't have to worry about any of that (it doesn't matter if it is Win/Mac/Linux, x86 or ARM).
Just a simple hardware CRC32 instruction (or peripheral) combined with the amazing power of 16 cogs could open the door to something UNIQUE.
I would not discount Ethernet entirely...
The 80MHz speed made any Ethernet support testing tricky, but now there is > 100MHz, this may be more practical.
Any Ethernet solution will need at least a PHY, (MII, RMII), so other options there are Ethernet chips, or 'smallest-mcu-with-ethernetMAC+PHY', or 'USB-Ethernet bridges' (if those are ok at FS USB)
Heater : The way to add wireless for low cost is to put an ESP32 onto the Propeller 2 breakout board.
That gets you WIFI and Bluetooth.
It just seems that all the modules I can find are wireless+MCU... Somehow, seems would lower cost to get wireless w/o MCU...
Was just looking on Digikey... Like the look of CC2500. Needs just a couple external items and has SPI interface...
In theory, wireless w/o MCU may somehow seem cheaper, but it's all about sales volumes , plus MCU included takes care of the stack.
The final WiFi+Bluetooth (+LoRa ?) module or device decision can be made much later, nearer P2 volume silicon.
This is a fast moving sector, and what looks good today, might be old-hat later.
The ESP32 does have a number of appeals..
A couple of non-technical appeals are a) it is not ARM, and b) it uses RAM, just like P2
From a technical/SW side, it is the 'new ESP8266', so will have the critical mass when P2 releases.
Another new customer for the P2 will be C/C++ programmers who tried the P1, but couldn't get their application to fit in 32K. With 512K of RAM, the P2 will be more attractive to C/C++. A program with full printf support and file I/O and floating point support will probably take less than 64K, which will leave lots of RAM available for data and graphics. The P1 required a lot of effort to trim the size of the generated code so it would fit in 32K. We won't have to mess around with things like simple_printf and limited file support on the P2. The P2 is going to be lots of fun to program.
It will be important to have Spin support for all the loyal Spin programmers. However, I believe there will be many more C/C++ programmers on the P2. Parallax should put their time and money into supporting and promoting C/C++ development on the P2 so that the tools are available when the silicon comes out.
I remember early on that there was a Professor(can't remember), who used the Prop to teach MCUs to his undergraduates. They learned the necessary theory and hooked up all kinds of sensors and devices for their final grades, an absolutely outstanding demonstration of the Prop's capabilities and easy of use.
To do something similar with the P2, you would have to add a level or two and get M.S. or PhD candidates to explore the suitability of the P2 for use in
research into exotic but popular technologies... Chip could come up with a list:) I don't know for sure but I'm thinking TOF, 3D ultrasound, etc.
It would be useful for grant applicants for Parallax to state a delivery date.... it doesn't have to be right, it just has to convince the givers of money.
The P2 is a little ... let's just say... it kind of intimidates a grown man:) Using some of the fine engineers we have hanging around here... it might be good
to spend (large) on a range of very surprising technology demonstrations. "Nothing scary around here@:) The rational for the board would be to develop kits for the product line... but the actual purpose is to convince working engineers (who produce on a budget and a schedule) that they can do what they want with the P2 and it won't take them forever to do it.
Computers can be hacked... anything that depends on a network can be hacked. A P2 alone in nature can't be touched. In some important contexts, the P2 is a nice backup when the networks go down and the computers fail.
It is a National Security thingy ...
When the security perspective is properly placed before the right people, we can stop worrying about who is going to buy the P2 and we can all move on to the joy of exploring 28nm!!!
We have a National Bird... what we need is a National MCU... it is the digital age: We don't need birds... We need MCUs.
p.s.
We talk about the importance of innovation... and then we let the innovators hang out to dry? Come on guys.... pick up the phone.
You know who you are.
One of the main questions that I have: Will the Prop 2 have interrupts so that we may port code from other sources? I think a lot of Prop 2s market share will be driven by the code base that is available to used with the chip.
If other sources of code, which use interrupts, can easily be ported to the Prop 2, I think that your markets could become an endless stream, because I think it will be adaptable to many different uses, with many unique advantages. This would help promote a lot of different porting, thus increasing your code base.
Yes. Each COG has them, and they are triggered on a variety of events.
To your knowledge, do you believe that we will now be able to easily port other code sources which utilize interrupts to use with these cog interrupts?
Yes. Each COG has them, and they are triggered on a variety of events.
To your knowledge, do you believe that we will now be able to easily port other code sources which utilize interrupts to use with these cog interrupts?
Not necessarily. P2 does have interrupts, but this goes only so far. If you are currently using a PIC (for example), you have a single core that's relying heavily on interrupts to interact with the peripherals. You will not be able to just port this to a single cog, as the P2 cog's "interrupt vector table" is not equivalent. Designs will still need to be broken into multiple discrete sections that will run across multiple cogs. Even then, the kind of interrupts you are dealing with are different. For instance, on a PIC, you are typically dealing with high-level, interface-specific interrupts. On the P2, the interrupts are a bit more low-level and/or generic. In other words, there is a bit of a dissonance between "traditional" MCU interrupts and what the P2 provides. Even if you were to dedicate cogs to being just interface drivers (e.g. SPI), your main program still has limited ability to be interrupted by these drivers. More specifically, any one cog can set up a maximum of three interrupt handlers at any given time. Beyond that, it must depend on other notification mechanisms. Or, if interrupts are critical, you have to spread your design across multiple cogs.
Based on the code I've encountered, particularly when written by other-than-software engineers (I'm not making a dig here, just stating my experience), it is usually very monolithic and rigid. Migrating these codebases are impractical.
Yes. Each COG has them, and they are triggered on a variety of events.
To your knowledge, do you believe that we will now be able to easily port other code sources which utilize interrupts to use with these cog interrupts?
Not necessarily. P2 does have interrupts, but this goes only so far. If you are currently using a PIC (for example), you have a single core that's relying heavily on interrupts to interact with the peripherals. You will not be able to just port this to a single cog, as the P2 cog's "interrupt vector table" is not equivalent. Designs will still need to be broken into multiple discrete sections that will run across multiple cogs. Even then, the kind of interrupts you are dealing with are different. For instance, on a PIC, you are typically dealing with high-level, interface-specific interrupts. On the P2, the interrupts are a bit more low-level and/or generic. In other words, there is a bit of a dissonance between "traditional" MCU interrupts and what the P2 provides. Even if you were to dedicate cogs to being just interface drivers (e.g. SPI), your main program still has limited ability to be interrupted by these drivers. More specifically, any one cog can set up a maximum of three interrupt handlers at any given time. Beyond that, it must depend on other notification mechanisms. Or, if interrupts are critical, you have to spread your design across multiple cogs.
Based on the code I've encountered, particularly when written by other-than-software engineers (I'm not making a dig here, just stating my experience), it is usually very monolithic and rigid. Migrating these codebases are impractical.
I'm also not sure why you'd want to migrate them to the P2. It seems to me that if your alternate MCU is currently doing the job then you may as well stick with it. It's probably cheaper than P2 will be. What makes sense is to implement new designs using P2 that can make use of its unique features. Trying to make the P2 look like your garden variety MCU is not likely to be productive.
I'm also not sure why you'd want to migrate them to the P2. It seems to me that if your alternate MCU is currently doing the job then you may as well stick with it. It's probably cheaper than P2 will be. What makes sense is to implement new designs using P2 that can make use of its unique features. Trying to make the P2 look like your garden variety MCU is not likely to be productive.
Agreed. In fact, I think a compelling argument you could make is that the P2 allows other-than-software engineers to write software in a more natural way than traditional MCUs require. This plays to the "Propeller is for the People" mantra, where "people" in this case means "hardware engineers that must also write software".
Parallax might want a tool like Cypress PSoC Creator that lets you easily configure peripherals and automatically create a simple API for controlling them. I've used a PSoC chip in a recent project and it's pretty easy to configure the hardware.
I suspect Bruce is thinking about the Teacup 3D printer firmware that uses timer interrupts. I think the interrupts in the P2 will make it easier to port this code. On the P1, interrupts could be simulated by running code in different cogs. However, the code assumed that only one thread is running at a time, which isn't the case when using multiple cogs. The interrupt capability in the P2 will be a very useful feature.
I suspect Bruce is thinking about the Teacup 3D printer firmware that uses timer interrupts. I think the interrupts in the P2 will make it easier to port this code. On the P1, interrupts could be simulated by running code in different cogs. However, the code assumed that only one thread is running at a time, which isn't the case when using multiple cogs. The interrupt capability in the P2 will be a very useful feature.
Yes, I was being a bit selfish in my thoughts, and some of my thoughts were directly related to the attempted Teacup port, as well as other timer related interrupt CNC firmware. However, any existing code base which can be more readily ported to the P2 would be a great asset in my opinion, otherwise you will basically be building a code base for the P2 from scratch (just like the P1), thus making it more difficult for rapid deployment of a P2 related design.
One of the most important benefits of an existing code base, besides having to create a new one, is the fact that the firmware in it's original state, will most likely have been extensively used, tested, and promoted. EDIT: and periodically updated and enhanced.
Parallax might want a tool like Cypress PSoC Creator that lets you easily configure peripherals and automatically create a simple API for controlling them. I've used a PSoC chip in a recent project and it's pretty easy to configure the hardware.
Certainly, many vendors have GUIs/Forms for setting up their peripherals.
Some are better than others...
They do need care, and are a common source of bugs, when they only 'almost get it right'...
SmartPin setup should be simpler, as there are less 'scattered flags' in many registers that can affect the outcome, but SmartPins also have some caveats.
The nearby-pin mux is one, that will need some means to correlate across smart pins, another is that the PinID might be a param, so late-config will be more common,
and that rather works against init-file config generators.
Some of my peeves of some others' GUIs/Forms:
* failing to report the actual baud result value and error
* Not allowing code revisions/version control via form
The second one is not easy to solve, - some remember your settings and you can edit those and export a new template you paste, but now version control fragments.
Others uses include files, but that means one per configured item, which can rapidly explode..
Some of my peeves of some others' GUIs/Forms:
* failing to report the actual baud result value and error
* Not allowing code revisions/version control via form
The second one is not easy to solve, - some remember your settings and you can edit those and export a new template you paste, but now version control fragments.
Others uses include files, but that means one per configured item, which can rapidly explode..
Yeah, the idea of stuffing critical things into lots of cubbyholes freaks me out, too. It makes me want to design in such a way where 7-bit ASCII will always be the best means to program and configure the system. That means keeping bits together that belong together and not scattering things all over the place - where in the worst case, you are compelled to have a GUI manage it for the user, and conglobulate the whole mess into a static configuration that is opaque.
Based on the code I've encountered, particularly when written by other-than-software engineers (I'm not making a dig here, just stating my experience), it is usually very monolithic and rigid. Migrating these codebases are impractical.
Hehe, well yes... but I'd split this more into low-level code, and higher level code issue.
Low -level code tightly interacts with peripheral hardware registers, & includes interrupts.
That always has poor portability.
One of the most important benefits of an existing code base, besides having to create a new one, is the fact that the firmware in it's original state, will most likely have been extensively used, tested, and promoted. EDIT: and periodically updated and enhanced.
Yes, but as mentioned above, any existing code base has 2 portions.
The higher level code, should be more portable, and is usually what changes once the low-level code is done.
Porting of low-level AVR code, that tightly uses PWM/Timers/Interrupts is never going to be trivial, and will be worse if the AVR was pushed to do the tasks.
The good news is the P2 is (mostly? ) a massive superset of AVR peripheral capabilities, and so real-time CNC type apps should be far easier to manage.
I'm also not sure why you'd want to migrate them to the P2. It seems to me that if your alternate MCU is currently doing the job then you may as well stick with it. It's probably cheaper than P2 will be.
A common reason to migrate, is when the alternate MCU is 'saturated', and cannot accept a required revision.
The AVR as CNC controller is a good example of a 'saturated controller', and P2 can give that app control-space headroom in a way no ARM M4 can.
.. What makes sense is to implement new designs using P2 that can make use of its unique features. ..
I would slightly rephrase that, to it makes sense to use P2's unique features, to take an existing design that is failing/saturated, and show just how much improvement is possible.
The good news is the P2 is (mostly? ) a massive superset of AVR peripheral capabilities, and so real-time CNC type apps should be far easier to manage.
Specific to CNC, I don't believe that managing is the issue. I believe the issue is having a code template to start with, so that a person or company can build a CNC application, without having to do it from the ground up. At this point, I have reviewed a fair share of CNC and 3D printer firmware, and every piece of popular firmware related to these two, have had a lot of time, energy, and thought poured into them.
Starting one from scratch, that would have the same capabilities as one of the popular ones, would take a person a very long time, as well as a project that has had several people working on it. As you know, every person has strengths and weaknesses, and much of the existing popular firmware has received the strengths of various supporters and individuals.
I certainly don't have the drive, ambition, or intelligence, to create a piece of CNC firmware from scratch which is equivalent to some of the popular firmware that already exists as open source. However, I would have the drive, ambition, and hopefully the intelligence to port it to a Propeller if it is feasible.
Comments
Building this kind of "bridge" is super sensible from a marketing and application perspective. While not all applications warrant IoT connectivity, it's worth adding just to attract users.
Ken Gracey
Having that CPU has some great advantages:
The whole protocol stack is taken care of for you.
As is security (TLS etc)
The ESP are very popular and familiar, increasingly so.
As I said, they are a familiar hook to catch the eye of the hacker to the unknown and alien Propeller.
..in a Pi Zero form factor. Or, maybe make the rest of the HAT (for the full RPi) a break-away protoboard. Make the break an edgecard that would allow someone to move the protoboard away from the Pi using a ribbon cable.
Given this, I have repeatedly encountered design requirements that I thought the P1 would be well suited for. However, translating this into actual adoption has been a complete non-starter. Some of the reasons are attributable to familiar barriers, while I think some have been due to the P1 itself.
To a lesser extent, part of the has also end up being me. I've pushed the Propeller so many times that it has now become a kind of running joke. Yes, I have actually had someone tell me "not the Propeller" even before I brought it up (though, ironically, I wasn't actually going suggest it that time).
Now, having said all that, I think the P2 will be able to address a lot of those issues. Addressing those items, in the same order:
Now, there is also another barrier I will have to overcome, which was also due to me (sort of). I regularly talk to my co-workers about the P2. It also means that they are accutely aware of the lack of actual silicon. This is starting to approach Duke Nukem Forever proportions. Ot unicorns. Whichever you prefer. I don't want to stop talking about the P2, but I also don't want my co-workers to tune me out ("blah-blah-blah mythical propeller product blah-blah-blah"). The point is, the chip needs to be available yesterday. "Perfect is the enemy of the good" and all that!
Anyhow, I don't know if there's useful feedback in any of that. But I hope it gives an appreciation for the difficulty of convincing others (at least, in my case) to take a look at the propeller. Take it or leave it as you want.
Thanks for all your thoughts, so far.
Do you have any real sensor examples of data packets ?
Hmm, some details of that may be outside P2 Smart-Pins, but it is certainly worth trialing...
The cable-length auto-adjust for example, might be managed with either an Async-start-bit approach, or an armed-SyncRX, waiting on a Wait-Pin trigger.
For the latter, Chip would need to indicate the SysCLK latencies for Wait-Pin SW polling -> Start RX - I think that's low single digits ?
Once properly triggered, in either approach, the serial-length becomes an issue, as BiSS needs continual RX of over 1024 bits if I read the specs right ?
That length looks to exclude Async-start, but triggered Sync serial might be able to stream continually.
Some aspects of slave cascade look to emulate a D-FF, which is also outside Smart-Pin support unless some USB details help there ?
Failing smart pin use, there is always bit-bang support, which should be good to some MBd, and it may be easiest to start with Bit-Bang code, and then see how Smart-Pins can assist. This BiSS looks like it needs a whole new thread....
I would not discount Ethernet entirely...
The 80MHz speed made any Ethernet support testing tricky, but now there is > 100MHz, this may be more practical.
Any Ethernet solution will need at least a PHY, (MII, RMII), so other options there are Ethernet chips, or 'smallest-mcu-with-ethernetMAC+PHY', or 'USB-Ethernet bridges' (if those are ok at FS USB)
The final WiFi+Bluetooth (+LoRa ?) module or device decision can be made much later, nearer P2 volume silicon.
This is a fast moving sector, and what looks good today, might be old-hat later.
The ESP32 does have a number of appeals..
A couple of non-technical appeals are a) it is not ARM, and b) it uses RAM, just like P2
From a technical/SW side, it is the 'new ESP8266', so will have the critical mass when P2 releases.
It would be in interesting board to have that plus a P2.
Besides wifi and BTLE, adds:
RTC
10 capacitive touch
Hall sensor
Temperature sensor
Not really sure why it has a Hall sensor, but it is interesting...
Anyway, if Parallax made a board like that easy to use, would have a lot of appeal, I think...
I don't see what kind of throughput speed you can get over Wifi though...
Would be real nice if could stream video from camera attached to P2...
It will be important to have Spin support for all the loyal Spin programmers. However, I believe there will be many more C/C++ programmers on the P2. Parallax should put their time and money into supporting and promoting C/C++ development on the P2 so that the tools are available when the silicon comes out.
I think that Hall effect device is just there to make really simple IoT detection of open doors and so on. Quite a neat idea.
Why would the speed of WIFI be an issue for video? I'm watching video over WIFI all the time.
To do something similar with the P2, you would have to add a level or two and get M.S. or PhD candidates to explore the suitability of the P2 for use in
research into exotic but popular technologies... Chip could come up with a list:) I don't know for sure but I'm thinking TOF, 3D ultrasound, etc.
It would be useful for grant applicants for Parallax to state a delivery date.... it doesn't have to be right, it just has to convince the givers of money.
The P2 is a little ... let's just say... it kind of intimidates a grown man:) Using some of the fine engineers we have hanging around here... it might be good
to spend (large) on a range of very surprising technology demonstrations. "Nothing scary around here@:) The rational for the board would be to develop kits for the product line... but the actual purpose is to convince working engineers (who produce on a budget and a schedule) that they can do what they want with the P2 and it won't take them forever to do it.
Computers can be hacked... anything that depends on a network can be hacked. A P2 alone in nature can't be touched. In some important contexts, the P2 is a nice backup when the networks go down and the computers fail.
It is a National Security thingy ...
When the security perspective is properly placed before the right people, we can stop worrying about who is going to buy the P2 and we can all move on to the joy of exploring 28nm!!!
We have a National Bird... what we need is a National MCU... it is the digital age: We don't need birds... We need MCUs.
p.s.
We talk about the importance of innovation... and then we let the innovators hang out to dry? Come on guys.... pick up the phone.
You know who you are.
SPI interface may not be fast enough to transmit video...
Probably want 8-bit interface...
BTW: Great C++ is a perfect reason to upgrade to P2
If other sources of code, which use interrupts, can easily be ported to the Prop 2, I think that your markets could become an endless stream, because I think it will be adaptable to many different uses, with many unique advantages. This would help promote a lot of different porting, thus increasing your code base.
If not...
To your knowledge, do you believe that we will now be able to easily port other code sources which utilize interrupts to use with these cog interrupts?
Not necessarily. P2 does have interrupts, but this goes only so far. If you are currently using a PIC (for example), you have a single core that's relying heavily on interrupts to interact with the peripherals. You will not be able to just port this to a single cog, as the P2 cog's "interrupt vector table" is not equivalent. Designs will still need to be broken into multiple discrete sections that will run across multiple cogs. Even then, the kind of interrupts you are dealing with are different. For instance, on a PIC, you are typically dealing with high-level, interface-specific interrupts. On the P2, the interrupts are a bit more low-level and/or generic. In other words, there is a bit of a dissonance between "traditional" MCU interrupts and what the P2 provides. Even if you were to dedicate cogs to being just interface drivers (e.g. SPI), your main program still has limited ability to be interrupted by these drivers. More specifically, any one cog can set up a maximum of three interrupt handlers at any given time. Beyond that, it must depend on other notification mechanisms. Or, if interrupts are critical, you have to spread your design across multiple cogs.
Based on the code I've encountered, particularly when written by other-than-software engineers (I'm not making a dig here, just stating my experience), it is usually very monolithic and rigid. Migrating these codebases are impractical.
Agreed. In fact, I think a compelling argument you could make is that the P2 allows other-than-software engineers to write software in a more natural way than traditional MCUs require. This plays to the "Propeller is for the People" mantra, where "people" in this case means "hardware engineers that must also write software".
Yes, I was being a bit selfish in my thoughts, and some of my thoughts were directly related to the attempted Teacup port, as well as other timer related interrupt CNC firmware. However, any existing code base which can be more readily ported to the P2 would be a great asset in my opinion, otherwise you will basically be building a code base for the P2 from scratch (just like the P1), thus making it more difficult for rapid deployment of a P2 related design.
One of the most important benefits of an existing code base, besides having to create a new one, is the fact that the firmware in it's original state, will most likely have been extensively used, tested, and promoted. EDIT: and periodically updated and enhanced.
Some are better than others...
They do need care, and are a common source of bugs, when they only 'almost get it right'...
SmartPin setup should be simpler, as there are less 'scattered flags' in many registers that can affect the outcome, but SmartPins also have some caveats.
The nearby-pin mux is one, that will need some means to correlate across smart pins, another is that the PinID might be a param, so late-config will be more common,
and that rather works against init-file config generators.
Some of my peeves of some others' GUIs/Forms:
* failing to report the actual baud result value and error
* Not allowing code revisions/version control via form
The second one is not easy to solve, - some remember your settings and you can edit those and export a new template you paste, but now version control fragments.
Others uses include files, but that means one per configured item, which can rapidly explode..
Yeah, the idea of stuffing critical things into lots of cubbyholes freaks me out, too. It makes me want to design in such a way where 7-bit ASCII will always be the best means to program and configure the system. That means keeping bits together that belong together and not scattering things all over the place - where in the worst case, you are compelled to have a GUI manage it for the user, and conglobulate the whole mess into a static configuration that is opaque.
Low -level code tightly interacts with peripheral hardware registers, & includes interrupts.
That always has poor portability.
Yes, but as mentioned above, any existing code base has 2 portions.
The higher level code, should be more portable, and is usually what changes once the low-level code is done.
Porting of low-level AVR code, that tightly uses PWM/Timers/Interrupts is never going to be trivial, and will be worse if the AVR was pushed to do the tasks.
The good news is the P2 is (mostly? ) a massive superset of AVR peripheral capabilities, and so real-time CNC type apps should be far easier to manage.
A common reason to migrate, is when the alternate MCU is 'saturated', and cannot accept a required revision.
The AVR as CNC controller is a good example of a 'saturated controller', and P2 can give that app control-space headroom in a way no ARM M4 can.
I would slightly rephrase that, to it makes sense to use P2's unique features, to take an existing design that is failing/saturated, and show just how much improvement is possible.
Specific to CNC, I don't believe that managing is the issue. I believe the issue is having a code template to start with, so that a person or company can build a CNC application, without having to do it from the ground up. At this point, I have reviewed a fair share of CNC and 3D printer firmware, and every piece of popular firmware related to these two, have had a lot of time, energy, and thought poured into them.
Starting one from scratch, that would have the same capabilities as one of the popular ones, would take a person a very long time, as well as a project that has had several people working on it. As you know, every person has strengths and weaknesses, and much of the existing popular firmware has received the strengths of various supporters and individuals.
I certainly don't have the drive, ambition, or intelligence, to create a piece of CNC firmware from scratch which is equivalent to some of the popular firmware that already exists as open source. However, I would have the drive, ambition, and hopefully the intelligence to port it to a Propeller if it is feasible.