A bunch of resistors were resized to become their proper values. They all got shortened.
...
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.
Hi Chip
Thanks for answering my post.
More on the fuses's subject, later...
@Chip, @jmg et. al.
In the subject of making the Reset pin an I/O, sorry by not being as clear as I needed to be, due to differing mother's language barriers, but I didn't intended for Reset to be a part of the 64 bit I/O block.
I've been thinking in something closer to JMG's latter post, perhaps with the addition of a new instruction that could control the setup of two variables; one to set the minimum External Reset pulse width that is to be allowed to pass in, before it can be even sensed as a valid one, thus effectivelly reseting the P2, and the other, controlling how long will last the internally generated Reset pulse, driving the Reset pin, to properly initialize any externally connected devices.
The same instruction, with perhaps zero as the minimum acceptable External Reset pulse lenght, can fire an internally generated Reset pulse, whose lenght will be controlled by the second field.
And finally, by defining a non-zero value for the minimum acceptable external reset pulse, and simultaneously, a zero lenght for the internally generated one, could be used to "mute" the output capability of the Reset pin, letting it with almost the same functions as it initialy has been designed.
Standard values for those two internally registered variables should be programmed as part of the Power On Reset procedures, thus defining the first internally generated Reset pulse period, if any, and enabling the P2 to be the solelly one to drive any board or system Reset line, during and perhaps just after each power cycle.
This way, by inspecting the lenght of the first internally generated Reset pulse, available at the Reset pin during and shortly after (register-contents defined) each power cycle, one can be assured that P2 has completed its internal reset procedures.
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.
None crazy sounding, yet...
In fact, perhaps we are closer to have some nice wookey frying pans, to blow fuses, inside...
I believe you've talked about each fuse's blowing circuit having a large PMOS device to deal with the needed (and now known to be 5V @ 35mA, lasting under 1mS) power.
If ONC18: G/MS is the target proccess and accordingly to the following OnSemi document, page 3, they can have 3.3V Gate / 15V Drain PLDMOS with Rsp = 34.5 mOHMs*mm2 devices.
Such a low on resistance would minimize losses due to the 35mA programming current, preventing much lower than the intended 5V programming voltages to finally hit the target fuse to be blown.
Also, on page 6 of the same document, they show several options for the 3.3V I/O circuits as being 5V tolerant, but with modest current limits of 24 or even 16mA.
Any way, and this should be noted, rated at design dimensions that are well under the ones settled at the current pad frame you have specified, then, IMHO, we are at the safe side area on this subject.
Also at the same document, on page 4, they show the availability of OTP (Sidense Oxide Rupture OTP IP) in two flavours (page 7); 1 kbit and 256 kbit instances!!!
To the extent of my readings, no increased mask count for any of the above, but I can say nothing about the cost of using Sidense IP, if anything will be charged or not.
In the subject of making the Reset pin an I/O, sorry by not being as clear as I needed to be, due to differing mother's language barriers, but I didn't intended for Reset to be a part of the 64 bit I/O block.
I've been thinking in something closer to JMG's latter post, perhaps with the addition of a new instruction that could control the setup of two variables; one to set the minimum External Reset pulse width that is to be allowed to pass in, before it can be even sensed as a valid one, thus effectivelly reseting the P2, and the other, controlling how long will last the internally generated Reset pulse, driving the Reset pin, to properly initialize any externally connected devices.
The same instruction, with perhaps zero as the minimum acceptable External Reset pulse lenght, can fire an internally generated Reset pulse, whose lenght will be controlled by the second field.
And finally, by defining a non-zero value for the minimum acceptable external reset pulse, and simultaneously, a zero lenght for the internally generated one, could be used to "mute" the output capability of the Reset pin, letting it with almost the same functions as it initialy has been designed.
Standard values for those two internally registered variables should be programmed as part of the Power On Reset procedures, thus defining the first internally generated Reset pulse period, if any, and enabling the P2 to be the solelly one to drive any board or system Reset line, during and perhaps just after each power cycle.
This way, by inspecting the lenght of the first internally generated Reset pulse, available at the Reset pin during and shortly after (register-contents defined) each power cycle, one can be assured that P2 has completed its internal reset procedures.
a) the problem, with any register-params around reset, is they are not known at power up, so you cannot do "Standard values for those two internally registered variables should be programmed as part of the Power On Reset procedures"
Instead, some special ROM/Fuse based defaults must be forced, to at least get reset to a working point.
b) I'm still unclear, but I think you are now talking about a BIDIRECTIONAL RESET pin, allowing "one can be assured that P2 has completed its internal reset procedures"
Yes, that operation is a more common - some MCUs do have a N_FET on their Reset pin, and this allows them to reset other devices, on a WDOG or SW-reset.
It can also be used to pulse stretch a narrow reset, and you could use it to signal across many P2's that the slowest one is (close to) ready.
This does not need fancy pulse width window registers, just a N_FET.
Making a reset pin Open-Drain is lower risk, than 'trying to make it too clever'.
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
I appreciate the honest concern about our well-being. This particular reliance is not a concern and I don't want people to get the idea that we'll be pulling the rug out from under them because Google decides "Blockly is OVER!". We took a copy of the Google Javascript engine and libraries and we build around it. It's open source license, and it doesn't matter what Google does with the project. In fact, they've already moved on to work with MIT on Scratch Blocks.
Now, a Blockly port lives on our servers and we don't need anything from them, unless they release some new components in Blockly we wish to add to our system. Even without them, we're adding graphing and other neat tools.
If you have concerns about viability of any program's hardware, software, company or vision, I could give you a long list that are of higher priority (component obsolescence is a big one, for starters!).
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 ?
Sure, an improvement could be made in this regard with some "Blockly syntax rules".
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.
I recently watched a KickStarter "town home" kinda meeting with a bunch of KickStarter(ers). Anyway, I got the impression that the completeness of a product taken to KickStarter varies with the kind of technology or progress under consideration. I just backed an Arduino circuit book that's being written. And what state was Parallela in? We'd have to meet with them before we took this concept too far, of course.
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 ?
Sure, an improvement could be made in this regard with some "Blockly syntax rules".
Sounds worthwhile.
One detail that helps in any language tool chain, is being able to search/find the outermost source labels, in the mid-level files, be they reports,MAP files, List Files, or intermediate generated source files.
It's not a concern and I don't want people to get the idea that we'll be pulling the rug out from under them. We took a copy of the Google Javascript engine and libraries and we build around it. It's open source license, and it doesn't matter what Google does with the project. Now it lives on our servers and we don't need anything from them, unless they release some new components in Blockly we wish to add to our system.
Ken, it's good to know that Parallax has total control over Blockly. Given Google's track record, I'm sure that was a priority, but I just wanted to make sure.
BTW, I'm not sure how you extrapolated from Google pulling the rug out from under you to Parallax doing that to their customers. You and your customers would both have been the victims in such a scenario, and Parallax would have been blameless. Thankfully, neither will come to pass.
a) the problem, with any register-params around reset, is they are not known at power up, so you cannot do "Standard values for those two internally registered variables should be programmed as part of the Power On Reset procedures"
Instead, some special ROM/Fuse based defaults must be forced, to at least get reset to a working point.
b) I'm still unclear, but I think you are now talking about a BIDIRECTIONAL RESET pin, allowing "one can be assured that P2 has completed its internal reset procedures"
Yes, that operation is a more common - some MCUs do have a N_FET on their Reset pin, and this allows them to reset other devices, on a WDOG or SW-reset.
It can also be used to pulse stretch a narrow reset, and you could use it to signal across many P2's that the slowest one is (close to) ready.
This does not need fancy pulse width window registers, just a N_FET.
Making a reset pin Open-Drain is lower risk, than 'trying to make it too clever'.
Thanks to you by clarifying this subject. I was wrong, because I've understood that a procedure very similar to the one adopted making the boot process accessible just after the reset period, could be used to pre-load the reset pin behavior control registers I've imagined, during the power-on reset cycle.
This could provide some means to extend its duration (valid reset pulse), to ensure every connected device can timely complete its internal reset procedures.
And yes, you are right again; in my mind (interpretation), an I/O pin and a bidiretional pin are the same thing. Now I know that this is not the right interpretation of their behavior.
This also clarifies my view of P2 pins; internally, they are bidiretional in nature. Externally, their behavior depends on many factors, including any override provided by programming then into any smart mode that controls the output state.
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.
I recently watched a KickStarter "town home" kinda meeting with a bunch of KickStarter(ers). Anyway, I got the impression that the completeness of a product taken to KickStarter varies with the kind of technology or progress under consideration. I just backed an Arduino circuit book that's being written. And what state was Parallela in? We'd have to meet with them before we took this concept too far, of course.
Ken Gracey
Parallella still seems to be around. You can buy a board from them with their chip on it for $99.
This could provide some means to extend its duration (valid reset pulse), to ensure every connected device can timely complete its internal reset procedures.
If that is the purpose, the Open Drain reset pin allows that, and more (eg SW & WDOG can do a system wide reset).
Problem is, I don't think Chip has allowed for an Open Drain Reset Pin so such 'system usefulness' discussions are moot.
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.
I recently watched a KickStarter "town home" kinda meeting with a bunch of KickStarter(ers). Anyway, I got the impression that the completeness of a product taken to KickStarter varies with the kind of technology or progress under consideration. I just backed an Arduino circuit book that's being written. And what state was Parallela in? We'd have to meet with them before we took this concept too far, of course.
Yes, my point was really to make final P2 silicon a stretch goal, there are other more practical milestones that can be delivered via a module, that can keep interest levels up.
On present FPGA price curves, it looks like a full P1V, and (or) some useful subset of P2, could be done.
Along the way, the whole P2 software eco system is a vital, but less tangible deliverable.
The intel example shows that doing the opposite - as in having silicon, before your software and docs are viable, is not a key to success.
Seriously... after 11 years, they are wondering if they should finish it? If nothing else, to update the original line and compete in the same areas where others have advanced. I, however, noted in my now DELETED post about my dismay over how long this has taken. I was putting off the portable hardware portion of a government tax ID/verification system that is going nation wide... THOUSANDS of chip sales for this.. but with so many delays and the hardware portable portion is all that is left, I had to pull the trigger yesterday and start looking at other options. Love the prop, and I'll play with the prop2 if it comes out before I die...
So to answer your question, I WOULD have 10's of 100's personally...
Seriously... after 11 years, they are wondering if they should finish it? If nothing else, to update the original line and compete in the same areas where others have advanced. I, however, noted in my now DELETED post about my dismay over how long this has taken. I was putting off the portable hardware portion of a government tax ID/verification system that is going nation wide... THOUSANDS of chip sales for this.. but with so many delays and the hardware portable portion is all that is left, I had to pull the trigger yesterday and start looking at other options. Love the prop, and I'll play with the prop2 if it comes out before I die...
So to answer your question, I WOULD have 10's of 100's personally...
I don't know who deleted your post, but I wanted to respond to it.
I'm not sure what to say.
I understand your frustration. You should figure that it sucks to be me, too. There is a mountain of effort into this project that is not yet realized as anything we can sell. The world keeps changing, meanwhile. Even the culture surrounding technology has morphed greatly. I'm doing my best to bring this to completion. And, yes, there's been a ton of tinkering along the way.
Hopefully, this gets done soon and we can all enjoy some benefit from it.
I was putting off the portable hardware portion of a government tax ID/verification system that is going nation wide...
I'm curious. What is it about the requirements for this system that would call for the real-time capabilities of the P2 ? Why has it's development been waiting for the P2 when there are millions of devices out there for ages now that could do it?
Please do not let the bull get to you, especially to the point of explaining your grief to an inactive member. It is very difficult to design and develop stuff, especially when you have a specific vision for your creation, but the funds are limited.
Just keep your nose to the grindstone, and if that wears down to nothing, then choose an ear
Seriously, I look forward to seeing the efforts of your labor, as well as all the support from the forum that has gone into this chip. As they say, you cannot rush success. Just have a well established plan ready for distribution, once the chip actually goes into production.
I don't know why Blocky needs the P2, wouldn't the money be better spent on software tools?
I don't see a large market for the P2, it is just too slow to bit bang most of the modern serial/semi parallel interfaces and it is too power hungry for battery operations. Can you really make it with a handful of 1K/year customers? Maybe when you get to the P5, it might be fast enough to be competitive.
But how do you afford the mask charges for a 40-60 nm process? I would suggest going with MOSIS multi-project die to build a small number of modern chips. If it really would be a player, better to have some samples for potential large customers and seed the forum base with parts to do demos. Yes you would have to abandon the analog, or do a big redesign (analog does not scale like digital). Other than that the P2 won't expand the current Propeller market much.
Lots of things. Props make really good learning platforms there's a number of reasons for this how the cogs work being able to bit bang clean Assembly Language in the P2 they'll be lots of spiffy functions on the chip...
I don't see a large market for the P2, it is just too slow to bit bang most of the modern serial/semi parallel interfaces ...
Almost any chip is too slow to bit bang most of the modern serial/semi parallel interfaces, so that point means little.
The 'Modern Serial Interfaces' cover a huge dynamic range - newest ones are GBit in speed, and clearly need custom silicon support.
P2 was never going to play in that sand pit anyway.
More important to P2, and the mid-level, highest volume serial interfaces like QuadSPI, HyperBUS and USB.
So far, P2 look to have those reasonably well covered (tho I'm not sure on latest USB-Build-phase?)
Certainly, the streamer design has the bulk transport covered, it may be some pin-level tweaks are needed to get best performance & control.
... and it is too power hungry for battery operations.
That rather depends on the size of the battery...
Quadcopters are battery operated, and they certainly are not 'mA paranoid', but the P2 is not even in the right package to chase the smallest, most portable coin-cell designs.
Chip has been improving the Time to (Re)Start, which is one place P2 system design can do something to expand the market.
What do they really want? More speed, more memory, more ???
Actually @Ken provided that info some years ago. I can't find the post, so just my memory. (not sure about order and completeness).
1. C support.
2. more memory.
3. more pins.
4. analog pins.
5. higher speed (more commercial customers then educational ones)
6. Debug capability
7. native LMM support (for C) - not sure about that, @Bill Henning might remember, it is almost a decade ago.
8. more COGs
that was, as far as I remember, the primary list of stuff needed.
Comments
How wonderfully last century. I don't think I've used a chip that needed a special voltage to program it since the days of the 2764.
Hi Chip
Thanks for answering my post.
More on the fuses's subject, later...
@Chip, @jmg et. al.
In the subject of making the Reset pin an I/O, sorry by not being as clear as I needed to be, due to differing mother's language barriers, but I didn't intended for Reset to be a part of the 64 bit I/O block.
I've been thinking in something closer to JMG's latter post, perhaps with the addition of a new instruction that could control the setup of two variables; one to set the minimum External Reset pulse width that is to be allowed to pass in, before it can be even sensed as a valid one, thus effectivelly reseting the P2, and the other, controlling how long will last the internally generated Reset pulse, driving the Reset pin, to properly initialize any externally connected devices.
The same instruction, with perhaps zero as the minimum acceptable External Reset pulse lenght, can fire an internally generated Reset pulse, whose lenght will be controlled by the second field.
And finally, by defining a non-zero value for the minimum acceptable external reset pulse, and simultaneously, a zero lenght for the internally generated one, could be used to "mute" the output capability of the Reset pin, letting it with almost the same functions as it initialy has been designed.
Standard values for those two internally registered variables should be programmed as part of the Power On Reset procedures, thus defining the first internally generated Reset pulse period, if any, and enabling the P2 to be the solelly one to drive any board or system Reset line, during and perhaps just after each power cycle.
This way, by inspecting the lenght of the first internally generated Reset pulse, available at the Reset pin during and shortly after (register-contents defined) each power cycle, one can be assured that P2 has completed its internal reset procedures.
Henrique
Surely users code could set an IO pin state to achieve that, without requiring this special reset function?
... about fuses.
None crazy sounding, yet...
In fact, perhaps we are closer to have some nice wookey frying pans, to blow fuses, inside...
I believe you've talked about each fuse's blowing circuit having a large PMOS device to deal with the needed (and now known to be 5V @ 35mA, lasting under 1mS) power.
If ONC18: G/MS is the target proccess and accordingly to the following OnSemi document, page 3, they can have 3.3V Gate / 15V Drain PLDMOS with Rsp = 34.5 mOHMs*mm2 devices.
https://onsemi.com/pub/Collateral/ONC18GMS-D.PDF
Such a low on resistance would minimize losses due to the 35mA programming current, preventing much lower than the intended 5V programming voltages to finally hit the target fuse to be blown.
Also, on page 6 of the same document, they show several options for the 3.3V I/O circuits as being 5V tolerant, but with modest current limits of 24 or even 16mA.
Any way, and this should be noted, rated at design dimensions that are well under the ones settled at the current pad frame you have specified, then, IMHO, we are at the safe side area on this subject.
Also at the same document, on page 4, they show the availability of OTP (Sidense Oxide Rupture OTP IP) in two flavours (page 7); 1 kbit and 256 kbit instances!!!
To the extent of my readings, no increased mask count for any of the above, but I can say nothing about the cost of using Sidense IP, if anything will be charged or not.
Hope it helps a bit (or a bunch of fuses).
Henrique
Instead, some special ROM/Fuse based defaults must be forced, to at least get reset to a working point.
b) I'm still unclear, but I think you are now talking about a BIDIRECTIONAL RESET pin, allowing "one can be assured that P2 has completed its internal reset procedures"
Yes, that operation is a more common - some MCUs do have a N_FET on their Reset pin, and this allows them to reset other devices, on a WDOG or SW-reset.
It can also be used to pulse stretch a narrow reset, and you could use it to signal across many P2's that the slowest one is (close to) ready.
This does not need fancy pulse width window registers, just a N_FET.
Making a reset pin Open-Drain is lower risk, than 'trying to make it too clever'.
I appreciate the honest concern about our well-being. This particular reliance is not a concern and I don't want people to get the idea that we'll be pulling the rug out from under them because Google decides "Blockly is OVER!". We took a copy of the Google Javascript engine and libraries and we build around it. It's open source license, and it doesn't matter what Google does with the project. In fact, they've already moved on to work with MIT on Scratch Blocks.
Now, a Blockly port lives on our servers and we don't need anything from them, unless they release some new components in Blockly we wish to add to our system. Even without them, we're adding graphing and other neat tools.
If you have concerns about viability of any program's hardware, software, company or vision, I could give you a long list that are of higher priority (component obsolescence is a big one, for starters!).
Ken Gracey
Sure, an improvement could be made in this regard with some "Blockly syntax rules".
I recently watched a KickStarter "town home" kinda meeting with a bunch of KickStarter(ers). Anyway, I got the impression that the completeness of a product taken to KickStarter varies with the kind of technology or progress under consideration. I just backed an Arduino circuit book that's being written. And what state was Parallela in? We'd have to meet with them before we took this concept too far, of course.
Ken Gracey
Sounds worthwhile.
One detail that helps in any language tool chain, is being able to search/find the outermost source labels, in the mid-level files, be they reports,MAP files, List Files, or intermediate generated source files.
BTW, I'm not sure how you extrapolated from Google pulling the rug out from under you to Parallax doing that to their customers. You and your customers would both have been the victims in such a scenario, and Parallax would have been blameless. Thankfully, neither will come to pass.
-Phil
Thanks to you by clarifying this subject. I was wrong, because I've understood that a procedure very similar to the one adopted making the boot process accessible just after the reset period, could be used to pre-load the reset pin behavior control registers I've imagined, during the power-on reset cycle.
This could provide some means to extend its duration (valid reset pulse), to ensure every connected device can timely complete its internal reset procedures.
And yes, you are right again; in my mind (interpretation), an I/O pin and a bidiretional pin are the same thing. Now I know that this is not the right interpretation of their behavior.
This also clarifies my view of P2 pins; internally, they are bidiretional in nature. Externally, their behavior depends on many factors, including any override provided by programming then into any smart mode that controls the output state.
Henrique
https://www.parallella.org
Problem is, I don't think Chip has allowed for an Open Drain Reset Pin so such 'system usefulness' discussions are moot.
On present FPGA price curves, it looks like a full P1V, and (or) some useful subset of P2, could be done.
Along the way, the whole P2 software eco system is a vital, but less tangible deliverable.
The intel example shows that doing the opposite - as in having silicon, before your software and docs are viable, is not a key to success.
So to answer your question, I WOULD have 10's of 100's personally...
I don't know who deleted your post, but I wanted to respond to it.
I'm not sure what to say.
I understand your frustration. You should figure that it sucks to be me, too. There is a mountain of effort into this project that is not yet realized as anything we can sell. The world keeps changing, meanwhile. Even the culture surrounding technology has morphed greatly. I'm doing my best to bring this to completion. And, yes, there's been a ton of tinkering along the way.
Hopefully, this gets done soon and we can all enjoy some benefit from it.
Please do not let the bull get to you, especially to the point of explaining your grief to an inactive member. It is very difficult to design and develop stuff, especially when you have a specific vision for your creation, but the funds are limited.
Just keep your nose to the grindstone, and if that wears down to nothing, then choose an ear
Seriously, I look forward to seeing the efforts of your labor, as well as all the support from the forum that has gone into this chip. As they say, you cannot rush success. Just have a well established plan ready for distribution, once the chip actually goes into production.
Wishing you and Parallax all the best.
Good one Bruce!
I don't see a large market for the P2, it is just too slow to bit bang most of the modern serial/semi parallel interfaces and it is too power hungry for battery operations. Can you really make it with a handful of 1K/year customers? Maybe when you get to the P5, it might be fast enough to be competitive.
But how do you afford the mask charges for a 40-60 nm process? I would suggest going with MOSIS multi-project die to build a small number of modern chips. If it really would be a player, better to have some samples for potential large customers and seed the forum base with parts to do demos. Yes you would have to abandon the analog, or do a big redesign (analog does not scale like digital). Other than that the P2 won't expand the current Propeller market much.
What do they really want? More speed, more memory, more ???
Almost any chip is too slow to bit bang most of the modern serial/semi parallel interfaces, so that point means little.
The 'Modern Serial Interfaces' cover a huge dynamic range - newest ones are GBit in speed, and clearly need custom silicon support.
P2 was never going to play in that sand pit anyway.
More important to P2, and the mid-level, highest volume serial interfaces like QuadSPI, HyperBUS and USB.
So far, P2 look to have those reasonably well covered (tho I'm not sure on latest USB-Build-phase?)
Certainly, the streamer design has the bulk transport covered, it may be some pin-level tweaks are needed to get best performance & control.
That rather depends on the size of the battery...
Quadcopters are battery operated, and they certainly are not 'mA paranoid', but the P2 is not even in the right package to chase the smallest, most portable coin-cell designs.
Chip has been improving the Time to (Re)Start, which is one place P2 system design can do something to expand the market.
Actually @Ken provided that info some years ago. I can't find the post, so just my memory. (not sure about order and completeness).
1. C support.
2. more memory.
3. more pins.
4. analog pins.
5. higher speed (more commercial customers then educational ones)
6. Debug capability
7. native LMM support (for C) - not sure about that, @Bill Henning might remember, it is almost a decade ago.
8. more COGs
that was, as far as I remember, the primary list of stuff needed.
Enjoy!
Mike
Except full fleshed out C/C++ support. But I will keep nagging there.
Enjoy!
Mike
Faster
More HUB RAM
Security
More I/O
I am sure there was a fifth point. Pretty sure it was not analog.
Basically it was a P1+
Could have been done years ago. Could be done for the next shuttle too and an extremely high chance of success except for the fuses.
P2 will require another pass. Goodbye 2017.
not sure about analog either, but C support and Debug where in there, if I am not senile yet.
@Publison, our God of Archive's, do you maybe can find that post of @Ken about what the customers wanted in 200x?
Enjoy!
Mike