This article from Wikipedia gives us a very comprehensive list of Arduino UNO compatible boards from “known” vendors.  There are 37 of them, excluding all the clones that are cheaply available from aliexpress etc. What makes Maker UNO distinctive is that it is specially redesigned for educational market. Let see what are the features / changes from the official Arduino UNO, follow the typical rules of “the good”, “the bad”, and “the ugly”

The Good

• More More LEDs. We all love LEDs. “Blinky” is probably the first Arduino project for many of us, then followed by “Chasing Lights”. Remember the tedious work to break out digital pins onto breadboard, plug LEDs and current limiting resistors? All these are no longer necessary with Maker UNO. We now have LED indicators built right onto the board for all digital pins. Imaging the amount of classroom time it saves! Even for advanced users, the LEDs can be super handy when debugging code. For example, turn on/off LEDs when “Serial.print” is not available, e.g., in an interrupt service routine.

• Buzzer and Button. Nothing is more exciting than making noise in the classroom. With Maker UNO it is now possible without additional hardware. A buzzer is built-in. If continuously making noise is not too welcomed in a classroom, then let the noise triggered by user button forms a more socially responsible project. Yes the button is also included. Of course there is also a switch that can turn off the buzzer permanently.

  

• Power option. Remember the gigantic 5.5mm DC jack and USB type B receptacle on the original Arduino UNO? Those are replaced by one single USB Micro-B port. Who does not carry a micro-USB cable now a days?

Summarize for the Good: More built-in peripherals, easier to power. All these significantly reduced the ownership cost and save precious classroom time.

The Bad

• I cannot really fault the board except for one issue: the CH340G USB-Serial chip it used. Well frankly speaking it is a bit unfair because I had not encountered one single problem with this chip. But historically CH340G had some issues with Mac OSX and it is largely due to the driver. So Mac users need to pay attention to download the correct driver. It is puzzling that the official WCH driver download page lists CH340G OSX driver as CH341.
  For Windows (Windows 10) users, driver is downloaded automatically from Windows Update hence no problem what-so-ever.

  

The Ugly

• Without reservation, I do have one complain. Look at the “GND” silkscreen label below. It seems as though the bottom three pins are all “GND”s because the bottom two pins are not labeled. But in fact the bottom most pin is VIN in official Arduino and “5VOUT” in Maker UNO. During one test I erroneously clipped the ground clip of my scope probe onto that pin, and BOOM, my USB hub turn itself off. So my board is a per-production version, I hope these pins can be properly labeled.

  

The Clever

Something went beyond “The Good” level. Lets save the best for last. And the best things are not always how good the construction is, how comprehensive the features are. For this time, the award belongs to the designer who made all the effort to include a blank space at back of the board for student to write his/her name! Who the genius designed this must have tons of experience in classroom! And my ultimate respect!

So here I finished my short review. Don’t forget to read the excellent article by Ober at https://hackaday.io/project/79748-arduino-uno-for-education, detailing the story behind Maker UNO. And see you Mar 23 2018 at KickStarter.

The post Arduino Redesigned – Maker UNO Review appeared first on Digital Me.

However the Facebook post did not attract too much attentions. I went ahead and shared the same on Twitter with hashtag #ESP8266.

It’s official! #ESP8266 I/Os are 5V tolerant. #goodtoknow pic.twitter.com/SBf9a7qOx9

— Baoshi (@ba0sh1) July 30, 2016

//platform.twitter.com/widgets.js

Apparently Twitter has much more bandwidth among ESP8266 fans. Soon I received quite a few counter claims that their ESP8266s were toasted by 5V input voltage. So who is correct? The chip designer or the end users? I think it would be interesting to find out.

On a side note, Twitter user vAir (@vAirMon) pointed to me that on Page 17 of ESP8266 Datasheet it is mentioned  “All digital IO pins are protected from over-voltage”. I looked into my document archive and found it does appear on “Version 4.3” of “ESP8266EX Datasheet”, released “Tuesday, May 12, 2015”.

But on a more recent version, Version 1.0 (?) , released “20160422”, the whole section is removed.

Though intriguing, the “old” datasheet do point out that the over protection is based on “snap back” circuit, not the traditional two diodes voltage clamp. I found some  background information of these two protection methods here. Basically snap back circuit sits only in between input and GND. There is no conductive path between input and power rail therefore it is not possible for 5V input voltage to raise the 3.3V rail.

Experiment

Assumption

