Educational sales enabled the development of the P1 and are doing the same for P2. To be specific: robots, Blockly, educator's courses, supporting teachers, offering a quality product with warranty are all ingredients to Parallax's business model. And yes, the Propeller 1 is at the core of these efforts - especially Blockly!
I understand a point made by Sandy and agree with part of his statement. However (as several pointed out), more than NOT serving a particular customer type, Parallax will need to segment the customer base and speak to BOTH commercial and educational customers on their terms. We have attempted this in the past with Parallax Semiconductor. Eventually we disrupted the Parallax Semiconductor business (with FAEs, a web site, separate phone number) to focus on our educational efforts. The focus (and there can be more than one) will be towards a viable, self-sustaining business of course.
We will soon be looking at what it means to have the P2 as part of our business planning. There will be many productive discussions around this, starting with Chip's vision. In fact, the crowd-sourcing from this exact thread charts the course very clearly. You tell us how to run our business to a large extent, and these pieces become part of our plan. It could be a mix of Spin2, Propeller Expos and a strong user base. Or, it could be a well-funded commercial effort with leadership in specific markets. These pieces are all being discussed.
Love Blockly, if you will. It's really appreciated when the rare educators stumbles into our forums and asks questions. Time and time again you all go out of your way to help that person out. At this moment, Parallax is getting into more classrooms than ever before. And this isn't a confused, viral "gotta have it" kind of thinking where educators buy the latest kit, but a sound, sensible adoption with solid equipment and tutorials. The core attributes our customers report back to us (their words) are features/benefits that simply don't exist with their current hardware. At the core of it is student interest. When students enjoy what they're doing, we ALL win!
Educational customers will expect to grow with all of us when P2 is released. Take a look at what they think about our present system:
I recently attended Parallax’s Blockly Training course and was blown away. As an educator, I always appreciate how thoroughly vetted and documented Parallax material is. It makes is so effortless for an educator to pick up programming and robotics. My students have been introduced into the joy of robotics for over a decade using Parallax robotics kits. In my opinion they are second to none in their thoroughness of teaching: electronics, electricity, wiring, and programming. Their Blockly kits take this to a whole new level! Students can be up and running in no time.
The most difficult part of teaching programming is the first few weeks. This is when many students get frustrated by difficult programming language, and are turned off from programming. The Blockly platform is perfect for teaching programming. Students get instant functionality out of their robots while learning important aspects of programming like variables, frequency, timing, etc. It provides better stepping stones than traditional programming classes.
The beauty of Blockly is that students are programming right from the beginning. Their isn’t the disappointment for students that are poor at typing or have difficulty understanding the logic of programming. With Blockly, they get it right away.
Blockly and Parallax is a perfect combo. The system works so well for differentiated instruction. Struggling students will see results early while picking up programming logic; simultaneously advanced students can toggle back and forth with the C screen to further develop their programming arsenal.
Thank you Parallax for making learning so easy. Every company in the world should do customer support like you do. Parallax actually lays out tutorial sheets for every command and component they utilize. I am not talking techie lingo that doesn’t make any sense either. I am talking clear to follow instructions with examples and explanations. Simply amazing. In addition, when you call the help desk, you get to talk to a real person!
Parallax robots are engaging. I once had a teacher come visit my class during our robotics section and they couldn’t believe how totally engrossed the students were into their robots. They were rushing me to get role done so they could start work, and then rushed off to get their robots, and immediately started working. All without a word from me. This visiting teacher was absolutely amazed.
John Agostinelli
CRANE Coordinator
Engineering Pathways
Mather, CA 95826
Ken Gracey
That's an excellent review, Ken. You and Parallax should be proud. Of course, we already knew Parallax was great with great products - that's why we're here!
It's not just the one language that makes sense. With Blockly, kids can get started without programming knowledge. When they outgrow it, they have a base to look at what their code produced, and then cango further if they desire. The hardest part is getting the kids interested. They have so many different things they can do, so they need something interesting orthey move on.
I had my eye on prop 1 for a while never used it though I had a starter kit for a year. Recently I started looking for parallel tasks like reading from gyros, accelerometers, magnetometers, and other sensors to find orientation in quad copters also to do some neural network stuff make certain filters to properly control copters. I think parallex prop can do it. My first problem I faced was c was easy but I was not able to harness all core to do pwm on 4 cogs to control 4 motor speeds.
I love the capability of prop1 to display video but I don't think its should be on chip.(ye game developers would love it though but its past, or just keep single core with pal/ntsc video generator)
also if you checkout the vive lighthouse or VR controllers I think parallax props will be great at doing all stuff fast & parallel.
@Trailblazer47: There's actually very little hardware on the chip for video generation. Most of the work is done by software. The video generator is essentially a shift register to shift out the video data a little faster than the cog could do by itself. If you've noticed, NTSC/PAL can be handled by a single cog. VGA takes one or more cogs depending on the resolution. Higher resolutions take up to 6 cogs taking turns fetching data, then rendering the data for one or more lines of video, then outputting the video. Look at the various video driver objects in the Propeller Object Exchange if you're interested in details.
Surely the processor used for Blockly/education products is irrelevant?
There are plenty of drag-and-drop 'languages' that run on single-core processors. And plenty of those are in the sub 1$ price range.
Educators would appreciate the sub-$1 domain with Blockly support, but there's much more to it than that. If that was the only filter a supplier had to pass we'd be out of business. There requirements are more like this:
(x) Tutorials, Assessment material and standards alignment (educators have access to the latter two pieces)
(x) Professional Development (we offer about 15 courses/year)
(x) Robotics kits, under $200 (we are the leader here)
(x) Ready to go hardware, sensor kits
(x) Chromebook support (announced today)
(x) code.org relevancy (uses Blockly)
(x) Warranty, quality product with support (yes, as you know)
Our Blockly has multicore support with a "new processor" block.
As engineers and skilled programmers, it can be difficult to shift mindset to that of an educator. They don't program and build circuits for a career; this is all new to them. They need a reliable system, backed by people who can help them, along with a mix of the right technology and tutorials.
Did Blockly originate from 12 blocks? He developed a nice system, but our customers wouldn't adopt a licensed, closed software in mass. While Hanno was certainly early to this kind of visual programming, it goes way back before Google. Watch my webinar for some details just how far back it goes:
I had to talk about a virtual robot product in that webinar as they sponsored the effort, but the early 15 minutes provide some historical review taking you back the early 70s.
Surely the processor used for Blockly/education products is irrelevant?
That rather depends on whether you can have parallel blocks executing simultaneously in Blockly. I have no idea having never played with it.
Now you know.
Very nice! Is there a way to communicate with a program running on another COG? I guess I'm asking about a mailbox interface that would allow the main COG to interact with the subordinate COGs.
Very nice! Is there a way to communicate with a program running on another COG? I guess I'm asking about a mailbox interface that would allow the main COG to interact with the subordinate COGs.
Do you mean variable sharing? All vars are global. You're a programmer and I'm a bit of a hack; rephrase your question please.
Very nice! Is there a way to communicate with a program running on another COG? I guess I'm asking about a mailbox interface that would allow the main COG to interact with the subordinate COGs.
Do you mean variable sharing? All vars are global. You're a programmer and I'm a bit of a hack; rephrase your question please.
Okay, I guess if all variables are global then any variable can be shared. Thanks.
Very nice! Is there a way to communicate with a program running on another COG? I guess I'm asking about a mailbox interface that would allow the main COG to interact with the subordinate COGs.
Do you mean variable sharing? All vars are global.
You mean all VARs are in HUB ? (none are in COG)
One example of cross-cog communication, would be to have the " red LED " function, ramp the greenLED var, within a defined range.
General comments:
Blocky seems to tolerate white spaces in function names, and the quotes suggest there may be leading and trailing spaces too ?
That's probably not the best idea for moving to any other language ?
I've written (assembled?) a Blockly program to run an ActivityBot using a SIRC interface and a TV remote. The bot has "whiskers" for detecting when it runs into something. Because of an unacceptable delay between object detection and response if I had that function running in the main cog, I run it in a second cog. When the object is detected a flag is set that tells the main cog that the detect cog is now controlling motion. Once the response is completed the flag is reset and the bot again accepts commands from the TV remote.
I had previously written the program in C and wanted to see how it translated to blockly.
It was interesting to build the program from my original logic notes without having to keep track of braces or semicolons. The biggest issue was how quickly the screen filled up when having to use a large number of nested if-else if blocks all of the remote control options I had. Since I wrote that program, Parallax has added arrays and case blocks which would have help condense the number of blocks.
I tried Blockly once, and I do think it's a good tool to introduce people to programming. I would play around more with blockly, but I'd prefer to do it on my own computer instead of through the Internet. Is it possible to install a Blockly app locally? Also, I recall that I had to store my program in the cloud. Can I store a blockly program on my own computer, where only I can access it?
I tried Blockly once, and I do think it's a good tool to introduce people to programming. I would play around more with blockly, but I'd prefer to do it on my own computer instead of through the Internet. Is it possible to install a Blockly app locally? Also, I recall that I had to store my program in the cloud. Can I store a blockly program on my own computer, where only I can access it?
My only concern with Blockly is that Parallax is trusting Google to continue supporting it. But that trust may be misplaced, given Google's track record. More than once they've pulled the rug out from under developers who relied upon their tools.
I developed some great apps for my robotics class that relied upon the Google Earth API. Well, guess what? They deprecated it without a viable alternative, and all the work I did is now for naught.
I'd really hate to see that happen to Parallax, since they've put so much energy and capital into Blockly.
Phil,
As far as I know, Blockly doesn't need google servers and is open source. So Google can't kill BlocklyProp, because parallax runs the servers and maintains the code.
Google can stop updating the source, or supporting Blockly itself, but that won't kill it.
My only concern with Blockly is that Parallax is trusting Google to continue supporting it. But that trust may be misplaced, given Google's track record. More than once they've pulled the rug out from under developers who relied upon their tools.
I developed some great apps for my robotics class that relied upon the Google Earth API. Well, guess what? They deprecated it without a viable alternative, and all the work I did is now for naught.
I'd really hate to see that happen to Parallax, since they've put so much energy and capital into Blockly.
-Phil
On the topic of Large Corporations Pulling the Plug, this recent news is also topical :
Seems all that market-speak and PR spin, can have a short half-life !
Some of the comments are interesting. Intel seems to have lost the skill of talking to Embedded Designers, which is a shame as they were one of the Embedded leaders once.
I'm not sure if this is good, or bad, news for Parallax & P2.
One cynic posts no one will notice intel's move, but it could make designers more risk averse, and it could drive them away from the unusual end of the spectrum.
Those effects are one reason I favour Parallax crowd-funding a FPGA module, that can seed P1V & P2, long before P2 silicon ships.
It is kind of funny what people think Parallax should do.
@jmg thinks they should crowd found a FPGA - if it is a valid business idea, why does he not do it himself?
@microcontrolleruser thinks they should build a tool chain and documentation for PIC chips - if it is a valid business idea, why does he not do it himself?
@clusso99 wants them to produce a P1+, delaying the P2 - if he would shoulder the $100K-$200K Parallax might do that.
I would have some other ideas Parallax could do, as long as they do not spend my money on it.
@jmg thinks they should crowd found a FPGA - if it is a valid business idea, why does he not do it himself?
Not just me ( so no WOW needed at all ) - Ken has said they are open to the idea of crowd funding.
Sounds ok to me, and my feeling is they need something tangible they can deliver as milestones, hence FPGA is logical.
As time marches on, FPGA gets more viable to offer.
It is kind of funny what people think Parallax should do.
@jmg thinks they should crowd found a FPGA - if it is a valid business idea, why does he not do it himself?
@microcontrolleruser thinks they should build a tool chain and documentation for PIC chips - if it is a valid business idea, why does he not do it himself?
@clusso99 wants them to produce a P1+, delaying the P2 - if he would shoulder the $100K-$200K Parallax might do that.
I would have some other ideas Parallax could do, as long as they do not spend my money on it.
simply WOW.
Mike
1. I have been advocating a P1+/P1B for a quite a few years now. Could have paid for itself by now, with almost no interference to the P2 delivery schedule.
2. In fact, we did have someone willing to invest the money for a P1+ but he was assured (more than once) that the P2 was just around the corner, so to hang on. It didn't happen and still hasn't.
3. You really should carefully read my posts. I have given reasons why I think it would be viable for Parallax. However, in the end, they are only suggestions.
4. And while we are at it, hindsight is wonderful. Should have built the P2HOT !!!
1. I have been advocating a P1+/P1B for a quite a few years now. Could have paid for itself by now, with almost no interference to the P2 delivery schedule.
2. In fact, we did have someone willing to invest the money for a P1+ but he was assured (more than once) that the P2 was just around the corner, so to hang on. It didn't happen and still hasn't.
Yes, meanwhile, the passage of time has actually made P1+ on FPGA, more viable. See the tables in this thread
See my link above, and look at FLiP, and it is not hard to imagine how such a P1+ module could exist.
At some point it might be cheaper to not produce the P2 at all, just burn some FPGAs and sell them.
weird,
That point for P2 is quite some time away yet, but the P1 cross-over point is rather closer.
Even today, it is as much a packaging question, as a price one.
My only concern with Blockly is that Parallax is trusting Google to continue supporting it
I also worry about closed source proprietary systems.
But in the case of Blockly, whatever it is seems to be open source. It generates C code, presumably compiled with the Free Software GCC. The compilation is done in, so we are told, Amazon cloud servers. Not Googles.
Did you made any changes at the pad frame layout, specially into the fuses area, and perhaps also had a chance to think about the possibility of having an I/O capability at the Reset signal?
Henrique
A bunch of resistors were resized to become their proper values. They all got shortened.
I've asked OnSemi for more fuse info, but not much has come back. So, the fuses remain the same. They are supposed to be blown at 5V,, I just learned, but we are set up for 3.3V. I had one stubborn fuse in the last test batch. Worst case, we must build a special programmer to briefly drive higher voltage into the VIO of the 4-pin bank whose 16 fuses are being blown. That sounds crazy, I know, but how else to get 5V at 35mA? We could come up with a programmable power supply circuit for common board use that normally outputs 3.3V, but can jump up briefly to 5V for the fuse blow. That would need one I/O pin and be under software control. The blow time is under 1ms.
I have not thought about making the RESn pin an I/O.
All the padframe layout changes are done and we are waiting for a shuttle.
I have not thought about making the RESn pin an I/O.
There are already the natural 64 io, so where would this map ?
Some vendors use RESn as a Debug connection, with a width filter. eg < 10us can be data, and > 20us is a genuine reset.
Those that do allow RESn as IO, often have a fuse to select that, to avoid unexpected RESn / IO interactions.
This makes more sense on the smallest, 20 pins and less parts, where an extra IO pin is a reasonable % gain.
I've asked OnSemi for more fuse info, but not much has come back. So, the fuses remain the same. They are supposed to be blown at 5V,, I just learned, but we are set up for 3.3V. I had one stubborn fuse in the last test batch. Worst case, we must build a special programmer to briefly drive higher voltage into the VIO of the 4-pin bank whose 16 fuses are being blown. That sounds crazy, I know, but how else to get 5V at 35mA? We could come up with a programmable power supply circuit for common board use that normally outputs 3.3V, but can jump up briefly to 5V for the fuse blow. That would need one I/O pin and be under software control. The blow time is under 1ms.
Ugh. That's sounding increasingly messy Can you not get at least an OTP block, or ideally MTP, (proven, no additional metal, or additional Vpp) from OnSemi ?
Just looking at the newest NXP LPC84x data, (June 2017) they mention
Fast Initialization Memory (FAIM) 128/256 bits allowing the user to configure chip behavior on power-up.
I think this really means what others call fuses, & sets these items
• Clocks and PMU for low-power start-up.
• Low power boot at 1.5 MHz using FAIM memory.
• Pin configuration including direction and pull- up or pull-down.
• Specification of pins to use for ISP entry for each serial peripheral.
• Select whether SWCLK and SWDIO are enabled on reset
they also say this
"The FAIM is a multiple time programmable (MTP), ultra low power memory, the full contents of which are read and latched immediately after reset, with no clocks required."
"The FAIM contents provide a user-programmable initial configuration for aspects of the microcontroller, which take effect immediately after reset, before code begins to run. For
instance, the standard I/O pads normally come out of reset with the internal pull-ups enabled. In some systems this may cause excess current to flow, until software can
reconfigure the pads. However, by programming the FAIM appropriately, every pad's reset configuration can be customized. Other aspects which can be controlled by the FAIM are
initial FRO divider value (low power start), serial wire debug disable, default ISP interface and pins, etc. One 32-bit FAIM row can be programmed, or read, using the ROM IAP calls
FAIMWrite and FAIMRead"
&
"The FAIM (MTP) is limited to 200 program cycles, so care must be taken to write this memory only when necessary during an end-product's development. Also, the FAIM programming voltage range is 3.0 V < Vdd < 3.6 V."
I think maybe they mean 'read and applied during reset', as this type of early-read fuse is best applied really early.
It sounds like every unique pad can be set initial this way, which is something new.
I've see Atmel parts where fuses config by port, but not down to the bit-level. A nice idea.
They can boot from one fuse choice of USART0, I2C0, SPI0, mapped to almost any pins. ie similar to P2 boot, but they add i2c.
It must start with some factory default, before you re-configure final boot choices.
Comments
It's not just the one language that makes sense. With Blockly, kids can get started without programming knowledge. When they outgrow it, they have a base to look at what their code produced, and then cango further if they desire. The hardest part is getting the kids interested. They have so many different things they can do, so they need something interesting orthey move on.
I love the capability of prop1 to display video but I don't think its should be on chip.(ye game developers would love it though but its past, or just keep single core with pal/ntsc video generator)
also if you checkout the vive lighthouse or VR controllers I think parallax props will be great at doing all stuff fast & parallel.
There are plenty of drag-and-drop 'languages' that run on single-core processors. And plenty of those are in the sub 1$ price range.
Educators would appreciate the sub-$1 domain with Blockly support, but there's much more to it than that. If that was the only filter a supplier had to pass we'd be out of business. There requirements are more like this:
(x) Tutorials, Assessment material and standards alignment (educators have access to the latter two pieces)
(x) Professional Development (we offer about 15 courses/year)
(x) Robotics kits, under $200 (we are the leader here)
(x) Ready to go hardware, sensor kits
(x) Chromebook support (announced today)
(x) code.org relevancy (uses Blockly)
(x) Warranty, quality product with support (yes, as you know)
Our Blockly has multicore support with a "new processor" block.
As engineers and skilled programmers, it can be difficult to shift mindset to that of an educator. They don't program and build circuits for a career; this is all new to them. They need a reliable system, backed by people who can help them, along with a mix of the right technology and tutorials.
We welcome you on board with our vision!
Ken Gracey
Did Blockly originate from 12 blocks? He developed a nice system, but our customers wouldn't adopt a licensed, closed software in mass. While Hanno was certainly early to this kind of visual programming, it goes way back before Google. Watch my webinar for some details just how far back it goes:
I had to talk about a virtual robot product in that webinar as they sponsored the effort, but the early 15 minutes provide some historical review taking you back the early 70s.
Now you know.
I like the C code view of that.
Do you mean variable sharing? All vars are global. You're a programmer and I'm a bit of a hack; rephrase your question please.
One example of cross-cog communication, would be to have the " red LED " function, ramp the greenLED var, within a defined range.
General comments:
Blocky seems to tolerate white spaces in function names, and the quotes suggest there may be leading and trailing spaces too ?
That's probably not the best idea for moving to any other language ?
I had previously written the program in C and wanted to see how it translated to blockly.
It was interesting to build the program from my original logic notes without having to keep track of braces or semicolons. The biggest issue was how quickly the screen filled up when having to use a large number of nested if-else if blocks all of the remote control options I had. Since I wrote that program, Parallax has added arrays and case blocks which would have help condense the number of blocks.
Tom
That isn't the Google way though, is it?
I developed some great apps for my robotics class that relied upon the Google Earth API. Well, guess what? They deprecated it without a viable alternative, and all the work I did is now for naught.
I'd really hate to see that happen to Parallax, since they've put so much energy and capital into Blockly.
-Phil
As far as I know, Blockly doesn't need google servers and is open source. So Google can't kill BlocklyProp, because parallax runs the servers and maintains the code.
Google can stop updating the source, or supporting Blockly itself, but that won't kill it.
On the topic of Large Corporations Pulling the Plug, this recent news is also topical :
http://hackaday.com/2017/06/19/intel-discontinues-joule-galileo-and-edison-product-lines/
Seems all that market-speak and PR spin, can have a short half-life !
Some of the comments are interesting. Intel seems to have lost the skill of talking to Embedded Designers, which is a shame as they were one of the Embedded leaders once.
I'm not sure if this is good, or bad, news for Parallax & P2.
One cynic posts no one will notice intel's move, but it could make designers more risk averse, and it could drive them away from the unusual end of the spectrum.
Those effects are one reason I favour Parallax crowd-funding a FPGA module, that can seed P1V & P2, long before P2 silicon ships.
@jmg thinks they should crowd found a FPGA - if it is a valid business idea, why does he not do it himself?
@microcontrolleruser thinks they should build a tool chain and documentation for PIC chips - if it is a valid business idea, why does he not do it himself?
@clusso99 wants them to produce a P1+, delaying the P2 - if he would shoulder the $100K-$200K Parallax might do that.
I would have some other ideas Parallax could do, as long as they do not spend my money on it.
simply WOW.
Mike
Not just me ( so no WOW needed at all ) - Ken has said they are open to the idea of crowd funding.
Sounds ok to me, and my feeling is they need something tangible they can deliver as milestones, hence FPGA is logical.
As time marches on, FPGA gets more viable to offer.
In another thread I've already linked to a real example of MCU on FPGA modules
2. In fact, we did have someone willing to invest the money for a P1+ but he was assured (more than once) that the P2 was just around the corner, so to hang on. It didn't happen and still hasn't.
3. You really should carefully read my posts. I have given reasons why I think it would be viable for Parallax. However, in the end, they are only suggestions.
4. And while we are at it, hindsight is wonderful. Should have built the P2HOT !!!
At some point it might be cheaper to not produce the P2 at all, just burn some FPGAs and sell them.
weird,
Mike
See my link above, and look at FLiP, and it is not hard to imagine how such a P1+ module could exist.
Even today, it is as much a packaging question, as a price one.
But in the case of Blockly, whatever it is seems to be open source. It generates C code, presumably compiled with the Free Software GCC. The compilation is done in, so we are told, Amazon cloud servers. Not Googles.
No worries about trusting Google there.
A bunch of resistors were resized to become their proper values. They all got shortened.
I've asked OnSemi for more fuse info, but not much has come back. So, the fuses remain the same. They are supposed to be blown at 5V,, I just learned, but we are set up for 3.3V. I had one stubborn fuse in the last test batch. Worst case, we must build a special programmer to briefly drive higher voltage into the VIO of the 4-pin bank whose 16 fuses are being blown. That sounds crazy, I know, but how else to get 5V at 35mA? We could come up with a programmable power supply circuit for common board use that normally outputs 3.3V, but can jump up briefly to 5V for the fuse blow. That would need one I/O pin and be under software control. The blow time is under 1ms.
I have not thought about making the RESn pin an I/O.
All the padframe layout changes are done and we are waiting for a shuttle.
Some vendors use RESn as a Debug connection, with a width filter. eg < 10us can be data, and > 20us is a genuine reset.
Those that do allow RESn as IO, often have a fuse to select that, to avoid unexpected RESn / IO interactions.
This makes more sense on the smallest, 20 pins and less parts, where an extra IO pin is a reasonable % gain.
Ugh. That's sounding increasingly messy
Just looking at the newest NXP LPC84x data, (June 2017) they mention
Fast Initialization Memory (FAIM) 128/256 bits allowing the user to configure chip behavior on power-up.
I think this really means what others call fuses, & sets these items
• Clocks and PMU for low-power start-up.
• Low power boot at 1.5 MHz using FAIM memory.
• Pin configuration including direction and pull- up or pull-down.
• Specification of pins to use for ISP entry for each serial peripheral.
• Select whether SWCLK and SWDIO are enabled on reset
they also say this
"The FAIM is a multiple time programmable (MTP), ultra low power memory, the full contents of which are read and latched immediately after reset, with no clocks required."
"The FAIM contents provide a user-programmable initial configuration for aspects of the microcontroller, which take effect immediately after reset, before code begins to run. For
instance, the standard I/O pads normally come out of reset with the internal pull-ups enabled. In some systems this may cause excess current to flow, until software can
reconfigure the pads. However, by programming the FAIM appropriately, every pad's reset configuration can be customized. Other aspects which can be controlled by the FAIM are
initial FRO divider value (low power start), serial wire debug disable, default ISP interface and pins, etc. One 32-bit FAIM row can be programmed, or read, using the ROM IAP calls
FAIMWrite and FAIMRead"
&
"The FAIM (MTP) is limited to 200 program cycles, so care must be taken to write this memory only when necessary during an end-product's development. Also, the FAIM programming voltage range is 3.0 V < Vdd < 3.6 V."
I think maybe they mean 'read and applied during reset', as this type of early-read fuse is best applied really early.
It sounds like every unique pad can be set initial this way, which is something new.
I've see Atmel parts where fuses config by port, but not down to the bit-level. A nice idea.
They can boot from one fuse choice of USART0, I2C0, SPI0, mapped to almost any pins. ie similar to P2 boot, but they add i2c.
It must start with some factory default, before you re-configure final boot choices.
Good. Keep on not thinking about it.