Author Topic: <30 cent MCU with USB controllers, capactive touch & more: WCH's CH55X series  (Read 23829 times)

0 Members and 1 Guest are viewing this topic.

Offline dgramopTopic starter

  • Newbie
  • Posts: 9
  • Country: us
Hello All!

I  bring the CH55x series MCU's to this forum. They're pretty loaded 8051 MCUs, all of them have USB Device capability, some support USB-C, some support USB Host as well.

They come pre-loaded with a USB bootloader that way you can flash your projects

Hackaday article: https://hackaday.com/2019/02/17/how-to-program-a-really-cheap-microcontroller/
SDCC SDK & examples: https://github.com/Blinkinlabs/ch554_sdcc
German forum with discussion: https://www.mikrocontroller.net/topic/462538
librech551 flasher for *nix: https://github.com/rgwan/librech551
Development boards: https://www.electrodragon.com/product/ch552-ch554-mini-dev-board-ch55x-series/

You can purchase the MCUs off of the Chinese supplier LCSC. I myself and trying to flash them from either my linux or my mac machine. Right now I'm kind of stuck, and I'm considering flashing via serial.

I have several of these CH552s, if anyone here helps the community out and lives close enough that the shipping will not be more than the cost of several MCUs and wants one I can send one over to you. These are insanely cheap.

I have several translated datasheets, the CH554 is from the Blinkinlabs repo and has mostly the same information as the CH552, just in better english. The CH552 datasheet is translated from an online service - its readable but it's helpful to have both datasheets out just in case.
 
The following users thanked this post: JTR, thm_w, ebclr

Online oPossum

  • Super Contributor
  • ***
  • Posts: 1447
  • Country: us
  • Very dangerous - may attack at any time
I have been playing with the CH551G for a few weeks now. The low price and built in USB bootloader is an attractive combination.

This a a BoB I made for it...



EAGLE CAD files attached

@ OSH Park https://oshpark.com/shared_projects/jPinrlkB
« Last Edit: May 14, 2019, 06:00:15 am by oPossum »
 
The following users thanked this post: JTR, 3roomlab, dgramop

Online oPossum

  • Super Contributor
  • ***
  • Posts: 1447
  • Country: us
  • Very dangerous - may attack at any time
First project is a USB CDC ACM to LCD interface

https://youtu.be/4pnEp9554o0
 
The following users thanked this post: dgramop, hidden

Offline dgramopTopic starter

  • Newbie
  • Posts: 9
  • Country: us
When your microcontroller is cheaper than your passives 🤣
Their entire stock of all 360 components is 4 cents...

Interesting project @oPossum. Thanks for posting the boards!

Im having trouble flashing mine on my Linux and MacOS machines...  I've been trying to put them in download mode but I have no clue what's going on. I short DOWN and 3.3 V before plugging in, and I always end up with the same issue from librech551 - "The chip id 0x18 not yet support in the program". Even when I edit the program to recognize that hex value as 0x18 it doesn't work. I also noticed that all pins are pulled high. Is this normal behavior? What am I doing wrong?
On Windows, does the wch-supplied program work?
 

Online oPossum

  • Super Contributor
  • ***
  • Posts: 1447
  • Country: us
  • Very dangerous - may attack at any time
I am using WCHISPTool V2.70 from wch.cn on Windows 10. Works great. Maybe you could get it to work with WINE.

There was some discussion on the German forum about a new version of the USB bootloader that does not work with the open source tools. Maybe your chips have this newer bootloader.

 
The following users thanked this post: dgramop

Online oPossum

  • Super Contributor
  • ***
  • Posts: 1447
  • Country: us
  • Very dangerous - may attack at any time
All GPIO are high when the bootloader is active. I didn't try to determine if this is due to pullup resistors being enabled (most likely) or being driven high.

Note that reset is active HIGH on these chips. This is different than almost every other MCU or CPU. Active LOW is the norm. There is an internal pulldown resistor on the reset pin.
 
The following users thanked this post: dgramop

Offline dgramopTopic starter

  • Newbie
  • Posts: 9
  • Country: us
@oPossum, I think you're right.

I'm reading up the open source versions issues and readme, it seems like the new protocol is still being implemented. Till then I might install windows on a thumb drive for the sole purpose of flashing. I'll give it like 15 gigs of space haha. Even after forcing the open-source version to detect my chip it doesn't work, regardless of the protocol. If I force it to recognize the chip and if I force it to use v2 of the protocol, it I get the same issue as issue #5 in the git repo. I'll give the Windows version a shot... I hate windows
 

Online PCB.Wiz

  • Super Contributor
  • ***
  • Posts: 1837
  • Country: au
They come pre-loaded with a USB bootloader that way you can flash your projects
How do they enable USB loader ? Some pin tied low ?
You can purchase the MCUs off of the Chinese supplier LCSC. I myself and trying to flash them from either my linux or my mac machine. Right now I'm kind of stuck, and I'm considering flashing via serial.
Do they include UART loaders, in the USB loader too ?