The fact is that I do not have access to any die-inspection equipment. Even if I had the equipment I would not be able to tell if a silicon die was damaged from over voltage. Therefore the experiment is designed based on the assumption that I/O will only destroy the chip via excessive input or output current, which causes thermal breakdown. As the GPIOs on ESP8266 are specified to be able to source 12mA, and usually I/O pins are able to sink more current than sourcing, I conservatively assume that any input/output current larger than 12mA is able to fry the chip.

Test of over-voltage input

The experiment setup is as follows:

For the experiment I’m using my ESP8266 Breakout Board with ESP-12E. It has GPIO pins directly connected to the leads. The AMS1117 regulator on the breakout board is removed to get rid of LDO GND current. Instead, the module is powered with 3.3V from GW Instek GPD-3303S power supply. An Advantest/ADCMT 6240A DC Voltage Current Source/Monitor is used to simulate voltage input into GPIO5. I used the following Arduino sketch as testing firmware:

#include <esp8266wifi.h>
void setup()
{    
    WiFi.forceSleepBegin(); // turn off ESP8266 RF     
    delay(1); // give RF section time to shutdown
    Serial.begin(115200);
    Serial.println(F("ESP8266 in No-RF mode"));
    pinMode(5, INPUT);
    pinMode(4, OUTPUT_OPEN_DRAIN);
    digitalWrite(4, HIGH);
}

void loop()
{
    int pin5 = digitalRead(5);
    if (pin5 == HIGH)
        Serial.println(F("IN5=HIGH"));
    else
        Serial.println(F("IN5=LOW"));
    delay(500);
}

In the beginning of setup(), I purposely turned off WiFi  so that the power consumption of ESP8266 can be monitored from GW Instek supply more precisely without WiFi interference.
For this experiment, I vary ADCMT 6240A power output from 0V to 5.5V in 0.1V steps. Below is the result of GPIO5 input voltage vs. input current:

It is clear that

• When the input voltage varies from 0V – 5.5V, maximum sinking current for ESP8266 is only 3.52uA, maximum sourcing is 0.89uA
• Of all the experiment the supply current for ESP8266 stays at 16mA, GPIO input does not go into 3.3v rail.
• No any type of over current observed
• The GPIO input L-H transition is at 1.6-1.7V (not shown on the graph)
• It seems the chip internally has 1.8V and 3V domains. Some switching happens in between 1.8V to 3V where the input pin actually sources current out.

Test of over-voltage pull-up at output

Similar experiment is also done with over-voltage pull up at output pin. The setup is below:

In this experiment, GPIO4 is set to Open Drain output mode. An external pull-up resistor pulls GPIO4 output above 3.3V. The choice of pull-up resistor is 1K, smaller than usually required. Because of the pull-up resistor, the current feed into GPIO4 will never go beyond 5.5mA. However it is still interesting to find out what is the actual amount.

The result is below:

• When the pull-up voltage varies from 0V – 5.5V, maximum GPIO sinking current is only 3.72uA, maximum sourcing 0.83uA
• Of all the experiment the supply current for ESP8266 stays at 16mA
• No over current observed
• The 1.8V phenomenon can be observed too for output.

Conclusion

I believe the experiment result is conclusive. The ESP8266 I/O is 5V tolerant unless couple of uA current can destroy the chip. Except for completely wrong wiring, such as feed 5V into 3.3v rail or feed 5V into output pin (in output low state or in output high with push-pull mode), 5V on GPIO pins will not destroy ESP8266.

The post Is ESP8266 I/O really 5V tolerant? appeared first on Digital Me.

Appearantly the breakout board, “ESP_Module_Testboard”, is little bit too wide for breadboard use, (leaving one row on each side), I decided to make a quick development board. The end result looks like this.

Some notes about the board:

• Pin “EN” has a 10k pull-up resistor. The reset button pulls “EN” down. ESP31 does not come with a RESET pin, it seems EN does the same.
• Pin “IO0” has a 10k pull-up resistor. The “IO0” pin pulls it down. Low level on IO0 during reset allows the ESP31 to enter programming mode. This is very much the same as ESP8266. I am not sure if the pull-up resistor is needed because it seems there is one built-in. Nevertheless I just put one for safety reason.
• The red board is a FTDI USB-Serial converter. The board is set to 3.3V I/O. The orange color jumper wire from FTDI board is to get 5V power from USB, feed through an AMS1117-3.3 to power the ESP31 module. I used a 100uF output tantinium capacitor. It seems this setup is not good enough. I’ll explain later.

