Looking very good, Peter! I can handle North America distribution again if numbers are overwhelming.
I just realized that we're talking about bare PCBs again this time. I guess I won't be needing one. I don't have the skill to do the soldering. It looks great though!
Looking very good, Peter! I can handle North America distribution again if numbers are overwhelming.
I just realized that we're talking about bare PCBs again this time. I guess I won't be needing one. I don't have the skill to do the soldering. It looks great though!
I think Peter is going going to populate about 15 boards and sell them.
I got the parts last Thursday but while I was tempted to use the paste gun just to get it up and running I have instead waiting until today since my friend had some good quality paste and was willing to try out the stencil and load the board while I doled out the parts as required. I took quite a number of photos just to track progress and backtrack in case there is a problem.
So the plan is to make sure that this board is working fine and then use it to test out the clock gen option as well and the rtc. There are a few boards I will give away including one for Chip (as well as some blanks) and a couple I will keep and the rest I will sell to cover parts costs. There will be some spare blanks but I intend to get more done with any minor changes and perhaps a red solder mask.
I popped down the coast and got my friend who has some fresh solder paste for the stencil to make up a pcb for me. Here is the intermediate result,...
Looks great. One minor detail, I notice UB3-USB uses VA power, whilst Flash is VB. Should UB3 have the same VB power rail as the flash, as it is also flash connected ?
That could allow VA side to be 'cleaner' power and VB side to be Flash+USB Data side ?
@jmg - it was more of a routing issue and the EFM chip is not really noisy since it only draws a few milliamps. These prototypes will tell all.
Now, jmg, I still need to install and fire up the Silabs IDE and then find and adapt the USB serial code for this chip. Have you had any experience with this? I find the new IDE overly complicated that tries to deal with their 32-bit ARMs and 8-bit 8051s all in one huge messy bundle.
Now, jmg, I still need to install and fire up the Silabs IDE and then find and adapt the USB serial code for this chip. Have you had any experience with this? I find the new IDE overly complicated that tries to deal with their 32-bit ARMs and 8-bit 8051s all in one huge messy bundle.
Yes, Silabs IDE cannot be called 'small'
Last time I checked, a few months back, there was not yet a UsbToUart example for UB3, but there are for UB1/UB2. IIRC there is a UB3 HID example, but that's somewhat slower.
I've just asked SiLabs for an update around UsbToUart examples, for UB3 that use 48MHz sysclk settings.
I'll update the IDE and see what is currently in there...
I manually mounted the RTC components onto the bottom of the pcb and as I did I realized that I had made a mistake somewhere. Can you spot it?
Sure enough, the footprint I created for the 8-pin DFN RTC chip should have had 0.4mm between the pads on both sides. I had somehow set it to 1.2mm. Looks like this current batch won't get the RTC option fitted but I will do some microsurgery on my prototype just so I can test it out.
I tried centering it but it didn't respond so now I will solder up one side on the pads after I attach fine wires (single strands of IDC cable) on the other side to straddle across that extra bit.
The part next to the chip that looks like a crystal is actually the ultra-capacitor.
I feel your pain Peter and know it's hard to get a new board to be 100% perfect first go particularly once you have to make your own new SMD footprints and not use tried and true ones already successfully used before.
This small RTC limitation is no drama for me as I already have an RTC on my own board on an I2C bus so I'm happy to take one of these first prototype boards without your RTC off your hands if the rest of it tests out.
After managing to precisely align the RTC chip so that it was just touching the pads and after a good dose of flux and solder I was wondering how the tiny backup capacitor would last with the RV-3028 RTC and at the rate it is going it seems to me that it could easily last a week. The cap voltage was only 2.4V over 6 hours ago and it is 2.26V now. The typical current consumption of this chip for time-keeping in standby is 40na @3V and the chip will keep working down to 1.1V. I haven't done my maths yet but it looks pretty good to me considering the size of the cap itself which is 3225, scarcely any different from the tiny 2520 crystals.
BTW, I never really used batteries and have always favored super caps in all shapes and sizes for backing up RTC chips. I figure that if a piece of commercial equipment is left unpowered for a week then it is probably out of service and then it is probably a good idea to set time and date anyway. The RV-3028 has a programmable trickle charger which I just set to use 1K.
With these numbers I would expect that leakage is also contributing to your limit rather than just the RTC current draw of 40nA itself. Some back of envelope calculations show leakage is about the same as actual current draw because ~4.1mJ of energy was drained from the capacitor in the 6 hours, and only about 2mJ was used by the RTC, assuming a simplified linear ramp down of voltage and a constant RTC current of 40nA is continually drawn from your 0.011F cap over 6 hours (though these assumptions are probably not especially accurate).
With these numbers I would expect that leakage is also contributing to your limit rather than just the RTC current draw of 40nA itself. Some back of envelope calculations show leakage is about the same as actual current draw because ~4.1mJ of energy was drained from the capacitor in the 6 hours, and only about 2mJ was used by the RTC, assuming a simplified linear ramp down of voltage and a constant RTC current of 40nA is continually drawn from your 0.011F cap over 6 hours (though these assumptions are probably not especially accurate).
Yes, this was only a quick initial observation. No doubt I will have to bench test it over a prolonged period and then do the maths. However for the purposes that I use an RTC for, anything that lasts a couple of days is normally more than suitable and a week is a bonus. There are a lot of useful features on this chip including UNIX time, event counter, periodic countdown etc that are a good start as to what every RTC chip should do rather than just copy from decades old thinking.
Yes that chip you selected looks nice Peter. If I rework my own board I might consider adding one of these parts instead of the MCP79401 RTC + XTAL I had used. In my case with the RTC external to the P2D2 I can still use the onboard Li-ion battery to keep the RTC powered when unplugged but I think I might change to a small cap for temporary backup in the situation where the batteries are ever changed out. A cap would suit that job perfectly instead of a coin cell and is one less thing to maintain.
If you redo your board you might be able to add a hole/pad to feed backup power to the RTC so it doesn't need powering most of the time from the main regulators. I'm thinking only for portable applications that are not regularly plugged into main power, and where the P2D2 is powered off for sleeping, as that is the situation I have.
Yes that chip you selected looks nice Peter. If I rework my own board I might consider adding one of these parts instead of the MCP79401 RTC + XTAL I had used. In my case with the RTC external to the P2D2 I can still use the onboard Li-ion battery to keep the RTC powered when unplugged but I think I might change to a small cap for temporary backup in the situation where the batteries are ever changed out. A cap would suit that job perfectly instead of a coin cell and is one less thing to maintain.
If you redo your board you might be able to add a hole/pad to feed backup power to the RTC so it doesn't need powering most of the time from the main regulators. I'm thinking only for portable applications that are not regularly plugged into main power, and where the P2D2 is powered off for sleeping, as that is the situation I have.
I wonder if I could reuse the VCC pin on the B connector for this instead and have it feed the backup cap directly so that a larger cap or external supply could be used for this. I noticed too that the 50mil header pin numbers don't match up to the 100mil header on the last two pins, but it is better for routing nonetheless.
However, if the cap can hold the RTC up for many days, why would we need to power it from an external supply? It's just that in my thinking I can't see the need.
If you know of a better way to do this, then please let me know.
The unix time in TAQOZ can be read as a 32-bit long simply:
TAQOZ# UTIME@ . --- 1558840156 ok
Just thought I'd share. I've just been making changes to the next revision of the P2D2 which I may order tomorrow that fixes a couple of minor things and also routes CLK1 from the preprogrammed version of the Si5351A to the P2 so the P2 can use that 24MHz as its clock source. Maybe I might so some more on the Si5351 or I might just get my HyperRAM pcb (p2d2 Mate) finished as well. The Mate will also aid in some extra heatsinking too.
@cgracey - I can make up one or two of these newer pcbs with everything except the P2 chip itself if you like, just so you can place a production P2 directly on a pretested board and solder it up manually or I find that simply squirting paste along the pads and making islands on the center pad is all that is required and then heat it up with the hot air from the gas iron.
Remember, when the time comes, we all want to see what is happening! Obviously you will have your EVAL pcbs anyway but this board is a pretested and known component.
However, if the cap can hold the RTC up for many days, why would we need to power it from an external supply? It's just that in my thinking I can't see the need.
Well you wouldn't need to if the P2D2 regulators stays on most of the time. If you have a portable application where the P2 is battery powered you might want the sleep with the regulators off, and then power the P2D2 on by some other device (like an external micro controller, which is what I do). In my case the RTC makes sense to position external to the P2D2 board, but if there was a VBAT pin on the P2D2 I could possibly start to make use of the on-board one, though I do also use its alarm output to wake up the system. The problem is if you add too much intelligence to the P2D2 with lots of on-board peripherals and power/sleep options etc it starts to add more IO requirements otherwise it can hinder its use as a generic module for the system using it. Keeping it simple is best so I'd leave it as is.
Here is a list of the latest changes I've made to the P2D2 r3 version that I will send off:
Added 47pF cap on P59 for ES chip glitch during boot (not needed for production P2)
Fixed RV-3028 footprint
Add accessible CLKOUT pad
Add VBAT via/pad (20mil)
Added resistor option for bridging INT to P33
Added 0.2/0.4F low profile supercap option
Changed RV-3028 EVI input to 100K series + 100K pull-up on P32 (eases routing)
Changed Si5351 clock output to CLK1 via option jumper resistor to P2 XI. (preprogrammed 24MHz variants)
EVI can't float but the pullup is on the P2 side whereas the series resistor from there to the EVI is not necessary but putting it there allowed me to route the extra supercap trace back in between it. So it does get full voltage. Sometimes having a resistor like this doesn't hurt and is way to route a track on an already very packed pcb.
The one part of the P2D2 that hasn't been tested properly is the EMF8 chip. There still isn't a USB UART example for the UB3 variant but I still have to locate the sample code for the other variants anyway. I'm not impressed with the so called "Simplicity" studio IDE and the old 8-bit tools kinda support the EFM8 chip, but don't really. When I plug the P2D2 USB directly into the PC all I get is a hidraw device and the sample Python code to talk to the bootloader doesn't work properly, even after importing some libs I still need a serial lib. But that was late at night and I was tired, so I will give it another go anyway.
So I hooked up the C2D and C2CK lines to P6 and P7 and loaded my C2PROG into TAQOZ so I could check the chip, and also examine registers and memory as well as program Flash etc. So far, so good. As for tools I'm thinking of finishing off my 8051 assembler written in TAQOZ and programming and testing the EFM8 interactively from TAQOZ just so I don't have to worry about the state of the 8-bit tools on the PC.
jmg contacted Silabs about providing a UB3 USB UART example which they may get around to but in the meantime I will continue to play with this part. Maybe I might be able to make the P2D2 appear as USB memory and load up the board with a simple drag and drop. Although the chip is not USB host enabled, I do wonder if it might be possible to bit bang a USB host for HID devices such as keyboards and mice. Then we could use these chips in lots of products that require keyboard/mouse.
Anyhow, I should have new boards next week and I can then start to get the limited number of chips onto boards and out to ones who need them.
@jmg, are you prepared to test and develop 8051 code on the EFM8 chip? I could send you a P2D2 to play with.
@"Peter Jakacki" Maybe this guy's example code from this first forum post on eevblog could help. He seems to be using an EFM8 micro with SiLabs VCP drivers to communicate serially to control his device... Took him ~2hrs to get it going. YMMV with your own variant perhaps.
That source seems to be missing VCPXpress.h but that might be with the Keil suite. I read somewhere that the CP2102N uses the EFM8UBx so it would be very nice indeed to have the source code for that, but I can see the conflict of interest there. But this also means I could almost drop a CP2102N QFN20 into the same spot. Certainly every pin seems to match up. I will check the CP2102N functions and see if I can make the pins compatible with the auxiliary functions of the P2D2.
Seems I should be able to adapt the EFM pinout to suit the CP2102N on the P2D2. If I swap SDON over to SUSPENDb then that just means the SD is powered off when the USB is suspended. VDD is being monitored then on P1.0 which becomes a suspend output so that needs an isolation resistor. Then there is the RTS output pin which at present is connect to P57/SDA so I will have to perhaps micro-jumper that. This way I have instant USB serial and later on I can get the EFM chip up and fully running.
Seems I should be able to adapt the EFM pinout to suit the CP2102N on the P2D2. If I swap SDON over to SUSPENDb then that just means the SD is powered off when the USB is suspended. VDD is being monitored then on P1.0 which becomes a suspend output so that needs an isolation resistor. Then there is the RTS output pin which at present is connect to P57/SDA so I will have to perhaps micro-jumper that. This way I have instant USB serial and later on I can get the EFM chip up and fully running.
Maybe I might be able to make the P2D2 appear as USB memory and load up the board with a simple drag and drop. Although the chip is not USB host enabled, I do wonder if it might be possible to bit bang a USB host for HID devices such as keyboards and mice. Then we could use these chips in lots of products that require keyboard/mouse.
Do you mean host via EFM8UB3, bit-banging ? - That would be tight, but might work at 1.5MHz - P2 can host already, so there seems less purpose for that ?
@jmg, are you prepared to test and develop 8051 code on the EFM8 chip?
Interesting question... I know the 8051 well, but USB code is not something I've run before, which is why I was pushing Silabs to improve their examples.
They know USB far better than I do I did improve their Baud-calc code, as that stands-alone & is easy to work on.
I am playing with the examples they do have, to see what I can morph, but that is slow going, with cryptic errors that seem project setting related, not code-related....
P2 USB host is resource hungry from what I know. EFM8 should be able to reduce USB down to a simple serial I/O or I2C to the P2.
Here's an updated EFM schematic where I decided to simply drop a micro-jumper pattern I made so that the track can be cut or bridged again. Can someone give this a once over and correlate that with the CP210N-QFN20 pinout to check for compatibility? This assumes that alternate CP2102N functions are not enabled.
The original intention of a support micro was to provide some monitoring such as temperature, voltage, and watchdog/reset etc. Then a change was made from a PIC to an EFM8BB and then to the USB variant to also provide USB serial. The CP2102N is pin compatible but can only provide the USB serial which is fine if we forego the monitoring functions for the moment. In the long run the EFM8UB3 will provide the monitoring and USB serial functions.
Comments
I think Peter is going going to populate about 15 boards and sell them.
So the plan is to make sure that this board is working fine and then use it to test out the clock gen option as well and the rtc. There are a few boards I will give away including one for Chip (as well as some blanks) and a couple I will keep and the rest I will sell to cover parts costs. There will be some spare blanks but I intend to get more done with any minor changes and perhaps a red solder mask.
Looks great. One minor detail, I notice UB3-USB uses VA power, whilst Flash is VB. Should UB3 have the same VB power rail as the flash, as it is also flash connected ?
That could allow VA side to be 'cleaner' power and VB side to be Flash+USB Data side ?
Now, jmg, I still need to install and fire up the Silabs IDE and then find and adapt the USB serial code for this chip. Have you had any experience with this? I find the new IDE overly complicated that tries to deal with their 32-bit ARMs and 8-bit 8051s all in one huge messy bundle.
Last time I checked, a few months back, there was not yet a UsbToUart example for UB3, but there are for UB1/UB2. IIRC there is a UB3 HID example, but that's somewhat slower.
I've just asked SiLabs for an update around UsbToUart examples, for UB3 that use 48MHz sysclk settings.
I'll update the IDE and see what is currently in there...
Sure enough, the footprint I created for the 8-pin DFN RTC chip should have had 0.4mm between the pads on both sides. I had somehow set it to 1.2mm. Looks like this current batch won't get the RTC option fitted but I will do some microsurgery on my prototype just so I can test it out.
I tried centering it but it didn't respond so now I will solder up one side on the pads after I attach fine wires (single strands of IDC cable) on the other side to straddle across that extra bit.
The part next to the chip that looks like a crystal is actually the ultra-capacitor.
It’s not a serious mistake and once you fix the footprint it will be correct for other uses. Not like the old days of black or red/blue tape hey
This small RTC limitation is no drama for me as I already have an RTC on my own board on an I2C bus so I'm happy to take one of these first prototype boards without your RTC off your hands if the rest of it tests out.
BTW, I never really used batteries and have always favored super caps in all shapes and sizes for backing up RTC chips. I figure that if a piece of commercial equipment is left unpowered for a week then it is probably out of service and then it is probably a good idea to set time and date anyway. The RV-3028 has a programmable trickle charger which I just set to use 1K.
Yes, this was only a quick initial observation. No doubt I will have to bench test it over a prolonged period and then do the maths. However for the purposes that I use an RTC for, anything that lasts a couple of days is normally more than suitable and a week is a bonus. There are a lot of useful features on this chip including UNIX time, event counter, periodic countdown etc that are a good start as to what every RTC chip should do rather than just copy from decades old thinking.
If you redo your board you might be able to add a hole/pad to feed backup power to the RTC so it doesn't need powering most of the time from the main regulators. I'm thinking only for portable applications that are not regularly plugged into main power, and where the P2D2 is powered off for sleeping, as that is the situation I have.
I wonder if I could reuse the VCC pin on the B connector for this instead and have it feed the backup cap directly so that a larger cap or external supply could be used for this. I noticed too that the 50mil header pin numbers don't match up to the 100mil header on the last two pins, but it is better for routing nonetheless.
However, if the cap can hold the RTC up for many days, why would we need to power it from an external supply? It's just that in my thinking I can't see the need.
This ends up in TAQOZ as:
If you know of a better way to do this, then please let me know.
The unix time in TAQOZ can be read as a 32-bit long simply:
Just thought I'd share. I've just been making changes to the next revision of the P2D2 which I may order tomorrow that fixes a couple of minor things and also routes CLK1 from the preprogrammed version of the Si5351A to the P2 so the P2 can use that 24MHz as its clock source. Maybe I might so some more on the Si5351 or I might just get my HyperRAM pcb (p2d2 Mate) finished as well. The Mate will also aid in some extra heatsinking too.
@cgracey - I can make up one or two of these newer pcbs with everything except the P2 chip itself if you like, just so you can place a production P2 directly on a pretested board and solder it up manually or I find that simply squirting paste along the pads and making islands on the center pad is all that is required and then heat it up with the hot air from the gas iron.
Remember, when the time comes, we all want to see what is happening! Obviously you will have your EVAL pcbs anyway but this board is a pretested and known component.
Added 47pF cap on P59 for ES chip glitch during boot (not needed for production P2)
Fixed RV-3028 footprint
Add accessible CLKOUT pad
Add VBAT via/pad (20mil)
Added resistor option for bridging INT to P33
Added 0.2/0.4F low profile supercap option
Changed RV-3028 EVI input to 100K series + 100K pull-up on P32 (eases routing)
Changed Si5351 clock output to CLK1 via option jumper resistor to P2 XI. (preprogrammed 24MHz variants)
Done like that, the P2 pin will only get to 50% of VIO ?
P2 already has pullups, so maybe that only needs a series R as the other pin does ?
So I hooked up the C2D and C2CK lines to P6 and P7 and loaded my C2PROG into TAQOZ so I could check the chip, and also examine registers and memory as well as program Flash etc. So far, so good. As for tools I'm thinking of finishing off my 8051 assembler written in TAQOZ and programming and testing the EFM8 interactively from TAQOZ just so I don't have to worry about the state of the 8-bit tools on the PC.
jmg contacted Silabs about providing a UB3 USB UART example which they may get around to but in the meantime I will continue to play with this part. Maybe I might be able to make the P2D2 appear as USB memory and load up the board with a simple drag and drop. Although the chip is not USB host enabled, I do wonder if it might be possible to bit bang a USB host for HID devices such as keyboards and mice. Then we could use these chips in lots of products that require keyboard/mouse.
Anyhow, I should have new boards next week and I can then start to get the limited number of chips onto boards and out to ones who need them.
@jmg, are you prepared to test and develop 8051 code on the EFM8 chip? I could send you a P2D2 to play with.
https://www.eevblog.com/forum/microcontrollers/efm8-usb-first-impression/
Certainly sounds like a useful pin-map to match.
Do you mean host via EFM8UB3, bit-banging ? - That would be tight, but might work at 1.5MHz - P2 can host already, so there seems less purpose for that ?
Interesting question... I know the 8051 well, but USB code is not something I've run before, which is why I was pushing Silabs to improve their examples.
They know USB far better than I do
I am playing with the examples they do have, to see what I can morph, but that is slow going, with cryptic errors that seem project setting related, not code-related....
Here's an updated EFM schematic where I decided to simply drop a micro-jumper pattern I made so that the track can be cut or bridged again. Can someone give this a once over and correlate that with the CP210N-QFN20 pinout to check for compatibility? This assumes that alternate CP2102N functions are not enabled.
The original intention of a support micro was to provide some monitoring such as temperature, voltage, and watchdog/reset etc. Then a change was made from a PIC to an EFM8BB and then to the USB variant to also provide USB serial. The CP2102N is pin compatible but can only provide the USB serial which is fine if we forego the monitoring functions for the moment. In the long run the EFM8UB3 will provide the monitoring and USB serial functions.