lcsc also has the newer CH549F (QFN-28) in stock, with a faster 48MHz 8051 MCU core, and more peripherals, Host/Device capable, but also higher price than CH551.
 

Offline dgramopTopic starter

  • Newbie
  • Posts: 9
  • Country: us
Do they include UART loaders, in the USB loader too ?

I'm not sure, I think they do support a non-USB method as described in the datasheet. I'd have to check.

I've finally set up a windows VM. I've setup virtualbox to share USB devices, and I can confirm that the USB devices are being shared properly. For some reason my ch552 isn't getting flashed. I suspect it has to do with previous unsuccesful attempts with the librech551 program... But probably not because the datasheet says that we can't flash the bootloader. I think that I might be doing the programming pins wrong
[EDIT]: The WCHISPTool is saying "Wrong hex file". I brought the hex file directly from sdcc after using the makefile on the example
« Last Edit: May 14, 2019, 10:08:36 pm by dgramop »
 

Online PCB.Wiz

  • Super Contributor
  • ***
  • Posts: 1837
  • Country: au
I've finally set up a windows VM. I've setup virtualbox to share USB devices, and I can confirm that the USB devices are being shared properly. For some reason my ch552 isn't getting flashed. I suspect it has to do with previous unsuccesful attempts with the librech551 program... But probably not because the datasheet says that we can't flash the bootloader. I think that I might be doing the programming pins wrong
[EDIT]: The WCHISPTool is saying "Wrong hex file". I brought the hex file directly from sdcc after using the makefile on the example
Does it show the device name ok ? - ie has it connected ?
 
The following users thanked this post: dgramop

Offline dgramopTopic starter

  • Newbie
  • Posts: 9
  • Country: us
Ooops, I forgot. Yeah, it shows the name of the device  & has recognized it
 

Online PCB.Wiz

  • Super Contributor
  • ***
  • Posts: 1837
  • Country: au
Ooops, I forgot. Yeah, it shows the name of the device  & has recognized it
I don't have any devices here, but I see in the SW a tick under Functions for an earlier 2.3 bootloader.
Maybe try that, if there are variant changes in the loader ?
I see no Read, but there is Verify, so you could make some tiny hex files of (eg) FF FF FF and LJMP SomeAdr  and verify those.
It should report a fail address and value ?
 

Offline dgramopTopic starter

  • Newbie
  • Posts: 9
  • Country: us
I figured out the problem. I've had this problem on completely unrelated projects before as well. It stems from me having compiled on linux

As you may have figured out, I'm only really use darwin and linux, so whenever I develop for windows I get these kinds of issues every now and then. Basically, windows expects line endings to be \r\n, wheras in linux you can just do \n.
\r\n is a Carriage Return + Line Feed.

I just used unix2dos to fix that like I had before.
 

Online PCB.Wiz

  • Super Contributor
  • ***
  • Posts: 1837
  • Country: au
I figured out the problem. I've had this problem on completely unrelated projects before as well. It stems from me having compiled on linux

As you may have figured out, I'm only really use darwin and linux, so whenever I develop for windows I get these kinds of issues every now and then. Basically, windows expects line endings to be \r\n, wheras in linux you can just do \n.
\r\n is a Carriage Return + Line Feed.

I just used unix2dos to fix that like I had before.
Cool, so it was actually fairly right about that 'wrong hex file' comment ;)
Can you summarize what you have working, with maybe a screen shot of a connected and successful program pass ?
 

Online oPossum

  • Super Contributor
  • ***
  • Posts: 1447
  • Country: us
  • Very dangerous - may attack at any time
How do they enable USB loader ? Some pin tied low ?

Connect P3.6 to 3.3V via a 10k resistor during power up. Reset can not be use, must be power cycle.

 
The following users thanked this post: JTR, PCB.Wiz, dgramop

Offline dgramopTopic starter

  • Newbie
  • Posts: 9
  • Country: us
Cool, so it was actually fairly right about that 'wrong hex file' comment ;)
Yep, it was exactly right! I thought it was cross-checking something in the hex file with supported instructions or something. I wish it said wrong format or told me it had trouble parsing the file.

Can you summarize what you have working, with maybe a screen shot of a connected and successful program pass ?

I'm at school right now, so I'll post the screenshot when I get home.