With the board on hand, it is now time to setup development environment. There are excellent guides at http://www.instructables.com/id/Beginners-ESP32-Guide-to-Assembly-Testing/, as well as LadyAda’s live show https://www.youtube.com/watch?v=HCGHb0OVz1s

New year is around the corner and I am so eager to continue my new year greeting video “series”. It natually envolves into this:

And the source code too: https://github.com/baoshi/ESP32-XMAS

Again some notes about the source code:

• The TFT screen contains 128×160 pixels, at 16bit/pixel it amounts to 40kB/frame, or 320kbits/frame. The SPI bus is running at 13.3MHz, that works out around 40fps. Due to some coding overhead the fastest I can achieve is about 25fps. But again becaused of the latency at WiFi side, I’m currently running the screen at 10fps. That is only 400kB/s for WiFi traffic, which is significantly slower than the claimed 140Mb/s rated speed. Of course there is huge room for improvement at software side.
• The ESP31 seems to take more power than it’s predecessor ESP8266. The above mentioned AMS1117-3.3 cannot provide enough juice. The phenomenon is garbaged output from serial port, lost WiFi connection, or failed with exception after reset. It could be a thermal issue. I ended up using a lab power supply then all the problems are gone. My supply registered 170mA when WiFi is active. Of course it includes the LCD comsumption. I will do some further investigation at a later time.
• I encouontered some WiFi abnormalities that the connection speed slows down significantly from time to time. Reset the chip will resolve the issue. For the time being I havn’t fully dig into it.
• Other than these, ESP31 (ESP32 Beta) and the current SDK (1.1.0) seems quite stable.

To all my readers or viewers I take this oppotunity to wish you a Merry Christmas and Happy New Year. See you next year.

The post First sight into ESP32 appeared first on Digital Me.

If you search MQTT and ESP8266 on the intraweb, most likely all hits can be traced back to the great work done by TuanPM. However Tuan’s code is based on Espressif’s NON-OS SDK. There has been some great debates about embedded programming with-or-without an OS. To me programming with OS vs NON-OS is like programming with C vs Assembly. I like programming in C, so I wrote a new MQTT client for Espressif’s RTOS SDK.

The source code is published at https://github.com/baoshi/ESP-RTOS-Paho

Here are some notes:

• The code is based on the Eclipse Paho project, specifically the embedded C client.
• Socket-level APIs used, the code is thread-safe.
• Many error handlings were added to the original Paho client, including time-out for most of the network functions. These are designed to work with an RTOS to support automatic error correction at various abused conditions.
• I’m compiling using the “Unofficial ESP8266 DevKit“. Other toolchain such as esp-open-sdk can be used as well (adjust pathes in Makefile).
• Skeleton code for connecting a MQTT broker is as follows:

[code]
struct Network network;
MQTTClient client = DefaultClient;
MQTTPacket_connectData data = MQTTPacket_connectData_initializer;
unsigned char mqtt_buf[100];
unsigned char mqtt_readbuf[100];

NewNetwork(&network);
ConnectNetwork(&network, MQTT_HOST, MQTT_PORT);
NewMQTTClient(&client, &network, 5000, mqtt_buf, 100, mqtt_readbuf, 100);
data.willFlag = 0;
data.MQTTVersion = 3;
data.clientID.cstring = mqtt_client_id; // you client’s unique identifier
data.username.cstring = MQTT_USER;
data.password.cstring = MQTT_PASS;
data.keepAliveInterval = 10; // interval for PING message to be sent (seconds)
data.cleansession = 0;
MQTTConnect(&client, &data);
[/code]

To subscribe to a MQTT topic, use

[code]
MQTTSubscribe(&client, "/mytopic", QOS1, topic_received);
[/code]

The parameter topic_received is a callback function handling the received message:

[code]
// Callback when receiving subscribed message
LOCAL void ICACHE_FLASH_ATTR topic_received(MessageData* md)
{
int i;
MQTTMessage* message = md->message;
dmsg_puts("Received Topic ");
for (i = 0; i t; md->topic->lenstring.len; ++i)
dmsg_putchar(md->topic->lenstring.data[i]);
dmsg_puts(", Message ");
for (i = 0; i < (int)message->payloadlen; ++i)
dmsg_putchar(((char*)message->payload)[i]);
dmsg_puts("rn");
}
[/code]

To publish a MQTT topic, use

