ZBasic Forum

A 24-pin Arduino Mini clone with integrated ESP8266...
http://www.ebay.com/itm/252075103475

Maybe there's no need to marry the Pi Zero and ESP8266, after all.

Unfortunately it does not use the new 1M Flash chip for the ESP8266. It uses the ATmega32U4 which has a USB interface so that's a another complication.

Atmel does supply a bootloader along with a PC driver that emulates a serial port. The ATMega32U4 is supported by Arduino.

And I found a DIY lightswitch that makes use of this hardware and Arduino compatibility.
http://hackaday.com/2015/11/06/the-robot-light-switch/

I also came across a similar product (under development) using the 328P and CH340G. If it actually materializes it would be more attractive for us ZBasic users.
http://www.esp8266.com/viewtopic.php?f=36&t=4752

I also came upon a board with ATmega328P mounted and sockets/pads for ESP8266 among other things.
https://www.tindie.com/products/ceech/w ... mega328p/#

Here's another ESP8266 based board that might be of interest. It uses an ESP8266 ESP-13 in an Arduino form factor with a CH340G USB-SER chip onboard. It should make an excellent ZBasic for ESP8266 development board with its 4MB memory. It's by a company that also makes an (approved) NodeMCU board so I'm hoping it will have auto-reset (I have asked the manufacturer). I have one on order and will post here when it's in hand..

The board seems reasonably priced but shipping seems excessive.
http://www.smartarduino.com/view.php?id=94894

I should have searched for other suppliers - Tindie has it for the same price but with reasonable shipping costs.
https://www.tindie.com/products/doit/es ... fi-uno-r3/

There's been no meaningful activity on the WIFIO forum (which I linked to earlier) since August so I'm not hopeful this will ever see the light of day. I think it would be popular amongst ZBasic users.
http://www.esp8266.com/viewtopic.php?f=36&t=4752

dlh wrote:There's been no meaningful activity on the WIFIO forum [...]

I've attached some photos of a prototype of a carrier board for the ESP-12E and ESP-12Q with which I've been experimenting. The basic idea is that it provides a breadboard-friendly adapter for those devices and includes the DTR-Only reset circuitry. Note, too, that the SPI pins are brought out (pins 10-15 of the outer footprint) so that they might be used.

The board does not provide a USB interface. Rather, it exposes the serial Rx, Tx and DTR lines. Neither does it have a regulator; instead it expects a 3.3V supply. It does, however, provide all of the needed pullups and pulldowns so that all that is needed is 3.3V logic level serial signals and a 3.3V supply.

The ESP-12Q has a 4MB Flash chip configured to operate in Dual mode, thus making two more pins available (that are usually used for Flash access in Quad mode).

One problem with the ESP8266 is the overwhelming amount of info on the web, much of which is inaccurate and frequently contradictory.

Do you know of a link which documents the differences between ESP-12E, ESP-12F, ESP-12Q, ESP-13 & ESP-14?

dkinzer wrote:I've attached some photos of a prototype of a carrier board for the ESP-12E and ESP-12Q with which I've been experimenting.

There is a similar board but with an onboard regulator from TronixLabs Australia. However, their listing has a dearth of details.
http://tronixlabs.com/wireless/esp8266/ ... australia/

dlh wrote:Do you know of a link which documents the differences between ESP-12E, ESP-12F, ESP-12Q, ESP-13 & ESP-14?

The page at the URL below doesn't cover all of the devices you mention but it does give information on quite a few ESP devices. Further, it is a "wiki" style page so it can be updated by the community.

http://www.esp8266.com/wiki/doku.php?id ... ule-family

dkinzer wrote:The page at the URL below doesn't cover all of the devices you mention but it does give information on quite a few ESP devices.

Thanks. That's more comprehensive than many sites I've found but it would be better if it included more details like flash size, etc.

BTW, how does flash size relate to program memory?

dlh wrote:BTW, how does flash size relate to program memory?

The simple answer is that the more Flash you have the larger your application code can be. The more complete answer is more complicated.

If you look at this page you'll find a map of the ESP8266 memory space and, farther down the page, a map of the layout of the Flash chip for both non-OTA and OTA configurations.

