I've used 3 EFM8 parts (EFM8SB1X, EFM8SB2X and EFM8BB2X) and I used SDCC with the Nordic NRF24LE1 in commercially shipping products. I used SDCC because I didn't want to shell out for the Keil compiler. TL;DR; I like the parts because they have a decent feature set at a good price (although recently subject to availability issues) for the class of problems they fit (e.g. relatively simple or low-end embedded systems).
I think your questions are a little subjective but I can share my experience.
1) Development Environment - It looks like, other than going command line assembler, it's SDCC or Simplicity Studio. What are they like to use?
I use Simplicity Studio with the Silicon Labs parts. It's ok. A big, bloated IDE like so many others but it gets the job done. The editor is reasonable. The debugger is ok (I only say ok because it has problems with things like sleep). They have some tools to help you characterize power. They have a configuration tool that can generate start-up code and even handle things like generating code to help you transition between different states (e.g. Sleep and Run, etc). Take care to really understand what it is generating though as it's pretty literal and you need to be explicit when you're trying to do things like absolutely minimize power consumption. Also you have to explicitly set the memory model in the project setup and be aware of where your variables are going since the 8051 has three different memory models, each with different performance characteristics. All my code is C. I have never had to drop into assembly for anything with the Silicon Labs parts.
I really enjoyed using SDCC with the Nordic part. I had a simple makefile-based build system and used different editors (vi and bbedit on Mac) for code editing. I felt very close to the hardware (it helps that the Nordic chip is pretty simple). There are some syntactical differences with the Keil-based compiler that you need to be aware of (they do a good job documenting those). I did spend some time understanding what code the compiler would generate for optimization purposes. In the end I felt I could generate really performant code in C using SDCC although I did a few parts of some code in assembly because I needed sub-microsecond control of IO.
2) The '51 core - the '51 series was the first uC I used so I'm very familiar with the core and it's instruction set. But what's it like when wrapped inside an EFM8?
I never used the original 8051 stuff but it looks like it's all pretty much there with additional timers, built-in extended memory and additional peripherals. I guess the modern 8051 cores are much faster, executing instructions in 1, 2 or 3 cycles mostly (so you'll want to review that probably).
Documentation is pretty good. You'll be reading both the part spec for things like electrical characteristics and the reference manual for part operation (and peripheral programming/configuration). Be sure to read the errata. They seem to fix many things in subsequent revs but they do let some big bugs remain (see below for my I2C issue).
3) Peripherals - what are the peripherals like? Some are obviously based on the original '51 peripherals but how about the new ones?
I think the peripherals are typical of 8-bit devices. Mostly pretty simple register based control and controlled by code (as opposed to things like DMA engines). The additional timers have more modes. IIRC, I've used serial, I2C (master and slave), ADC, PWM, RTC, Flash programming, watchdog.
The I2C slave on the EFM8SB20 is busted. It can stomp on other I2C transactions. They document (and I use) a work-around that involves using one of the timers and that seems to work but it's ugly. I've not been bit by any other hardware issues.
I tend to write my own drivers for simple peripherals like these. Silicon Labs provides example code for each peripheral and maybe a library but I never found the library functions really what I wanted and it's simple enough to read the example code, the manual and write your own.
Overall I've had success with these parts. I think like any family of parts there's a learning curve to climb. I have had success in re-using code between projects which has made me more productive. I've found, like a lot of developers, that once you climb that learning curve then you're more likely to use the same family for future products. So it's always worth a bit of research as you're doing to decide on what family you want to spend your time.
Silicon Labs provides cheap dev boards if you want to get your feet wet. Clearly they're subsidizing these boards because they come with complex supporting circuitry including power monitoring that can work at uA and mA levels so you can profile power usage in Simplicity Studio.
Home
Help
Search
Login
Register