[code]
char msg[PUB_MSG_LEN];
MQTTMessage message;
message.payload = msg;
message.payloadlen = PUB_MSG_LEN;
message.dup = 0;
message.qos = QOS1;
message.retained = 0;
MQTTPublish(&client, "topic", &message);
[/code]

The demo project included in the library shows how the MQTT related functions can be organized inside a FreeRTOS task and interact with other tasks, such as retry connection after server error, WiFi error, etc. The following diagram may be helpful to understand the code. (Imaging how this can be done using NON-OS SDK)

As Espressif had just teased us with the new ESP32 chip and RTOS is rumored to be the default SDK, I hope this piece of code will be useful.

The post ESP8266 MQTT client on RTOS appeared first on Digital Me.

Another year, another Maker Faire. Yes! for this year it is nolonger “Mini Maker Faire”, we’ve just upgraded to the full fledged “Maker Faire” event. As Singapore Maker Faire has grown 10 times compare to 3 year ago, I am not able to cover every single booth or exhibit in the event. I only write about those I’m interested in.

An Augmented Reality Sandbox is a perfect application of Kinect. Originate at UC Davis, this construction is made by the students from Temasek Secondary School.

Benjamin Low and “Art makes us” team, who made the “Synesthete’s Music Machine” last year, have came back with “Neobombe”, a simulation of   Turing machine inspired by the movie “The Imitation Game”. This setup contains 11 Arduinos driving 36 step motors. The motors spin according to the enigma decipher algorithm running at backend. Since I’m too late to write his, Ben has already published his “making-of” article here.

Leon Lim, who is the “go-to” person for DIY PCB etching in the community, bought us two day’s worth of live etching and soldering workshop. Participants have experienced PCB etching using household suppliers, drilling and soldering. The end product is a cardboard dome with colorful LED lighting, very nice!

This ball shaped robot is developed by IDA Labs. It travels on the ground and also in water. But I really do want to see a BB-8 leh. Maybe next year?

Here comes some heavy weight electronics project. Design by Adnan of 2-Watt Elements,  Chippy is an “Intel Edison powered USB hub” Intel Edison breakout board that helps developer to access Edison peripherals much much easier. Interested people please take note, Chippy is coming to market coming September.

More interesting projects from local and overseas guest are better capture using video format:

Yearly Review

As I said Maker Faire is like a new year’s day to me. The past year is an exciting year, that I am able to monetize my project. I designed an ESP8266 breakout board and start selling on Tindie since February. As of today, I sold total 332 boards across 29 countries.  And this is mainly why I have not been updating this blog too frequently, because I totally underestimated the effort went into the production and sales of these boards. My initial idea was just to sell some extra pieces from my prototype lot and recover part of the cost. But in the process it becomes so welcomed that my I can hardly fulfill orders. I’ve not able to write too much code for ESP8266 either, which is a great pity.

A “good” news is ever since Adafruit, OLIMEX and Sparkfun start to produce their versions of ESP8266 development board, my sales drops like brick wall. But this gives me more time to work on the software side and do some new projects, stay tuned

And since I’ve done so much on ESP8266, I can’t help bring a project to Maker Faire. So this is my selfie with ESP8266 clock. The clock synchronize time from NTP, gather temperature/humidity and push to a MQTT broker, and display MQTT messages from my webpage (more on this in the following posts).

A big THANKS to Mr Teo Swee Ann and Espressif Systems to make this possible.

Rant

I hesitated a bit before write this part. It will hurt someone, for sure.

ARDUINO IS NOT ELECTRONICS!

I have been talking to some makers, attending some events, and people seems to mistake Arduino as the only electronics platform.

ARDUINO IS NOT ELECTRONICS!

I have to admit Arduino helps to lower the entrance barrier, bring people onboard electronics, which is fantastic. But do not claim you understand electronics because you can follow some online tutorials and create some Arduino projects.

The same applies to Raspberry Pi, Banana Pi, Beagle Bone, etc.

I don’t know whole lot of electronics either.

I come across the Nah’s family who present this electronics learning kit in the Maker Faire. I personally give them the best project award.

This basic components block kit immediately reminds me of the Radioshark laboratory kit (clone) I started with. There is no shortcut to learning electronics. You still have to start with basic components and Ohm’s law.

For more expert advise, I highly recommend this eevBLAB episode.

/Rant over.

The post Maker Faire, Yearly Review, and Rant appeared first on Digital Me.