In the memory map, you'll see that there is "Data RAM" at 0x3ffe800, "Instruction RAM" at address 0x40100000, and "Flash Cache RAM" at 0x40108000. The "Data RAM" is essentially equivalent to RAM on an AVR and the "Instruction RAM" taken together are somewhat like Flash memory on an AVR. However, as suggested by the name, the "Flash Cache RAM" holds different content at different points in the execution of an application. Essentially, parts of the Flash content are copied to the Flash Cache RAM for execution as needed (something like paging). This is what allows an ESP8266 application to be larger than it might at first appear.

When writing an application for the ESP8266 in C, functions that don't have a special tag to indicate that they should be executed from the cache end up in the Instruction RAM. Note, however, that the size of the Instruction RAM is fairly small, only 32KB. If the total size of the code destined for Instruction RAM exceeds 32K the linker will emit an error/warning.

If a function has a special tag, __attribute__((section(".irom0.text")), it will be copied to the Flash Cache RAM as needed for execution. The maximum aggregate size for cached functions depends on the Flash size and the recipe given to the linker in the "linker script". When you build a ZBasic application for the ESP8266 the ZBasic compiler generates a custom linker script that takes into account the Flash size you specify.

The default Flash layout for a ZBasic-ESP8266 application for a 512KB Flash chip is shown on Page 61 of the ZBasic for ESP8266 manual. In the table, you'll see a 64K block beginning at address 0x00000000 described as being the "Application boot image". That block of data contains the code that will be loaded into the "Instruction RAM" as well as data for initializing application data RAM variables. All of the functions marked for caching end up in the "Application ROM code/data" portion, limited to 428K when using a 512KB Flash chip. For larger Flash chips, the size of the "Application ROM code/data" section increases by (FlashSize - 512KB).

Most of the code in the ZBasic System Library for the ESP8266 goes in the cached area. The exceptions are interrupt handlers and some small special purpose blocks of code. By default, all user-written ZBasic procedures are marked for caching except for ISR procedures. There currently is no way to designate that a non-ISR procedure shouldn't be cached. This may be a useful addition.

I understand that the SPIFFS uses static wear leveling but what about the rest of flash memory? Will we be able to wear out the flash on an ESP8266 module?

dlh wrote:Will we be able to wear out the flash on an ESP8266 module?

It is the erase/write cycle that "wears out" a Flash cell. A typical NOR Flash memory will have an endurance of 100,000 write cycles. Consquently, if you don't write to Flash other than to download a new application or SPIFFS image you needn't worry. If you are frequently updating information in a SPIFFS file system then the wear issues would be more important.

I found a description of the ESP-14. It seems to have been designed by someone unclear on the ESP8266 concept.
http://www.cnx-software.com/2015/10/26/ ... stm8s-mcu/

The schematic for this Arduino UNO like ESP8266 board shows NodeMCU type auto-reset. It also has OTA updates allowing for firmware updates from a web browser.
http://www.wemos.cc/d1/Getting_Started#schematics

Banggood has it for $2 less than the ESPDuino with free (slow boat) shipping.
http://www.banggood.com/WeMos-D1-WiFi-E ... 11870.html

The people who make it also have a D1:mini, similar to the small development boards discussed above but with voltage regulator and USB-Serial chip. It also has NodeMCU auto-reset and OTA updating. There are also some shields for it - temp, humidity, etc. I think we have a winner at $4 each with $1.44 shipping.
http://www.wemos.cc/wiki/doku.php?id=en:d1_mini

I did hear back from ESPDuino about auto-reset but the reply was gibberish. I'll let you know when it's here.

dlh wrote:The schematic for this Arduino UNO like ESP8266 board shows NodeMCU type auto-reset.

Given that there are no level converters on this board I don't understand how useful it would be since most Arduino shields are 5V. Perhaps I'm overlooking something.

dkinzer wrote:Given that there are no level converters on this board I don't understand how useful it would be since most Arduino shields are 5V. Perhaps I'm overlooking something.

I didn't anticipate using standard shields but thought of using it with a prototyping shield with a small breadboad for development purposes only.
http://www.amazon.com/Arduino-ProtoShie ... JDRHJ8V716
Once a prototype is proven, one can design 3.3V application shields but I was thinking more of using this as a test bed for applications that would use smaller versions of the ESP8266.

For example, the WeMos D1 mini is probably underpowered when connected via USB but the WeMos D1 can be powered separately. One can develop/test with the big brother and then download to the little brother, powering it from a 5V power supply once it's configured.

And, given that they supply shields for their D1 mini, they may be planning shields for these as well. And, 3.3V seems to be the current standard for various devices so I'd anticipate 3.3V Arduinos at some point.