I think I'm completely confused now. I paid for a P2D2 board. Which rev will I get? Also, can I pay more and get one or both of the other boards at the same time?
You will indeed get a P2D2 board, an improved one, and perhaps without making any more promises yet, the P2PAL pcb although mounting HyperRAM after production might be a bit tricky, the PSRAM is easy, and the microSD socket is handy as well as the extra led indicators etc. I will try to release some more detail about the P2PAL and P2LAB in the next day or so.
I think I'm completely confused now. I paid for a P2D2 board. Which rev will I get? Also, can I pay more and get one or both of the other boards at the same time?
You will indeed get a P2D2 board, an improved one, and perhaps without making any more promises yet, the P2PAL pcb although mounting HyperRAM after production might be a bit tricky, the PSRAM is easy, and the microSD socket is handy as well as the extra led indicators etc. I will try to release some more detail about the P2PAL and P2LAB in the next day or so.
Sounds great! I'm happy to pay more for the other boards if you are able to provide them. Just let me know how much to send.
I will let you know as soon as I have them assembled and available to ship
Anyone who has ordered a P2D2 can have a basic P2PAL mounted (if requested, and assuming it all works out) with a proper microSD socket and LED indicators and reset. The P2PAL also can have PSRAMx2 and HyperRAM options, plus a little extra maybe. Larger connectors such as HDMI and VGA etc are on the P2LAB board that the P2D2 can plug into as a module.
P2LAB also allows for dual full sized SD connectors. If you don't use them then the I/O is still available of course.
Yeah the P2PAL sounds good because the HyperRAM opens up lots of interesting options down the track for anyone who wants the extra capabilities it offers like external video memory.
I'll wait to see how it progresses and all the board's final mechanical/connection details, certainly soldering the BGA is not something I'll attempt myself.
Just waiting for the price of the full bundle with all options
so I can transfer via PayPal - Euro to $US right?
and get one to into the european shipping
jmg was doubtful about i2c slave capability with USB for the UB3. He has made it a slave at 8-bit address $36 which registers as a sensor I once used. Let's put all the I2C devices through a device scan and keep stepping it up until something breaks.
TAQOZ# lsi2c --- I2C DEVICES
$36 MCP9808 TEMPERATURE SENSOR
$A4 RV-3028 RTC
$C4 Si5351A CLOCK GEN ok
again
TAQOZ# 1000 I2C.KHZ --- ok
TAQOZ# lsi2c --- I2C DEVICES
$36 MCP9808 TEMPERATURE SENSOR
$A4 RV-3028 RTC
$C4 Si5351A CLOCK GEN ok
again
TAQOZ# 1500 i2c.khz --- ok
TAQOZ# lsi2c --- I2C DEVICES
$36 MCP9808 TEMPERATURE SENSOR
$A4 RV-3028 RTC ok
surely not this time
TAQOZ# 2000 i2c.khz --- ok
TAQOZ# lsi2c --- I2C DEVICES
$36 MCP9808 TEMPERATURE SENSOR ok
Awh, what the heck, let's bomb it.
TAQOZ# 3000 i2c.khz --- ok
TAQOZ# lsi2c --- I2C DEVICES
$36 MCP9808 TEMPERATURE SENSOR ok
TAQOZ#
I'm not sure if that really is 3MHz there, I've never been up that far before, but while the dedicated chips have fallen, something is still standing!
Thanks Ross and MJB and others, I will update the forum this week with details.
The UB3 work is progressing, I can now read the temperature and monitor the CPU 1.8V supply etc.
Check out the bottom line of the startup report in TAQOZ.
...
1) Pull-down on P2 RESn with active drive from UB3 (no power-up/down or brown-out hiccups)
2) DTR load pulse validation - simply opening and closing ports etc will not trigger a reset.
3) Valid DTR load pulse enables P59 pullup thus forcing serial load mode regardless of SD and Flash bootability
4) Short reset press = normal boot ; long reset press = disable Flash and SD boot (enter TAQOZ ROM or debugger etc)
5) Reset button and external reset actually disable SDON which cuts the SD power and is sensed as a reset request by the UB3
...
Sorry Peter, I've seen now this.
1) Perhaps you can delay the P2 boot with an R(pullup)C on the reset line and the UB3 can in any case overdrive it (low to force reset state or high to shorten the RC delay).
In this case if UB3 (which is an auxiliary element) damages, the P2 can boot anyway and notify that it can not talk to the UB3.
4) Differentiating a short/long reset button press is usefull and the UB3 can store this information inside for the P2 to evaluate during boot and do something.
But I will drive the P2 in TAQOZ ROM (no boot) only after a special command coming via USB serial channel. In any case to use TAQOZ this way you need a console connection to P2 which happens via UB3 USB to serial channel. The UB3 can monitor the first N characters coming immediately after the USB plug-in and if match boot the P2 in TAQOZ.
BTW: let us know if it is @ErNa collecting the European (Italy) orders for P2D2
The UB3 has become an integral part of the P2D2 now and there is no cause for any concern that it might be "damaged" and not release the P2 from reset. My main P2D2r4 has been modified with a pulldown on the P2 RESn and with the UB3 driving that high. This works really well and as much as I try with low supply voltages and currents, or big caps with long slow discharge on power-down, the P2 is held in reset when it isn't safe for it to run.
The UB3 works well as a watchdog over I2C which is important for when the P2D2 is built into a product and has to keep running, even if the rare glitch wants to crash it.
I already have a lot of functions built into the UB3 but it will easy enough to upgrade the firmware via USB if I add more features. There are already back-channel serial commands that were used for debugging the chip when we were testing the I2C functions, so having it monitor in the other direction should be easy enough.
ErNa has been itching to get the latest P2D2 boards and as soon as they are ready I will let him know. I am hoping to have them by the end of the month.
Hi Peter, I will take a little break 27th of July to 7th of August. So hopefully the boards arrive that time. I know after a system is design it's a burden to flatten everything nicely and I understand that Rev4 will be a near to perfect product. You've seen ManAtWorks PPM is keen to pick and place...
4) Differentiating a short/long reset button press is usefull and the UB3 can store this information inside for the P2 to evaluate during boot and do something.
Interesting.
Current UB3 tests DTR pulse width against 5.12ms time ticks for max ~ 1300ms and divides that into 3 zones, to give P2 boot choices.
I've added a P2 i2c command (0xCC) to read the captured DTR pulse width, as yes, that may be useful inside P2 user code.
Note Windows has reasonable jitter on USB drivers etc and around 16ms jitter is common, tho I noticed that Python handling is 'cleaner' than others. Not sure why that is ?
UB3 also has these simple instruments on i2c bus :
* 32b edge capture on one pin, for P2 timing 'sanity checks' against an independent clock.
* 24b generator on another pin, that covers 24MHz down to 48M/2^16/12/128/2 = 0.23841 Hz
When operated from an optional 48MHz CMOS Osc, the UB3 can Time/Generate to low ppm precision. On the USB locked RC Osc, it is ballpark 0.1% accurate.
A while ago I wrote a disassembler for the EFM8UB3 so I could get a handle on all the code, every last little bit. Then I made it so that I can reassemble this using asem-51, a common multi-platform 8051 assembler. Then I remapped the code and tables etc so that the tables are in fixed user programmable areas. I also added a lot of I2C commands so that I could change configurations and options etc from the P2 easily.
On top of this I have done the same with the UB3 bootloader itself, which can only be changed via the C2 interface. Although I haven't made any modifications, I wanted to have full control since the UB3 automatically executes this bootloader at reset before it runs user code at the reset vector. To accommodate this I have added a 3 pin header on the new P2D2s so that the user can jumper 2 pins for when they need to upgrade the UB3 firmware, and also the 3 pins are for direct factory programming making it easier to load and fully customize the UB3 firmware, as well as test the UB3 hardware.
I'm saying this because while jmg has been instrumental in developing the firmware, it relies on the Silabs libraries and needs to compile in "SImplicity Studio" which is anything but The extra features that jmg has been working on with timing capture and 48MHz output etc may be integrated back into the assembly version at some stage, but aren't necessary right at the moment. The clock output feature can't be used on the P2D2 but might be useful for a P1 design and the timing capture could be used to measure RCFAST for instance, although the P2D2 has an on-board RTC that outputs a reference clock through a 100k resistor on P34. The P2D2 also has a programmable clock generator which at present uses either a 25MHz or precision 26MHz crystal and outputs a standard 20MHz for the P2. BTW, the UB3 loads the configuration table into this during reset.
At present, I can put the UB3 through its paces and then make minute changes in exactly the right spot that I need to, and very quickly, so I'm not giving this up. It was taking way too long before getting new firmware and then testing it out, finding bugs, and then analyzing the problem then communicating, then waiting for an update etc. This development went a lot faster when we started to collaborate via Google docs rather than emails, and I could drop scope captures in there as well etc, but sometimes it is much easier to add one line of assembler myself and seconds later I can confirm if I was on the right track. So seconds instead of days
I'm hoping to have new boards back by the end of the month. The new P2D2 is being made in two variations so that I can determine which is more suitable. I wanted to change the integrated-magnetics SMPS chip to a discrete design but there is no room on the board for this. At present the MPM38222 is a very capable if more expensive solution and one of the things it does is switch the dual outputs out of phase which reduces the strain and noise on the input supply. The 3.6V output means I can use a tiny dual LDO for clean supplies to the A and B ports and still have high efficiency. The 3.6V is available on the header so external circuitry can take advantage of this preregulated supply and just use a small LDO (they don't even get hot), instead of a big regulator or another switcher. Also, some devices such as WiFi modules may be better off running from the 3.6V supply since this voltage is still safe for powering 3.3V devices, and 3.3V logic and the P2 will tolerate 3.6V on their inputs (Vdd+300mV). I might even trim this to 3.55V.
@jmg @"Peter Jakacki"
the DSR pulse width reading mostly relate to developing/debugging stage. When the product is in the field the customer can press the reset button if something is going wrong and eg P2 can reset some settings to default values on different levels, depending on the button press time.
jmg, perhaps the 0xCC instead of returning the pulse width (time taken) could instead return a byte eg BBSSxWPR where:
B is the 3 'time-zones' (01,10,11) for button press,
S is the three 'time-zones' for serial (DTR),
x is reserved for other possible sources
W is watchdog, and
P is P2 reset request
R(MSB) is the cumulative (summing) bit 0..6 (of the reset register).
By looking at R P2 can discriminate between an power-on and reset event, bits 0..6 tels the reset source
If a reset happens which source is not tracked bit R is set with all other bits set to 0; reset due to unknown reason
When/after P2 reads 0xCC UB3 clears R bit,
By writing to 0xCC the P2 requests for reset (and optionally request SD boot(h82) or flash boot(h81))
Since P2 can internally sw reset but it can't drive the reset pin requesting the reset to UB3 comes friendly to reset also other components on the mainboard that their reset pin connected to the P2D2 reset.
BTW @jmg have you the sources for UB3 available anywhere? I have one Thunderboard EFM8UB3 here to play with.
jmg, perhaps the 0xCC instead of returning the pulse width (time taken) could instead return a byte eg BBSSxWPR where:
B is the 3 'time-zones' (01,10,11) for button press,
S is the three 'time-zones' for serial (DTR),
x is reserved for other possible sources
W is watchdog, and
P is P2 reset request
R(MSB) is the cumulative (summing) bit 0..6 (of the reset register).
By looking at R P2 can discriminate between an power-on and reset event, bits 0..6 tels the reset source
If a reset happens which source is not tracked bit R is set with all other bits set to 0; reset due to unknown reason
When/after P2 reads 0xCC UB3 clears R bit,
By writing to 0xCC the P2 requests for reset (and optionally request SD boot(h82) or flash boot(h81))
Since P2 can internally sw reset but it can't drive the reset pin requesting the reset to UB3 comes friendly to reset also other components on the mainboard that their reset pin connected to the P2D2 reset.
Many of those features are available over i2c, but not as a single 'status byte'.
DTR has 3 time zones, but presently buttons have only 2, as it's harder for users to 'guess' times.
UB3 DATA Memory is now getting tight (maxed out), tho there is plenty of code memory. Latest build reports Program Size: data=177.5 xdata=4080 const=113 code=12068
BTW @jmg have you the sources for UB3 available anywhere? I have one Thunderboard EFM8UB3 here to play with.
Long term the plan is to release the source, in whatever form Simplicity Studio allows, as it's a mix of SiLabs libraries, C and ASM, but right now it is in a state of rapid flux
A move to 24 pin UB3 on one variant is planned, and that allows more pin-smarts.
..The extra features that jmg has been working on with timing capture and 48MHz output etc may be integrated back into the assembly version at some stage, ..
FIWR, 32b timing capture was/is working on your flat-ASM variant, but the 24b timing generator is recent.
..At present the MPM38222 is a very capable if more expensive solution and one of the things it does is switch the dual outputs out of phase which reduces the strain and noise on the input supply.
That 'out of phase' helps most when the loads are similar, and the supply voltages are similar and close to 50%.
The dominant load (by far) in P2 is the core, which is present for ~ 36% of the time on the 5V rail.
This is the main variant of the R5 version of the P2D2 that I will be getting made up that has all the changes that I wanted incorporated. I still have to fix up a few things with the optional full microSD socket that is mounted on the reverse with the card ejectable from the left edge. Although the component placement looks much the same there have been layout changes to the switching regulator section and the USB serial. This version still uses the QFN20 that I had problems during assembly with but the pads and layout have been improved here as well. The USB socket is different with the wide side up and the serial pin header has been removed completely. However there is a 4-pin header that has VIN and GND as well as the USB chips programming lines, C2D and C2CK. I may use this for factory programming but the middle two pins may be shorted out on power-up to put the USB chip in firmware load mode. I will do some final adjustments and checks over the next couple of days along with the P2LAB and P2PAL boards as well before sending them off for fabrication.
Has there been any thought to providing pins to connect a ESP8266 WX module. It would be nice to have 5 pins to allow plugging in an ESP WX module and being able to remotely load code onto the P2.
While the ESP WX module doesn't support P2 loading a simple mode to the firmware should make that possible.
Comments
You will indeed get a P2D2 board, an improved one, and perhaps without making any more promises yet, the P2PAL pcb although mounting HyperRAM after production might be a bit tricky, the PSRAM is easy, and the microSD socket is handy as well as the extra led indicators etc. I will try to release some more detail about the P2PAL and P2LAB in the next day or so.
Anyone who has ordered a P2D2 can have a basic P2PAL mounted (if requested, and assuming it all works out) with a proper microSD socket and LED indicators and reset. The P2PAL also can have PSRAMx2 and HyperRAM options, plus a little extra maybe. Larger connectors such as HDMI and VGA etc are on the P2LAB board that the P2D2 can plug into as a module.
P2LAB also allows for dual full sized SD connectors. If you don't use them then the I/O is still available of course.
I'll wait to see how it progresses and all the board's final mechanical/connection details, certainly soldering the BGA is not something I'll attempt myself.
I would happily pay extra to get the P2PAL & P2LAB boards to go with my P2D2.
so I can transfer via PayPal - Euro to $US right?
and get one to into the european shipping
I'm not sure if that really is 3MHz there, I've never been up that far before, but while the dedicated chips have fallen, something is still standing!
I'd be happy to order a P2PAL & P2LAB to go with my P2D2 - just let me know how much extra I owe you.
No stress!
Ross.
The UB3 work is progressing, I can now read the temperature and monitor the CPU 1.8V supply etc.
Check out the bottom line of the startup report in TAQOZ.
KERNEL Parallax P2 *TAQOZ* Extensible Firmware V2.5 'CHIP' 200MHz 200504-1430 MODULES: 2498 *DISK* SD DISK REPORTING & FORMATTING TOOLS 190800-0000 4736 *EASYFILE* SD CARD plus FAT32 with VIRTUAL MEMORY 190800-0000 1360 *SPIRAM* LY68L6400 8MB SPI RAM ACCESS 191020-0000 1762 *DECOMPILER* A decompiler for TAQOZ 190825-0000 726 *RTC* RV-3028 RTC DATE and TIME 190800-0000 592 *SMARTPINS* SMARTPIN FUNCTIONS and drive modes 190800-0000 390 *P2CLOCK* P2 CLOCK CONTROL 190800-0000 2278 *ANSI* ANSI TERMINAL SUPPORT 200410-0000 392 *EXTEND* Primary kernel extensions 200525-1000 5756 *SPIFLASH* MEMORY MAP CODE: 07064 28,772 bytes WORDS: 1DD9B 8,655 bytes DATA: 01B44 55 bytes ROOM: 93,495 bytes HARDWARE PCB P2 (P2D2) CLOCK IN 20.000000MHZ DEVICES SD CARD 63 GB SANDISK SD SC64G REV$80 #35190404 DATE:2018 /10 SPI FLASH 16MB WINBOND $EF40_1800 #4837448895114529879 I2C DEVICES $36 P2D2 UB3 USB+SUPPORT $A4 RV-3028 RTC $C4 Si5351A CLOCK GEN 2020/05/27 WED 12:25:31 18.56'C Vdd=1.8348V ------------------------------------------------------------------------------- TAQOZ#Just wondering how thing are coming along. Any news? Apologies if you have posted an update elsewhere. I looked, but couldn't find any recent posts.
1) Perhaps you can delay the P2 boot with an R(pullup)C on the reset line and the UB3 can in any case overdrive it (low to force reset state or high to shorten the RC delay).
In this case if UB3 (which is an auxiliary element) damages, the P2 can boot anyway and notify that it can not talk to the UB3.
4) Differentiating a short/long reset button press is usefull and the UB3 can store this information inside for the P2 to evaluate during boot and do something.
But I will drive the P2 in TAQOZ ROM (no boot) only after a special command coming via USB serial channel. In any case to use TAQOZ this way you need a console connection to P2 which happens via UB3 USB to serial channel. The UB3 can monitor the first N characters coming immediately after the USB plug-in and if match boot the P2 in TAQOZ.
BTW: let us know if it is @ErNa collecting the European (Italy) orders for P2D2
The UB3 works well as a watchdog over I2C which is important for when the P2D2 is built into a product and has to keep running, even if the rare glitch wants to crash it.
I already have a lot of functions built into the UB3 but it will easy enough to upgrade the firmware via USB if I add more features. There are already back-channel serial commands that were used for debugging the chip when we were testing the I2C functions, so having it monitor in the other direction should be easy enough.
ErNa has been itching to get the latest P2D2 boards and as soon as they are ready I will let him know. I am hoping to have them by the end of the month.
Current UB3 tests DTR pulse width against 5.12ms time ticks for max ~ 1300ms and divides that into 3 zones, to give P2 boot choices.
I've added a P2 i2c command (0xCC) to read the captured DTR pulse width, as yes, that may be useful inside P2 user code.
Note Windows has reasonable jitter on USB drivers etc and around 16ms jitter is common, tho I noticed that Python handling is 'cleaner' than others. Not sure why that is ?
UB3 also has these simple instruments on i2c bus :
* 32b edge capture on one pin, for P2 timing 'sanity checks' against an independent clock.
* 24b generator on another pin, that covers 24MHz down to 48M/2^16/12/128/2 = 0.23841 Hz
When operated from an optional 48MHz CMOS Osc, the UB3 can Time/Generate to low ppm precision. On the USB locked RC Osc, it is ballpark 0.1% accurate.
On top of this I have done the same with the UB3 bootloader itself, which can only be changed via the C2 interface. Although I haven't made any modifications, I wanted to have full control since the UB3 automatically executes this bootloader at reset before it runs user code at the reset vector. To accommodate this I have added a 3 pin header on the new P2D2s so that the user can jumper 2 pins for when they need to upgrade the UB3 firmware, and also the 3 pins are for direct factory programming making it easier to load and fully customize the UB3 firmware, as well as test the UB3 hardware.
I'm saying this because while jmg has been instrumental in developing the firmware, it relies on the Silabs libraries and needs to compile in "SImplicity Studio" which is anything but
At present, I can put the UB3 through its paces and then make minute changes in exactly the right spot that I need to, and very quickly, so I'm not giving this up. It was taking way too long before getting new firmware and then testing it out, finding bugs, and then analyzing the problem then communicating, then waiting for an update etc. This development went a lot faster when we started to collaborate via Google docs rather than emails, and I could drop scope captures in there as well etc, but sometimes it is much easier to add one line of assembler myself and seconds later I can confirm if I was on the right track. So seconds instead of days
I'm hoping to have new boards back by the end of the month. The new P2D2 is being made in two variations so that I can determine which is more suitable. I wanted to change the integrated-magnetics SMPS chip to a discrete design but there is no room on the board for this. At present the MPM38222 is a very capable if more expensive solution and one of the things it does is switch the dual outputs out of phase which reduces the strain and noise on the input supply. The 3.6V output means I can use a tiny dual LDO for clean supplies to the A and B ports and still have high efficiency. The 3.6V is available on the header so external circuitry can take advantage of this preregulated supply and just use a small LDO (they don't even get hot), instead of a big regulator or another switcher. Also, some devices such as WiFi modules may be better off running from the 3.6V supply since this voltage is still safe for powering 3.3V devices, and 3.3V logic and the P2 will tolerate 3.6V on their inputs (Vdd+300mV). I might even trim this to 3.55V.
the DSR pulse width reading mostly relate to developing/debugging stage. When the product is in the field the customer can press the reset button if something is going wrong and eg P2 can reset some settings to default values on different levels, depending on the button press time.
jmg, perhaps the 0xCC instead of returning the pulse width (time taken) could instead return a byte eg BBSSxWPR where:
B is the 3 'time-zones' (01,10,11) for button press,
S is the three 'time-zones' for serial (DTR),
x is reserved for other possible sources
W is watchdog, and
P is P2 reset request
R(MSB) is the cumulative (summing) bit 0..6 (of the reset register).
By looking at R P2 can discriminate between an power-on and reset event, bits 0..6 tels the reset source
If a reset happens which source is not tracked bit R is set with all other bits set to 0; reset due to unknown reason
When/after P2 reads 0xCC UB3 clears R bit,
By writing to 0xCC the P2 requests for reset (and optionally request SD boot(h82) or flash boot(h81))
Since P2 can internally sw reset but it can't drive the reset pin requesting the reset to UB3 comes friendly to reset also other components on the mainboard that their reset pin connected to the P2D2 reset.
BTW @jmg have you the sources for UB3 available anywhere? I have one Thunderboard EFM8UB3 here to play with.
Many of those features are available over i2c, but not as a single 'status byte'.
DTR has 3 time zones, but presently buttons have only 2, as it's harder for users to 'guess' times.
UB3 DATA Memory is now getting tight (maxed out), tho there is plenty of code memory. Latest build reports Program Size: data=177.5 xdata=4080 const=113 code=12068
Long term the plan is to release the source, in whatever form Simplicity Studio allows, as it's a mix of SiLabs libraries, C and ASM, but right now it is in a state of rapid flux
A move to 24 pin UB3 on one variant is planned, and that allows more pin-smarts.
That 'out of phase' helps most when the loads are similar, and the supply voltages are similar and close to 50%.
The dominant load (by far) in P2 is the core, which is present for ~ 36% of the time on the 5V rail.
While the ESP WX module doesn't support P2 loading a simple mode to the firmware should make that possible.
Mike