The new utility, named ST2Makefile, is available on https://github.com/baoshi/ST2Makefile

My limited testing shows it works for most example projects in ST’s library package, as well as STM32CubeMX exported projects. One thing needs tweaking could be that some ST’s example project contains duplicated source files. If you receive error message such as “Symbol already defined in XXX” during linking, please check the SRCS section for any duplicated source entries.

The usage is changed a little since CubeMX2Makefile.py, now you should run:

[code light=”true”]
ST2Makefile.py <TrueSTUDIO project location>
[/code]

where you can identify TrueSTUDIO project location by locating “.project” and “.cproject” files inside it.

As usual, some useful resources:

Useful links

ST2Makefile: https://github.com/baoshi/ST2Makefile
ARM GCC: https://launchpad.net/gcc-arm-embedded

My packaged GNU Make for Win32: https://ba0sh1com.files.wordpress.com/2020/09/2c1c9-make.zip

The post TrueSTUDIO STM32 project to GCC Makefile converter appeared first on Digital Me.

UPDATE

Always get update from https://github.com/baoshi/CubeMX2Makefile The code is now based on SW4STM32 project output. Thanks various contributors to make this possible.

Deprived off electronics lab back in Singapore, a Chinese new year holiday here in Shanghai home is perfect for some software projects. I have little exposure with Python but after two days of Googling (through VPN) and copy/paste, a crude CubeMX2Makefile utility is ready, available at https://github.com/baoshi/CubeMX2Makefile (OOP aficionados please forgive my spaghetti styled code. It works is it?)

As the name suggests, the program converts STM32CubeMX project into a GNU Makefile. Here is a mini-HOWTO:

1. Create a STM32CubeMX project, configure pins, peripherals and MiddleWare, then edit project settings as follows: (choose SW4STM32 instead of TrueStudio in the picture below)

   

   Make sure the Tool/IDE selection is TrueSTUDIO 4.3.1 (as of STM32CubeMX 4.6.0), and note down the “Toolchain Folder Location”. I found it necessary to empty the old “Toolchain Folder” before each code generation, otherwise the project file just keep growing regardless of settings (this could be a bug in STM32CubeMX). See update below.

2. Download the project from the Github repo below, extract files to a folder, say “C:CubeMX2Makefile”. Install Python 2.7 Win32 from www.python.org

   [code light=”true”]
   c:CubeMX2Makefile>dir /b
   .gitattributes
   .gitignore
   CubeMX2Makefile.py
   CubeMX2Makefile.tpl
   readme.md
   [/code]

3. From command prompt, execute CubeMX2Makefile.py, e.g,

   [code light=”true”]
   c:CubeMX2Makefile>CubeMX2Makefile.py R:411ProjTestF4
   File created: R:411ProjTestF4Makefile
   [/code]

4. Cd into “Toolchain Folder Locaiton”, make project, i.e.,

   [code light=”true”]
   R:411ProjTestF4>make
   …
   arm-none-eabi-size build/TestF4.elf
   text data bss dec hex filename
   5876 12 1056 6944 1b20 build/TestF4.elf
   arm-none-eabi-objcopy -O ihex build/TestF4.elf build/TestF4.hex
   [/code]

   Refer to blog and below links for ARM GCC and make utility installation. It will be much easier to import the Makefile project into Eclipse CDT for code editing and debugging.

Useful links

CubeMX2Makefile: https://github.com/baoshi/CubeMX2Makefile

STM32Cube: http://www.st.com/stm32cube

ARM GCC: https://launchpad.net/gcc-arm-embedded

My packaged GNU Make for Win32: https://ba0sh1com.files.wordpress.com/2020/09/2c1c9-make.zip

The post STM32CubeMX GCC Makefile project appeared first on Digital Me.

The modules I’m targeting are ESP-07 and ESP-12, both having identical pinout but only differ in antenna type. I choose these two because they have all the I/O available, and using same edge castellation (half vias) connectors which is easy to work with.

The modules are 16mm tall, easily occupies 4 rows (2 rows on each side) on a breadboard. Therefore my first design requirement is to minimize real estate on the breadboard. To do this I made some custom pin headers by modifying from SMT pin header.

I removed pair of pins from both ends and replace with through hole pins. This little touch strengthens the bounding between pin header and the board. If otherwise on my first version I can easily pull up all the pads when lifting the board up from breadboard. With this design, I maintain 4 rows occupation on the breadboard, that leaves another 6 rows for wiring.

