.. 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.
Isn’t hindsight wonderful
Shame the hindsight wasn’t 3 weeks ago
Guess the next rev could change the pinout to use compatible CP2102 pinout so either CP2102 or EFM8BB could be used. The monitoring functions could be linked by solder blobs to bridge pads. Of course space is extremely tight.
Guess the next rev could change the pinout to use compatible CP2102 pinout so either CP2102 or EFM8BB could be used. The monitoring functions could be linked by solder blobs to bridge pads. Of course space is extremely tight.
Yes, I think that is exactly what Peter is doing.
I've also tracked my P2D2Pi fork, to include the same jumpers, they seem to fit ok, 1 on top, 2 on bottom, default bridged.
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.
Google search has found that VCP header source here if you need it for testing your EFM8 device with serial over USB... the VCPXpress header and library file appear to be from Silabs.
@rogloh - thanks. I will have new pcbs and more parts next week and probably make up some on Thursday. They should work fine so hopefully I will be able to send them express post same day.
The newer parts are the 24MHz preprogrammed Si5351 chips which I will use for the P2 clock and also CP2102N for USB serial, unless of course I manage to get the EFM8 up and running before then.
I've also will have heatsink PCBs and while these are just 1oz copper (cheap), they are all copper both sides although the pcb is two thirds length to allow rear mounted microSD and RTC etc. This is just a cheap way to check effectiveness of such a pcb layer.
Sounds good Peter, though just wondering if you don't fit the EFM8 device to the P2D2 will we still have full control of the flash vs SD vs serial boot selection for the P2? Isn't the micro required to pullup/down the appropriate boot pins depending on the boot order desired? I didn't see any other resistor strapping options in the recent P2D2 schematics so I was presuming the micro could be configured to do that job. Perhaps with a CP2102 we need to use some external resistors to achieve this?
Update June 1 11:00am: actually just ignore what I mention above Peter... I just located that 10k pullup on P61R to VB in your schematic so if the flash is not populated that resistor would probably also be removed to also let you boot from SD etc according to P2 boot logic table in latest P2 Google documentation. (Assuming it is still valid, perhaps it is out of date if any tweaks were made in the respin for booting, not sure there as it mentions it needs more editing).
In my own application I sort of bypass the EFM8 for P2 serial downloads and can either try to use Wifi or another USB enabled micro (AVR) to communicate with the P2 so I'm not too concerned what is fitted on the early P2D2 as long as external P62/P63 serial pin programming still works, but the EFM8 device does seem like it should be rather versatile once you learn how to get it to work.
.. unless of course I manage to get the EFM8 up and running before then..
Partial progress to report.
I've imported a EFM8UB1 example (since UB3 exact example does not exist yet) , and ported their UART0 to UART1, and EFM8UB3 register sets.
Whacked SS about until it mostly does what I intend, and I have a build and download, that seems to run at expected 48MHz and appears as COM38 when running.
Polling loop runs at 276.812kHz which is between some predictions of
48M/86/2 = 279069
48M/87/2 = 275862
Sim suggests ~ 75c for this loop, which is in right ballpark as it does not cover all opcode slowdown causes. (only other sysclk choice is 24.5MHz, ie clearly not that, plus I suspect it will not attach as COM38 at 24.5MHz )
.. but no terminal will connect to this visible COM38...
My EFM8UB1 board is damaged, so I cannot check that alternative ...
So I dig deeper, and find an older C8051F381, and build the USB_UART example for that, no changes.
Does not want to launch debug, but does seem to download, so I connect F381 card alone, and that shows as COM38 again.
This COM38 I can connect to, so the issue is not in any PC drivers or in a proven example, but maybe the UB3.VCPXpress library needs work ?
Any minor mistakes in UART1 details, should not prevent Terminal Connect ? Connect attempts have no long term effect on the polling loop, so it is not locking up.
I've come across that UB3 VCP code in the link that rogloh sent but I may wait until I get a UB3 dev board in my parts order since that includes the standard debug interface etc. I can try it out then.
I've come across that UB3 VCP code in the link that rogloh sent....
That link seemed a little strange to me.
It tags as
efm8_sdcc/efm8/mcu/EFM8UB1/VCPXpress/
so appears to be for UB1 not UB3 and it is not clear if that is a Keil lib (appears to have no source) or a SDCC lib.
Other useful info:
For your assembler, attached is an edited SI_EFM8UB3_Defs.inc I made that adds tagged with compare from UB1. ie UB3 is almost a superset of UB1, (they remove UART0, add CLU0..3, add Timer5.., improve SMbus, remove i2cslave ..)
I've not dug into the USB depths, but the SFRs all align UB1==UB3.
I just when to the home link and downloaded the whole project. There's UB3 there but I'm having a little play with it now.
I think that VCPXpress.lib is a copy of the SiLabs Keill one, as it is identical in size to my one here, and compare says ==
C:/SiliconLabs/SimplicityStudio/v4/developer/sdks/8051/Device/EFM8UB3/VCPXpress/
While I am waiting to assemble the new P2D2r3 pcbs next week (I have them now) I decided to play a little bit. First off, I attached a "heat-sink" pcb to the r2 version that I've been testing and left it to run at 325MHz. So far, so good.
Just for fun though I've taken the BREAKOUT game I wrote in Tachyon for the P1 VGA text mode and started to convert that for the P2 in TAQOZ. It's taken just minutes to write some initial code and test interactively on the monitor, even with TAQOZ console output appearing on the bottom 4 lines.
This is the code so far, just very basic stuff, but have a look what it does.
pub *BREAKOUT* PRINT" BREAKOUT FOR THE P2 - 190606" ;
*** SOUNDS ***
--- hitting a wall sound
pub BONK ROUT PIN 300 HZ 50 ms MUTE ;
*** WALL ***
( CONSTANTS )
300 := backwall --- gap behind walls (down really low for the photo)
32 := bricks --- number of brick columns
4 := walls
640 bricks / := brickw --- width of brick
10 := brickh --- height of brick
--- initialize the brick wall with 4 rows of random colored bricks/tiles from backwall (gap)
--- walls * bricks position next brick width & height with random color panel
pub WALLS walls 0 DO bricks 0 DO I brickw * x J brickh * backwall + y brickw w brickh h RND >B 1 MAX panel LOOP LOOP ;
*** BALL ***
3 := ballw 3 := ballh
--- ball position variables
word bx word by word abx word aby
pub BALL ( color -- ) bx W@ x by W@ y ballw w ballh h panel ;
*** PADDLE ***
--- paddle xy
word px word py
--- draw the paddle
pub PADDLE ( color -- ) px W@ x py W@ y 20 w 3 h panel ;
While I am waiting to assemble the new P2D2r3 pcbs next week (I have them now) I decided to play a little bit. First off, I attached a "heat-sink" pcb to the r2 version that I've been testing and left it to run at 325MHz. So far, so good.
Just for fun though I've taken the BREAKOUT game I wrote in Tachyon for the P1 VGA text mode and started to convert that for the P2 in TAQOZ. It's taken just minutes to write some initial code and test interactively on the monitor, even with TAQOZ console output appearing on the bottom 4 lines.
This is the code so far, just very basic stuff, but have a look what it does.
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.
I've lost the plot.
This seems to go back a decade+ to why the Prop doesn't have any hardware onboard.
Wasn't USB always seen as a requirement, and the standard response was as always to just use an object?
Or is the above for later generation high speed USB?
I guess the question is, is basic USB v1 still doable just as a standard OBEX object?
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.
I've lost the plot.
This seems to go back a decade+ to why the Prop doesn't have any hardware onboard.
Wasn't USB always seen as a requirement, and the standard response was as always to just use an object?
Or is the above for later generation high speed USB?
I guess the question is, is basic USB v1 still doable just as a standard OBEX object?
The 12Mbps USB circuit works, but we don't have USB code to put into ROM for boot purposes.
Wasn't USB always seen as a requirement, and the standard response was as always to just use an object?
Not really.
As Chip says, there was no room in the ROM, and USB is not stable enough to go into ROM yet, but there are other caveats too
* USB needs a higher SysCLK, whilst at boot 20MHz+ RCFAST is all that is available.
* USB is resource hungry. IIRC the ROM loader can download all 8 COGs, but a USB core needs 1-2 COGs
Many micros with onboard usb also seem to rely on external debug micros or serial USB chips mainly because onboard usb depends upon firmware, which can be overwritten or disabled etc. I think the only solution that will always work is to have dedicated usb serial. Wouldn't it be nice if that was built into the micro or the p2!
@"Peter Jakacki", as I PM'd you I am OK with EFM8 (and RTC). I'll develop the USB by myself.
Curious what do you have functioning on EFM8UB3 and USB ?
Exactly on EFM8UB3 nothing. But I have my Thunderboard EFM8UB3 (22€) on the way. I am familiar on the 8051 core so I know it will not represent an issue.
The main problem is that I still don't have a P2 in my hands and thus I can't start preparing and develop what I need. I need the EFM8 on the P2D2 and if presently Peter have troubles with that chip I don't want that this delay the P2D2r2/3 delivery ... thus I'll program the EFM8 by myself. I have paid enough attention with Peter that things such i2c was connected in the way that can sweet also my needs and anyway, even if Peter comes out with his firmware I will most probably develop mine to better adapt to my project/idea.
I've got a UB3 Thunderboard too and I'm totally at home with 8051 assembler so in a way I am itching to write my own USB drivers just as I was prepared to write my own support chip code for it. If only they had the simple 8-bit tools that were compatible with the EFM8UB range as well, then I would have had something up and running already. But alas there are the "Simplicity" tools to learn and unfortunately the examples are all in C which relies upon libraries whereas I like to have full control over the build right down to where the code and data reside.
Anyway, I've fired up the tools again and have my boards here so I will see if I can make a simple start at least. jmg has been working on the VCP example code and hopefully SIlabs will tweak the libraries it so that it will work reliably.
BTW, I didn't quite get my P2D2 boards made up this week but will do this Monday. Hopefully I will have some EFM code ready in time.
I've got a UB3 Thunderboard too and I'm totally at home with 8051 assembler so in a way I am itching to write my own USB drivers just as I was prepared to write my own support chip code for it.
That has appeal, but you also need to couple to the PC, so it needs to 'look like' a device the drivers can talk to.
That's why I'm trying VCPxpress and feeding back issues to SiLabs... it means we stay compatible with their drivers, and future revisions.
If only they had the simple 8-bit tools that were compatible with the EFM8UB range as well, then I would have had something up and running already.
The older IDE I think can work, as it does include the EFM8 part codes. but I've not used that combination much.
Silicon Laboratories IDE Revision History
-----------------------------------------
Version 5.30 IDE Version 5.30 - December 19, 2017
EFM8 Updates to synchronize MCUProgrammer V3.90 and Flash Programming Utilities V4.78 releases.
Version 5.20 IDE Version 5.20 - December 6, 2017
Added support for EFM8 UB3 devices.
But alas there are the "Simplicity" tools to learn and unfortunately the examples are all in C which relies upon libraries whereas I like to have full control over the build right down to where the code and data reside.
Simplicity Studio is large and not very nimble, but I am 'beating it into submission'. I stick with it, because I need to stay somewhat close to what SiLabs use when talking to them.
What I do like in SS are the macro expansion hover hints and `find declaration` on code I have not written myself.
Keil-C is not the smartest, and often does dead shuffles, but I am moving small pieces into ASM files, to avoid that.
Trying to keep ASM code to a minimum, by writing C 6 different ways, and picking the best ASM variant.
@MJB - Yes, I was thinking I would have a connector or two for those SPI displays. That's a good idea about having analog I/O for a scope but then again that's why I have a module plug-in area in which case I could prototype on some matrix board plug-in and after verifying the design, get some pcb versions of the analog module made, maybe even with BNCs. Digital I/Os need to be raw to be effective as general-purpose I/Os. The most I would do is maybe build in some clamp diodes perhaps but to even add series resistance would limit what we can do.
I would use the ESP32 which can also handle Bluetooth and of course I like the W5500 modules I have already.
But there would not be any bare prototype solder area on the dev board itself. This kind of thing is all wrong since you mess up the dev board completely. No, building a prototype on a bit of matrix board that plugs in as a module is the way to go and a system that I have used for many years. You can do as many versions of the module as you like and not wreck the dev board. The proto module can be completely wrecked, but you just plug in a replacement, hopefully the pcb version by that time.
But there would not be any bare prototype solder area on the dev board itself. This kind of thing is all wrong since you mess up the dev board completely. No, building a prototype on a bit of matrix board that plugs in as a module is the way to go and a system that I have used for many years. You can do as many versions of the module as you like and not wreck the dev board. The proto module can be completely wrecked, but you just plug in a replacement, hopefully the pcb version by that time.
fully agreed - no soldering on the valuable expensive dev board itself
Also of course I like to design a pcb with a case in mind, so the dev board will fit into an readily available case. One trick is to use the lid as the bottom and mount the board on that. That way you can nibble cutouts on the top edge (now bottom) of the case itself for all the connections. No need to do awkward internal cutouts. Then I print a polyester label to dress it up.
I''ve had my latest P2D2 r3 pcb for many months now and I have all the parts ready to assemble including about a dozen P2ES chips. But therein lays the dilemma seeing that the new P2 is just within reach, kinda. What I really want are a handful of the new P2 chips for these boards and I'd even take my chances with faulty chips since I can rework the pcb easily enough anyway. However, I do have these P2ES chips. What to do?
I''ve had my latest P2D2 r3 pcb for many months now and I have all the parts ready to assemble including about a dozen P2ES chips. But therein lays the dilemma seeing that the new P2 is just within reach, kinda. What I really want are a handful of the new P2 chips for these boards and I'd even take my chances with faulty chips since I can rework the pcb easily enough anyway. However, I do have these P2ES chips. What to do?
Such a tough question! Hopefully they will get at least some chips from the current revision to be packaged, even if yields aren't great. I know waiting for another foundry run is going to suck for everyone. I've been making such slow progress I'm not ready for a board revision yet but when I do I'll be building around the P2D2 footprint!
I''ve had my latest P2D2 r3 pcb for many months now and I have all the parts ready to assemble including about a dozen P2ES chips. But therein lays the dilemma seeing that the new P2 is just within reach, kinda. What I really want are a handful of the new P2 chips for these boards and I'd even take my chances with faulty chips since I can rework the pcb easily enough anyway. However, I do have these P2ES chips. What to do?
Get Chip to send some epoxy top ES2 ones, any ES2 chip that is working, needs to be on a board being tested...
They should be able to a good number of full packaged parts from the more careful testing, and these ES2 parts may have some ESD / Spike handling rules ...
I'd be happy to take my chances with interested chips since there are a couple off ways I could test them. The faulty wire bonded parts should be easy enough to check with the diode range on the meter using pin probes (pins soldered onto the tips of my probes). I could also try making a jig to press the chip onto a board and using the center pcb hole for intimate contact with the exposed pad maybe with a pogo pin or two and then use ROM TAQOZ to check it. Even if the part is soldered down, the center pcb hole makes it a lot easier to desolder the part again. Maybe.
But maybe I might just make up 3 or so boards for those who desperately need them.
Peter, given that P2 RevB will be here soon, is there anything you would change on the original BOM for the original P2D2 to accommodate them? I still have 4 boards that nobody in the Americas wanted, (probably the SMT fear). I my get qty 10 of all the parts and apply the toaster oven magic to distribute with the new chips. Seems a shame to let these boards sit here not creating code. My be worth getting a stencil made.
Comments
Looks OK to me.
Isn’t hindsight wonderful
Shame the hindsight wasn’t 3 weeks ago
Guess the next rev could change the pinout to use compatible CP2102 pinout so either CP2102 or EFM8BB could be used. The monitoring functions could be linked by solder blobs to bridge pads. Of course space is extremely tight.
I've also tracked my P2D2Pi fork, to include the same jumpers, they seem to fit ok, 1 on top, 2 on bottom, default bridged.
Google search has found that VCP header source here if you need it for testing your EFM8 device with serial over USB... the VCPXpress header and library file appear to be from Silabs.
https://github.com/ahtn/efm8_sdcc/tree/master/efm8/mcu/EFM8UB1/VCPXpress
The newer parts are the 24MHz preprogrammed Si5351 chips which I will use for the P2 clock and also CP2102N for USB serial, unless of course I manage to get the EFM8 up and running before then.
I've also will have heatsink PCBs and while these are just 1oz copper (cheap), they are all copper both sides although the pcb is two thirds length to allow rear mounted microSD and RTC etc. This is just a cheap way to check effectiveness of such a pcb layer.
Update June 1 11:00am: actually just ignore what I mention above Peter... I just located that 10k pullup on P61R to VB in your schematic so if the flash is not populated that resistor would probably also be removed to also let you boot from SD etc according to P2 boot logic table in latest P2 Google documentation. (Assuming it is still valid, perhaps it is out of date if any tweaks were made in the respin for booting, not sure there as it mentions it needs more editing).
In my own application I sort of bypass the EFM8 for P2 serial downloads and can either try to use Wifi or another USB enabled micro (AVR) to communicate with the P2 so I'm not too concerned what is fitted on the early P2D2 as long as external P62/P63 serial pin programming still works, but the EFM8 device does seem like it should be rather versatile once you learn how to get it to work.
I've imported a EFM8UB1 example (since UB3 exact example does not exist yet) , and ported their UART0 to UART1, and EFM8UB3 register sets.
Whacked SS about until it mostly does what I intend, and I have a build and download, that seems to run at expected 48MHz and appears as COM38 when running.
Polling loop runs at 276.812kHz which is between some predictions of
48M/86/2 = 279069
48M/87/2 = 275862
Sim suggests ~ 75c for this loop, which is in right ballpark as it does not cover all opcode slowdown causes. (only other sysclk choice is 24.5MHz, ie clearly not that, plus I suspect it will not attach as COM38 at 24.5MHz )
.. but no terminal will connect to this visible COM38...
My EFM8UB1 board is damaged, so I cannot check that alternative ...
So I dig deeper, and find an older C8051F381, and build the USB_UART example for that, no changes.
Does not want to launch debug, but does seem to download, so I connect F381 card alone, and that shows as COM38 again.
This COM38 I can connect to, so the issue is not in any PC drivers or in a proven example, but maybe the UB3.VCPXpress library needs work ?
Any minor mistakes in UART1 details, should not prevent Terminal Connect ? Connect attempts have no long term effect on the polling loop, so it is not locking up.
UB3 Build reports Program Size: data=133.6 xdata=472 const=110 code=9950
F380 build reports Program Size: data=113.5 xdata=472 const=285 code=9718
ie look quite similar. (different target boards )
It tags as
efm8_sdcc/efm8/mcu/EFM8UB1/VCPXpress/
so appears to be for UB1 not UB3 and it is not clear if that is a Keil lib (appears to have no source) or a SDCC lib.
Other useful info:
For your assembler, attached is an edited SI_EFM8UB3_Defs.inc I made that adds tagged with compare from UB1. ie UB3 is almost a superset of UB1, (they remove UART0, add CLU0..3, add Timer5.., improve SMbus, remove i2cslave ..)
I've not dug into the USB depths, but the SFRs all align UB1==UB3.
I think that VCPXpress.lib is a copy of the SiLabs Keill one, as it is identical in size to my one here, and compare says ==
C:/SiliconLabs/SimplicityStudio/v4/developer/sdks/8051/Device/EFM8UB3/VCPXpress/
Just for fun though I've taken the BREAKOUT game I wrote in Tachyon for the P1 VGA text mode and started to convert that for the P2 in TAQOZ. It's taken just minutes to write some initial code and test interactively on the monitor, even with TAQOZ console output appearing on the bottom 4 lines.
This is the code so far, just very basic stuff, but have a look what it does.
I've lost the plot.
This seems to go back a decade+ to why the Prop doesn't have any hardware onboard.
Wasn't USB always seen as a requirement, and the standard response was as always to just use an object?
Or is the above for later generation high speed USB?
I guess the question is, is basic USB v1 still doable just as a standard OBEX object?
The 12Mbps USB circuit works, but we don't have USB code to put into ROM for boot purposes.
Not really.
As Chip says, there was no room in the ROM, and USB is not stable enough to go into ROM yet, but there are other caveats too
* USB needs a higher SysCLK, whilst at boot 20MHz+ RCFAST is all that is available.
* USB is resource hungry. IIRC the ROM loader can download all 8 COGs, but a USB core needs 1-2 COGs
I've got a UB3 Thunderboard too and I'm totally at home with 8051 assembler so in a way I am itching to write my own USB drivers just as I was prepared to write my own support chip code for it. If only they had the simple 8-bit tools that were compatible with the EFM8UB range as well, then I would have had something up and running already. But alas there are the "Simplicity" tools to learn and unfortunately the examples are all in C which relies upon libraries whereas I like to have full control over the build right down to where the code and data reside.
Anyway, I've fired up the tools again and have my boards here so I will see if I can make a simple start at least. jmg has been working on the VCP example code and hopefully SIlabs will tweak the libraries it so that it will work reliably.
BTW, I didn't quite get my P2D2 boards made up this week but will do this Monday. Hopefully I will have some EFM code ready in time.
That's why I'm trying VCPxpress and feeding back issues to SiLabs... it means we stay compatible with their drivers, and future revisions.
The older IDE I think can work, as it does include the EFM8 part codes. but I've not used that combination much. Simplicity Studio is large and not very nimble, but I am 'beating it into submission'. I stick with it, because I need to stay somewhat close to what SiLabs use when talking to them.
What I do like in SS are the macro expansion hover hints and `find declaration` on code I have not written myself.
Keil-C is not the smartest, and often does dead shuffles, but I am moving small pieces into ASM files, to avoid that.
Trying to keep ASM code to a minimum, by writing C 6 different ways, and picking the best ASM variant.
just some random thoughts:
- LAN via WIZ5500 (I know this already) or similar
and / or
- Wifi via ESP32 ??
- BlueTooth via ESP32 ??
ideally without extra coding on ESP32 required, that would be a big slowdown
VGA/RGB
ANALOG IO - idiot save (at least SOME, nicely and safely buffered)
for use as DSO, maybe even jumper to input divider ?
Digital IO - at least some REALLY safe to play with
I might take a PPDB remove/or leave the P1 and connect the P2 board to give playground
btw. that sounds nice giving a P2 with P1 combo ...
so for me just playground.
Will add a cheap QVGA 320*240 SPI LCD like I have for P1.
I would use the ESP32 which can also handle Bluetooth and of course I like the W5500 modules I have already.
But there would not be any bare prototype solder area on the dev board itself. This kind of thing is all wrong since you mess up the dev board completely. No, building a prototype on a bit of matrix board that plugs in as a module is the way to go and a system that I have used for many years. You can do as many versions of the module as you like and not wreck the dev board. The proto module can be completely wrecked, but you just plug in a replacement, hopefully the pcb version by that time.
Such a tough question! Hopefully they will get at least some chips from the current revision to be packaged, even if yields aren't great. I know waiting for another foundry run is going to suck for everyone. I've been making such slow progress I'm not ready for a board revision yet but when I do I'll be building around the P2D2 footprint!
Get Chip to send some epoxy top ES2 ones, any ES2 chip that is working, needs to be on a board being tested...
They should be able to a good number of full packaged parts from the more careful testing, and these ES2 parts may have some ESD / Spike handling rules ...
But maybe I might just make up 3 or so boards for those who desperately need them.