How I flashed the code (minus the things that didn't work)
First, I cloned git sdcc sdk repo by Blinkinlabs so I could find working sample code. Then, I used "make" to produce binaries. Since I compiled the code on my debian Machine, I used unix2dos <hex file path> to convert the hex file's endlines from LF to CRLF. Next, I copied the hex file over to my windows machine, and then filled in the input "User File" to the path to the hex file. Then I shorted the 3.3 and DOWN as I plugged in the device into my usb hub, then I immediately unshorted the pins after plugging in the device. I could tell it was in bootloader mode because all GPIOs were pulled HIGH. Finally, I clicked "Download" to load the code onto the device. All other settings were default on the WCHISPTool.

librech551 doesn't work with the new bootloader yet - still some bugs that need ironing out according to issues on repo.
 

Offline splin

  • Frequent Contributor
  • **
  • Posts: 999
  • Country: gb
Impossible to beat, huh.

https://www.arrow.com/en/products/efm8ub10f8g-c-qfn20/silicon-labs?utm_campaign=octopart_2018&utm_currency=USD&utm_keyword=EFM8UB10F8G-C-QFN20&utm_medium=aggregator&utm_content=inv_listing&utm_source=octopart

Sure, it's a wrong price, but get it while supplies last.

The 16kB version is also cheaper than other distributors, though not stupidly cheap like this one.

So how many of you took advantage of this 'offer'? I see they have now corrected the price to $0.78 but oddly they apparantly have 11 in stock compared to 360 when they were $.0001 each. Did someone here buy 349?
 

Online oPossum

  • Super Contributor
  • ***
  • Posts: 1447
  • Country: us
  • Very dangerous - may attack at any time
These chips don't have an output mux for the UART. The UART has a rx enable, but not a tx enable. So how do you send the UART output to the pin? Nothing in the docs about that that I could find. What is seems to do is simply AND the UART and GPIO register bit. So the corresponding GPIO has to be set high for the UART to work. Took me way too long to figure this out.
 

Online oPossum

  • Super Contributor
  • ***
  • Posts: 1447
  • Country: us
  • Very dangerous - may attack at any time
PCB for the USB LCD project...

 

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 3984
  • Country: ua
8051 is terrible architecture

one dollar STM32F103C8T6 is much-much better and much-much more comfortable for programming.
« Last Edit: May 26, 2019, 05:16:15 am by radiolistener »
 

Online PCB.Wiz

  • Super Contributor
  • ***
  • Posts: 1837
  • Country: au
8051 is terrible architecture

one dollar STM32F103C8T6 is much-much better and much-much more comfortable for programming.
If you write in C, the core is largely irrelevant.

'one dollar' ?   Digikey shows $3.03905/2,400, and that part is 48 pins.
The 8051 wins on price and package size here. 8051 is growing quite rapidly in Asia, as they see room for 8 bit MCUs.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11723
  • Country: us
    • Personal site
SAM D11 is ~$1, and still much easier to program.

Compiler is irrelevant when underlying architecture is suitable for the C compiler, and 8051 is not.
Alex
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
8051 is terrible architecture

one dollar STM32F103C8T6 is much-much better and much-much more comfortable for programming.

I agree! ...  tho the STM32F103 announced in 2007 is getting a little old in the tooth and has a few limitations that the newer STMF or L models don't.
CAN Bus                       Shares memory with the USB hardware, which means that USB and CAN cannot be enabled at the same time
Serial Comms               No Autobaud

Nevertheless a STM32F103C8T6 is *immensely capable*, lightning fast, 32 bits, 53 peripherals on chip has every development tool one could ever ask for, and all Free.

I bought 10 off STM32L162RDY6TR from Arrow a couple of weeks ago for $0.90 AUD each and free shipping. These 32 bit MCUs have 384KB of Flash, 12 KB of eeprom and 48KB of ram and 46 peripherals on chip. just like the STM32F103C8T6, this mcu also has every development tool one could ever ask for, and all Free.

I also bought 10 off STM32L053C8 for $0.46 AUD with free shipping.

Delivery from the USA to my doorstep in Australia via TNT ... 4 days including a weekend !

If you shop carefully there is no reason to buy seemingly cheap Chinese homegrown 8041 mcus with no tools, scant English documentation and few internal resources when you can get really cheap, proven ARM Cortex-M's with established and proven, free toolchains for around half a dollar :)

« Last Edit: May 26, 2019, 11:17:20 am by techman-001 »
 
The following users thanked this post: I wanted a rude username

Offline sorin

  • Frequent Contributor
  • **
  • Posts: 279
  • Country: de
I bought 10 off STM32L162RDY6R from Arrow a couple of weeks ago for $0.90 AUD each and free shipping.

This code don't exist.

I also bought 10 off STM32L053C8 for $0.46 AUD with free shipping.
Delivery from the USA to my doorstep in Australia via TNT ... 4 days including a weekend !

Where did you buy them?
At Arrow they cost around 3.2$.
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
I bought 10 off STM32L162RDY6R from Arrow a couple of weeks ago for $0.90 AUD each and free shipping.

This code don't exist.

I also bought 10 off STM32L053C8 for $0.46 AUD with free shipping.
Delivery from the USA to my doorstep in Australia via TNT ... 4 days including a weekend !

Where did you buy them?
At Arrow they cost around 3.2$.

Sorry I omitted a char in error, the correct part number is STM32L162RDY6TR.

I bought them from Arrow.com. This is TODAY, I bought them a couple of weeks ago when they were OVERSTOCKED. IIRC they had about 22,000 of them at that price.

You have to keep a eye on the prices, look for 'overstock' and pounce!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf