Or, maybe we could have P2 start with all pins in weak pullup mode?
Either would work, with the all pins in weak pullup being most predictable.
It is probably not a good idea to start/reset a MCU to floating pins anyway.
Weak pullups seems common, and if weak enough, they can be pulled down with a resistor for those pins that need to reset low.
eg 6.6k external pulldown, is 500uA drive for Hi, and yet will pull down a 30uA weak-pullup to < 200mV
Pulling either way seems rather presumptive. I think the best policy is to float, and let external resistors pull high or low, where necessary.
Note the space before "PropellerHex" that the auto-baud code needs to determine the baud rate in terms of ~20MHz internal RC clock cycles. Space characters occur frequently in hex mode to keep the baud accurate.
I also made a base64 load command, where each non-white-space character provides 6 bits of binary data:
White space, including space, tab, cr, and lf, can be used to break up the hex or base64 data. It would be good to begin each base64 data line with a space for frequent baud recalibration.
At 115.2k baud, the base64 mode loads over 8.5KB per second, while the hex mode loads only ~3.8KB per second.
Personally I wouldn't be concerned with anything other than hex mode because we can load a simple binary loader that can then switch to xtal mode and go much faster.
Personally I wouldn't be concerned with anything other than hex mode because we can load a simple binary loader that can then switch to xtal mode and go much faster.
I was thinking about smaller file sizes for the simplest of loaders. Just transmit the data. The Prop2 returns "PASS" or "FAIL", in case the sender wants to know if it worked.
Pulling either way seems rather presumptive. I think the best policy is to float, and let external resistors pull high or low, where necessary.
That's a lot of resistors (64) now needed to have definable low power state during reset ?
Floating pins is not desirable, on CMOS parts, as the power peaks of the buffers can be significant.
Some MCUs have light pullups, and some Logic parts use a Pin-Keep approach, which has no added current when pulled either way, but does need a certain over-drive current to flip the pin.
Pulling either way seems rather presumptive. I think the best policy is to float, and let external resistors pull high or low, where necessary.
That's a lot of resistors (64) now needed to have definable low power state during reset ?
Floating pins is not desirable, on CMOS parts, as the power peaks of the buffers can be significant.
Some MCUs have light pullups, and some Logic parts use a Pin-Keep approach, which has no added current when pulled either way, but does need a certain over-drive current to flip the pin.
I see what you are saying, but this is no low-power part. It's quiescent draw is going to be 1-2mA, just due to leakage in the 1.8V circuitry.
Pulling either way seems rather presumptive. I think the best policy is to float, and let external resistors pull high or low, where necessary.
+1.
Where it matters, I put the components that ensure a safe state near the destination anyway. being able to assume virtual isolation at startup or unexpected restart can simplify that.
Is there some way to reinvoke the loader once one program is sent and executed? Or does the loader get hidden once the program is executed?
This would allow concatenation of a sequence of independent commands, eg if you wanted to set one pin doing one thing and another pin doing something else.
If you can't do that, how big is the loader code approximately?
Very weak pull-ups are better than floating pins which can end up floating to the switch's linear region and drawing excess current or ringing. Values in excess of 100k are fine, they are still very low resistance compared to the ultra-high CMOS input resistance.
So Chip, any chance of a new binary with a boot ROM anytime soon? I could really use it like yesterday. Turns out too that I will probably have to upgrade all the P1s to P2s in my new project once it goes to production because of security issues. That's over forty P2s per unit! But if P2 isn't available then that means I have no other choice but to use something else, as repugnant as that would be.
btw, I sense line breaks as a way of resetting the Prop so it would be nice if this feature was always active as it makes it possible to gain control to the bootloader if necessary.
.
.
.
So Chip, any chance of a new binary with a boot ROM anytime soon? I could really use it like yesterday. Turns out too that I will probably have to upgrade all the P1s to P2s in my new project once it goes to production because of security issues. That's over forty P2s per unit! But if P2 isn't available then that means I have no other choice but to use something else, as repugnant as that would be.
btw, I sense line breaks as a way of resetting the Prop so it would be nice if this feature was always active as it makes it possible to gain control to the bootloader if necessary.
I sense the P2 design is finally frozen and now comes the last 10%, verification, tools, "pre-press" for the foundery. It would be tragic to see your project have to migrate to another micro after all the work producing Tachyon for the propeller chips. Although I'm sure you can retarget the Tachyon Byte Code VM at will. But tragic for me in that I use Tachyon as a gateway/learning tool between propeller hardware and PASM. Not to mention ease of development for me. My only problem is my bloated Tachyon code that I tend to run out of memory. P2 frees me of this issue!!!! But I just refactored 100 Longs out of my current project so it's getting easier.
Turns out too that I will probably have to upgrade all the P1s to P2s in my new project once it goes to production because of security issues.
Can you not use something else for security, in the interim ?
eg the EFM8BB1, or I see a Nuvoton N79E715AS16 (SO16N) is just 30c/500+, with a bootloader and 16k of Flash.
That could be used as a sort of secure co-processor / intelligent memory / secure ADC etc ?
I see EFM8BB1 has 32b unique ID, larger EFM8BB3 has 128b unique ID, and alternate N76E885 has 96b UID.
btw, I sense line breaks as a way of resetting the Prop so it would be nice if this feature was always active as it makes it possible to gain control to the bootloader if necessary.
How does this interact with an Auto-Baud scheme ?
ie how can it know when a break is sent ?
Turns out too that I will probably have to upgrade all the P1s to P2s in my new project once it goes to production because of security issues.
Can you not use something else for security, in the interim ?
eg the EFM8BB1, or I see a Nuvoton N79E715AS16 (SO16N) is just 30c/500+, with a bootloader and 16k of Flash.
That could be used as a sort of secure co-processor / intelligent memory / secure ADC etc ?
I see EFM8BB1 has 32b unique ID, larger EFM8BB3 has 128b unique ID, and alternate N76E885 has 96b UID.
btw, I sense line breaks as a way of resetting the Prop so it would be nice if this feature was always active as it makes it possible to gain control to the bootloader if necessary.
How does this interact with an Auto-Baud scheme ?
ie how can it know when a break is sent ?
Once the big bucks have been spent on UL certification I am then stuck with whatever chip I've designed in. It is far easier to develop with the Prop and Tachyon at present and once it is fully tested I have the option of migrating to another chip if P2 isn't available by then. Mind you, it looks like that is the way I will probably have to go sad to say.
A break is always way longer than any character at any practical baud rate. Say if a break were 100ms long then even at a ridiculous 300 baud that would be detected. A break always gets past any baud rate issues and is easily detected. In fact I just accept 100 framing errors in a row which is usually a break (I'd have to reduce that to 3 or so for 300 baud which would never be the case).
BTW, I do use about 84 of the little PIC12F1572s for A/D etc. The cost of the P2s vs cheaper options should never be an issue but even if it were I could easily dismiss it by bringing up the continuity of supply issue, these itty-bittys go out of production within such a short time but Parallax has proven itself as a supplier one can count on for long-term supply and support.
Once the big bucks have been spent on UL certification I am then stuck with whatever chip I've designed in. It is far easier to develop with the Prop and Tachyon at present and once it is fully tested I have the option of migrating to another chip if P2 isn't available by then. Mind you, it looks like that is the way I will probably have to go sad to say.
Yes, hence my suggestion of adding a helper device that avoids that second step.
If the issue is security, then add just enough to satisfy that, and still develop in Tachyon.
Very weak pull-ups are better than floating pins which can end up floating to the switch's linear region and drawing excess current or ringing. Values in excess of 100k are fine, they are still very low resistance compared to the ultra-high CMOS input resistance.
So Chip, any chance of a new binary with a boot ROM anytime soon? I could really use it like yesterday. Turns out too that I will probably have to upgrade all the P1s to P2s in my new project once it goes to production because of security issues. That's over forty P2s per unit! But if P2 isn't available then that means I have no other choice but to use something else, as repugnant as that would be.
btw, I sense line breaks as a way of resetting the Prop so it would be nice if this feature was always active as it makes it possible to gain control to the bootloader if necessary.
It would be unfortunate if you had to go to another MCU. Would you port Tachyon to the new processor or use some other Forth? I assume you wouldn't recode everything in C.
Once the big bucks have been spent on UL certification I am then stuck with whatever chip I've designed in. It is far easier to develop with the Prop and Tachyon at present and once it is fully tested I have the option of migrating to another chip if P2 isn't available by then. Mind you, it looks like that is the way I will probably have to go sad to say.
Yes, hence my suggestion of adding a helper device that avoids that second step.
If the issue is security, then add just enough to satisfy that, and still develop in Tachyon.
A helper device doesn't need to be hacked, its function is fairly easily discerned and implemented, the P1 with the important code in EEPROM would still be exposed unless you have a grand idea in that regard. Even with just a loader in EEPROM I could load an encrypted binary off the microSD card with the secure master P2 issuing keys to devices as each node's binary is encrypted with a different key based on the node address perhaps. But either way, the master needs to be a secure micro.
A helper device doesn't need to be hacked, its function is fairly easily discerned and implemented, ...
That same line can be used with the whole product.
If someone has that level of skills, & funding, you are not going to stop an equivalent product creation.
So it comes down to what it is exactly that you hope to secure against ?
Is it night shift production creepage ? or external hacking/attack ? or ?
BTW, I do use about 84 of the little PIC12F1572s for A/D etc. The cost of the P2s vs cheaper options should never be an issue but even if it were I could easily dismiss it by bringing up the continuity of supply issue, these itty-bittys go out of production within such a short time but Parallax has proven itself as a supplier one can count on for long-term supply and support.
Microchip keeps devices in production indefinitely.
BTW, I do use about 84 of the little PIC12F1572s for A/D etc. The cost of the P2s vs cheaper options should never be an issue but even if it were I could easily dismiss it by bringing up the continuity of supply issue, these itty-bittys go out of production within such a short time but Parallax has proven itself as a supplier one can count on for long-term supply and support.
Microchip keeps devices in production indefinitely.
Yep. We use their oldest chips in our BASIC Stamps. We are still selling them after 23 years.
BTW, I do use about 84 of the little PIC12F1572s for A/D etc. The cost of the P2s vs cheaper options should never be an issue but even if it were I could easily dismiss it by bringing up the continuity of supply issue, these itty-bittys go out of production within such a short time but Parallax has proven itself as a supplier one can count on for long-term supply and support.
Microchip keeps devices in production indefinitely.
Yep. We use their oldest chips in our BASIC Stamps. We are still selling them after 23 years.
Have you ever considered moving up to one of their newer chips? I would think you could get rid of the external EEPROM if you used a chip with a larger on-chip flash.
BTW, I do use about 84 of the little PIC12F1572s for A/D etc. The cost of the P2s vs cheaper options should never be an issue but even if it were I could easily dismiss it by bringing up the continuity of supply issue, these itty-bittys go out of production within such a short time but Parallax has proven itself as a supplier one can count on for long-term supply and support.
Microchip keeps devices in production indefinitely.
Yep. We use their oldest chips in our BASIC Stamps. We are still selling them after 23 years.
Have you ever considered moving up to one of their newer chips? I would think you could get rid of the external EEPROM if you used a chip with a larger on-chip flash.
That BASIC Stamp code is wound up tighter than a ten-cent watch. Better to leave it alone.
BTW, I do use about 84 of the little PIC12F1572s for A/D etc. The cost of the P2s vs cheaper options should never be an issue but even if it were I could easily dismiss it by bringing up the continuity of supply issue, these itty-bittys go out of production within such a short time but Parallax has proven itself as a supplier one can count on for long-term supply and support.
Microchip keeps devices in production indefinitely.
Yep. We use their oldest chips in our BASIC Stamps. We are still selling them after 23 years.
Have you ever considered moving up to one of their newer chips? I would think you could get rid of the external EEPROM if you used a chip with a larger on-chip flash.
That BASIC Stamp code is wound up tighter than a ten-cent watch. Better to leave it alone.
BTW, I do use about 84 of the little PIC12F1572s for A/D etc. The cost of the P2s vs cheaper options should never be an issue but even if it were I could easily dismiss it by bringing up the continuity of supply issue, these itty-bittys go out of production within such a short time but Parallax has proven itself as a supplier one can count on for long-term supply and support.
Microchip keeps devices in production indefinitely.
Yep. We use their oldest chips in our BASIC Stamps. We are still selling them after 23 years.
Have you ever considered moving up to one of their newer chips? I would think you could get rid of the external EEPROM if you used a chip with a larger on-chip flash.
That BASIC Stamp code is wound up tighter than a ten-cent watch. Better to leave it alone.
Have you ever considered moving up to one of their newer chips? I would think you could get rid of the external EEPROM if you used a chip with a larger on-chip flash.
Certainly, overdue for a simple make-over.
A quick search for cheapest MCU with USB, gives EFM8UB1 64c/1k, (bootloader included)
Cheapest 32k device is EFM8UB20 ~ $1.16, 64k+ gives either EFM8UB20F64, or STM32F070 at 128k for ~ $1.30
However, many of those are not 5V Drive, or 5V ADC, which is probably an issue....
5V ?
Cypress have a part that is 5V Drive and 5V ADC with 160KBF 16KR 2.7 V ~ 5.5 V A/D 8x12b ~$1.71
Nuvoton have M4 5V parts 40k M452LC3AE $1.52/1k, to $1.89/1k for 128KF, 32KR,
or new M4TK adds touch keys... (showing $2.23 for 256k,100pins)
or, you could look at the new wireless MCUs, but a Stamp still needs power, so 5V-USB is simplest .....
Have you ever considered moving up to one of their newer chips? I would think you could get rid of the external EEPROM if you used a chip with a larger on-chip flash.
Certainly, overdue for a simple make-over.
A quick search for cheapest MCU with USB, gives EFM8UB1 64c/1k, (bootloader included)
Cheapest 32k device is EFM8UB20 ~ $1.16, 64k+ gives either EFM8UB20F64, or STM32F070 at 128k for ~ $1.30
However, many of those are not 5V Drive, or 5V ADC, which is probably an issue....
5V ?
Cypress have a part that is 5V Drive and 5V ADC with 160KBF 16KR 2.7 V ~ 5.5 V A/D 8x12b ~$1.71
Nuvoton have M4 5V parts 40k M452LC3AE $1.52/1k, to $1.89/1k for 128KF, 32KR,
or new M4TK adds touch keys... (showing $2.23 for 256k,100pins)
or, you could look at the new wireless MCUs, but a Stamp still needs power, so 5V-USB is simplest .....
It would certainly be fun to work on an update to the BASIC Stamp.
That BASIC Stamp code is wound up tighter than a ten-cent watch. Better to leave it alone.
Well, yes, that's true of the host it was optimized to run in, however modern MCUs are not nearly as constraining, and you should be able to emulate a Stamp in a 72MHz Cortec M4 for example, without needing any 'code wound up tighter than a ten-cent watch'
That BASIC Stamp code is wound up tighter than a ten-cent watch. Better to leave it alone.
Well, yes, that's true of the host it was optimized to run in, however modern MCUs are not nearly as constraining, and you should be able to emulate a Stamp in a 72MHz Cortec M4 for example, without needing any 'code wound up tighter than a ten-cent watch'
And there is so much flash that we could put a Lisp VM in there along with the PBASIC one! :-)
Comments
Pulling either way seems rather presumptive. I think the best policy is to float, and let external resistors pull high or low, where necessary.
Here is all you need to do load a program (this one flashes the LEDs on the Prop-123 board):
Note the space before "PropellerHex" that the auto-baud code needs to determine the baud rate in terms of ~20MHz internal RC clock cycles. Space characters occur frequently in hex mode to keep the baud accurate.
I also made a base64 load command, where each non-white-space character provides 6 bits of binary data:
"A".."Z" = 0..25
"a".."z" = 26..51
"0".."9" = 52..61
"+" = 62
"/" = 63
Here is that same program loaded via the base64 command:
White space, including space, tab, cr, and lf, can be used to break up the hex or base64 data. It would be good to begin each base64 data line with a space for frequent baud recalibration.
At 115.2k baud, the base64 mode loads over 8.5KB per second, while the hex mode loads only ~3.8KB per second.
I was thinking about smaller file sizes for the simplest of loaders. Just transmit the data. The Prop2 returns "PASS" or "FAIL", in case the sender wants to know if it worked.
Floating pins is not desirable, on CMOS parts, as the power peaks of the buffers can be significant.
Some MCUs have light pullups, and some Logic parts use a Pin-Keep approach, which has no added current when pulled either way, but does need a certain over-drive current to flip the pin.
I see what you are saying, but this is no low-power part. It's quiescent draw is going to be 1-2mA, just due to leakage in the 1.8V circuitry.
+1.
Where it matters, I put the components that ensure a safe state near the destination anyway. being able to assume virtual isolation at startup or unexpected restart can simplify that.
Is there some way to reinvoke the loader once one program is sent and executed? Or does the loader get hidden once the program is executed?
This would allow concatenation of a sequence of independent commands, eg if you wanted to set one pin doing one thing and another pin doing something else.
If you can't do that, how big is the loader code approximately?
So Chip, any chance of a new binary with a boot ROM anytime soon? I could really use it like yesterday. Turns out too that I will probably have to upgrade all the P1s to P2s in my new project once it goes to production because of security issues. That's over forty P2s per unit! But if P2 isn't available then that means I have no other choice but to use something else, as repugnant as that would be.
btw, I sense line breaks as a way of resetting the Prop so it would be nice if this feature was always active as it makes it possible to gain control to the bootloader if necessary.
I sense the P2 design is finally frozen and now comes the last 10%, verification, tools, "pre-press" for the foundery. It would be tragic to see your project have to migrate to another micro after all the work producing Tachyon for the propeller chips. Although I'm sure you can retarget the Tachyon Byte Code VM at will. But tragic for me in that I use Tachyon as a gateway/learning tool between propeller hardware and PASM. Not to mention ease of development for me. My only problem is my bloated Tachyon code that I tend to run out of memory. P2 frees me of this issue!!!! But I just refactored 100 Longs out of my current project so it's getting easier.
Go Chip Go!
Can you not use something else for security, in the interim ?
eg the EFM8BB1, or I see a Nuvoton N79E715AS16 (SO16N) is just 30c/500+, with a bootloader and 16k of Flash.
That could be used as a sort of secure co-processor / intelligent memory / secure ADC etc ?
I see EFM8BB1 has 32b unique ID, larger EFM8BB3 has 128b unique ID, and alternate N76E885 has 96b UID.
How does this interact with an Auto-Baud scheme ?
ie how can it know when a break is sent ?
Once the big bucks have been spent on UL certification I am then stuck with whatever chip I've designed in. It is far easier to develop with the Prop and Tachyon at present and once it is fully tested I have the option of migrating to another chip if P2 isn't available by then. Mind you, it looks like that is the way I will probably have to go sad to say.
A break is always way longer than any character at any practical baud rate. Say if a break were 100ms long then even at a ridiculous 300 baud that would be detected. A break always gets past any baud rate issues and is easily detected. In fact I just accept 100 framing errors in a row which is usually a break (I'd have to reduce that to 3 or so for 300 baud which would never be the case).
BTW, I do use about 84 of the little PIC12F1572s for A/D etc. The cost of the P2s vs cheaper options should never be an issue but even if it were I could easily dismiss it by bringing up the continuity of supply issue, these itty-bittys go out of production within such a short time but Parallax has proven itself as a supplier one can count on for long-term supply and support.
If the issue is security, then add just enough to satisfy that, and still develop in Tachyon.
A helper device doesn't need to be hacked, its function is fairly easily discerned and implemented, the P1 with the important code in EEPROM would still be exposed unless you have a grand idea in that regard. Even with just a loader in EEPROM I could load an encrypted binary off the microSD card with the secure master P2 issuing keys to devices as each node's binary is encrypted with a different key based on the node address perhaps. But either way, the master needs to be a secure micro.
If someone has that level of skills, & funding, you are not going to stop an equivalent product creation.
So it comes down to what it is exactly that you hope to secure against ?
Is it night shift production creepage ? or external hacking/attack ? or ?
Microchip keeps devices in production indefinitely.
Yep. We use their oldest chips in our BASIC Stamps. We are still selling them after 23 years.
Have you ever considered moving up to one of their newer chips? I would think you could get rid of the external EEPROM if you used a chip with a larger on-chip flash.
That BASIC Stamp code is wound up tighter than a ten-cent watch. Better to leave it alone.
Or make a new one with a Propeller chip! :-)
Yes. A BASIC Stamp that is a whole computer.
A quick search for cheapest MCU with USB, gives EFM8UB1 64c/1k, (bootloader included)
Cheapest 32k device is EFM8UB20 ~ $1.16, 64k+ gives either EFM8UB20F64, or STM32F070 at 128k for ~ $1.30
However, many of those are not 5V Drive, or 5V ADC, which is probably an issue....
5V ?
Cypress have a part that is 5V Drive and 5V ADC with 160KBF 16KR 2.7 V ~ 5.5 V A/D 8x12b ~$1.71
Nuvoton have M4 5V parts 40k M452LC3AE $1.52/1k, to $1.89/1k for 128KF, 32KR,
or new M4TK adds touch keys... (showing $2.23 for 256k,100pins)
or, you could look at the new wireless MCUs, but a Stamp still needs power, so 5V-USB is simplest .....
Any news on the shuttle run?
New FPGA binary date?
BTW I tested the shared LUT between cogs (without interrupts). Nice!!!
I see the M4TK etc says this
ARM® Cortex®-M4F core running up to 72 MHz
– Supports DSP extension with hardware divider
– Supports IEEE 754 compliant Floating-point Unit (FPU)
...
Boot Loader
– 16 KB embedded ROM
– Supports Nuvoton native In-System-Programming (ISP) for UART0, SPI0, I2C0, CAN*1 and USB*2
– Supports direct boot from Boot Loader by pin selection
& also
144MHz PWM, and
Voltage Adjustable Interface
– Supports user Configurable 1.8~5.5V I/O Interface with a dedicated power input (VDDIO)
– Supports UART1, SPI0, SPI1, I2C1 or I2C0 interface
- Supports 96-bit Unique ID (UID)
- Supports 128-bit Unique Customer ID (UCID)
- One built-in temperature sensor with 1℃ resolution
- Operating Temperature: -40℃~105℃
- (8KV ESD, 4KV EFT)
- Packages – LQFP 100-pin (14mm x 14mm) – LQFP 64-pin (10mm x 10mm) – LQFP 64-pin (7mm x 7mm)
– LQFP 48-pin (7mm x 7mm)
ROM loader sounds novice friendly, and the VAI would allow 5V or 3v3 interfaces, from the 5V core.
Well, yes, that's true of the host it was optimized to run in, however modern MCUs are not nearly as constraining, and you should be able to emulate a Stamp in a 72MHz Cortec M4 for example, without needing any 'code wound up tighter than a ten-cent watch'
Low Power 1.71 to 5.5 V Operation
Use point and drag schematic for custom smart pins, including opamps
48 pin LQFP