The boot mode of ESP-8266 is often another source of confusion. The table below summarizes different boot modes during power on or reset:

In firmware flashing mode, user is able to update new firmware from UART0 using FLASH_DOWNLOAD_TOOLS or esptool.py.

The board is designed for ESP8266 developers so reset and flash must be made easily accessible. I designed a simple circuit that only uses one button to perform these two tasks:

During idle state, internal pull-up in the ESP8266 RESET pin turns on Q1. Q2 cut off so GPIO0 remains high due to GPIO0 internal pull-up. At the same time, C1 discharges from R2 and Q1. When user presses SW1, RESET goes low immediately. Meanwhile, Q1 turns off and 3.3V power charges C1 through R1 and R2. If user releases SW1 quickly and the voltage across C1 has not reached Q2’s threshold voltage, Q2 remains off and ESP8266 enters normal running mode. However if user holds SW1 long enough before releasing, Q2 will turn on, pull GPIO0 low. At the moment user releases SW1, RESET goes high but GPIO0 will be held low for a while due to C1 have to discharge through R2 and Q1. The choice of C1 and R2 are such that it keeps GPIO0 low long enough for ESP8266 to enter program mode.

The board also includes a 3.3V LDO (AMS-1117 3.3) and a UART header using FTDI Basic pin out. Below is my programming hardware. (Yes I’m writing OLED driver, which will be release right after).

The schematic and board are designed using KiCad BZR 5312. Windows binary is available at http://kicad.nosoftware.cz/. I have uploaded the schematic and PCB onto my GitHub page at

https://github.com/baoshi/ESP-Breakout

At the moment I’m trying to sell extra boards on Tindie. Please visit my store

Product link -> https://www.tindie.com/products/Ba0sh1/esp8266-esp-0712-full-io-breadboard-adapter/

This is my first attempt to generate some income via hobbyist project. Please support if you also want to join the ESP8266 fun!

Thanks

The post ESP8266 breadboard adapter and I’m on Tindie appeared first on Digital Me.

Digging into BLE upgrade for Macbook Air Late 2010 results in many solutions. The best resource seems to be the “Continuity-Activation-Tool” project, which is made to enable “Continuity” feature on old Mac computers. Since “Continuity” depends on BLE, I suppose this will work with Lightblue Bean. For my model of Macbook, the suggestion is either to add a USB dongle or replace the Airport Extreme card. My poor Macbook only has two USB ports, so replace the Airport Extreme card seems to be the way to go.

The suitable replacement Airport Extreme card with BLE is BCM94360CS2. It can be purchased from eBay or Taobao at reasonable price (~US$20). The kind seller also included a Pentalobe screw driver in the package, which proves to be a life saver later.

For record purpose here are the screenshot of Bluetooth and WiFi page in “System Information” before replacement:

Open the back cover of Macbook Air *REQUIRES* the pentalobe screw driver, and never assume a multi-head screw driver set will contain one.

The original Airport Extreme card has a mouthful BCM943224PCIEBT2 model number. There are two ipx antenna connectors on board, assuming one for Bluetooth and one for WiFi.

My Macbook Air has 11 inch screen. The card placement is different from most online pictures which are for 13inch model. On the 13 inch model the card has longer edge parallel to the casing, but for 11 inch it is perpendicular. It is also reported on many online resources that the antenna cable has to be rerouted to reach the new card. It seems unnecessary for my 11 inch model. I can easily fit the two cables.

At the moment I have no idea which antenna is to fit into which socket. But my random connecting seems to be working. Also noted that the new card is longer than the old one, so the mounting hole is no longer fit. However the socket is tight enough to keep the card in place.

I assemble the back cover and turn on power. Not surprisingly everything “just works”. No error and no “install driver” kinds of message at all. Even the Wireless LAN password and Bluetooth paired devices list are preserved. Here are the system information after replacement:

The Bean Loader seems to be happy with the new card as well.

As a “side effect”, the “Continuity” feature works without any tweaking, together with the “AirDrop” functionality. The replacement worth every cents of it!

The post Macbook Bluetooth upgrade for LightBlue Bean appeared first on Digital Me.

The application is made with ESP8266 RTOS SDK. SSD1306 based OLED panel is connected on GPIO4/5 using software emulated I2C. I rushed this out last night and the code is in a mess now.To prevent bad influence I’ll release the code after I reorganize them.

The post Happy New Year from ESP8266 appeared first on Digital Me.