Monthly Archives: May 2015

ESP8266 SDK 1.10 Different

Uncategorized

Something odd here.

 

So I’ve downloaded the latest ESP8266 SDK version 1.10 and while one of my bigger projects is ok, another fails miserably. If you look at some of the items below… PIN_PULLDWN_DIS for example – that is most definitely in EAGLE_SOC.H in the previous version – yet missing from the 1.10 version – I’m sure that the story will be the same for other errors in here.

Anyone know what’s up?

 

 

16:12:46 **** Build of configuration Default for project Petes_and_Aid_Code ****
mingw32-make.exe -f C:/Users/Peter/ownCloud/Documents/esp-mqtt-dev/Makefile all
LD build/app.out
c:/Espressif/ESP8266_SDK/lib\libmain.a(app_main.o): In function `user_uart_wait_tx_fifo_empty’:
(.irom0.text+0x34c): undefined reference to `user_rf_pre_init’
c:/Espressif/ESP8266_SDK/lib\libmain.a(app_main.o): In function `user_uart_wait_tx_fifo_empty’:
(.irom0.text+0x474): undefined reference to `user_rf_pre_init’
build/app_app.a(petes_code.o): In function `convertTime’:
C:\Users\Peter\ownCloud\Documents\esp-mqtt-dev/user/petes_code.c:79: undefined reference to `PIN_PULLDWN_DIS’
C:\Users\Peter\ownCloud\Documents\esp-mqtt-dev/user/petes_code.c:85: undefined reference to `PIN_PULLDWN_DIS’
build/app_app.a(petes_code.o): In function `ds_reset’:
C:/Users/Peter/ownCloud/Documents/esp-mqtt-dev/Makefile:137: recipe for target ‘build/app.out’ failed
C:\Users\Peter\ownCloud\Documents\esp-mqtt-dev/user/petes_code.c:247: undefined reference to `os_intr_lock’
C:\Users\Peter\ownCloud\Documents\esp-mqtt-dev/user/petes_code.c:248: undefined reference to `os_intr_unlock’
C:\Users\Peter\ownCloud\Documents\esp-mqtt-dev/user/petes_code.c:250: undefined reference to `os_intr_lock’
build/app_app.a(petes_code.o): In function `temperature_cb’:
C:\Users\Peter\ownCloud\Documents\esp-mqtt-dev/user/petes_code.c:1388: undefined reference to `os_intr_unlock’
build/app_app.a(petes_code.o): In function `bounce_cb’:
C:\Users\Peter\ownCloud\Documents\esp-mqtt-dev/user/petes_code.c:1382: undefined reference to `PIN_PULLDWN_DIS’
build/app_app.a(petes_code.o): In function `rtc_cb’:
C:\Users\Peter\ownCloud\Documents\esp-mqtt-dev/user/petes_code.c:1418: undefined reference to `PIN_PULLDWN_DIS’
collect2.exe: error: ld returned 1 exit status
mingw32-make.exe: *** [build/app.out] Error 1

Facebooktwitterpinterestlinkedin

Apologies

Uncategorized

Apologies to anyone who tried to register yesterday or this morning. In an attempt to reduce false registration I added a plug in to include captcha – well that worked a treat except in the process it altered the responses to new uses so that they didn’t get a password – fat load of use that was. Site is also running a little slow presumably due to interest, working on that with the service provider.

Pete.

Facebooktwitterpinterestlinkedin

Raspberry Pi 2 Logging

Raspberry Pi 2

Here’s a thing… if you’re using a Raspberry Pi as some kind of central controller for long-term home control or other data logging application you will no doubt be aware of the potential issues with FLASH memory. The Pi will let you use Linux and log stuff and shove information into databases but is perhaps not quite as aware of the limits of it’s own Flash memory as it should be? Flash only lasts so many write/erase cycles.

With that in mind I was rather pleased, using as I am the latest RASPBIAN, when I turned on email recently on the Pi, to receive daily emails from the unit along the lines of…

/etc/cron.daily/logrotate:
apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName
/etc/cron.daily/ramlog:
Restarting ramlog = saving logs to hdd: .

I’m not wildly happy about a range of messages I’ve never been able to stop about fully qualified domain names – but that’s just a warning.. however the important thing here – is the logging. This is NOT something I’ve done – and hence I can only assume it is built into the latest setup of Debian for Pi (at least the Pi2)  – clearly, logs are being saved up in memory and dumped to FLASH once a day – which will help immensely to reduce the amount of writing to FLASH – now if I could just figure out how to make it do that with MYSQL (yes, I do use an uninterruptable power supply) I could ignore the desire to strap a hard disk to my Pi (I’ve already done that with the one I’ve left running in Spain).

If anyone has been through all of this AND has RAM buffering of all MYSQL activity, do enlighten us in here.

Pete.

p.s. Funny old thing the Pi…  so this morning the email turned up with no reference to domain names!!

/etc/cron.daily/ramlog:
Restarting ramlog = saving logs to hdd: .

Facebooktwitterpinterestlinkedin

ESP8266 FLASH– Something to Ponder

ESP8266

Update: You’ll see from the original article before the break, I was having serious problems with ESP-01 versus ESP-12 etc where code running in the 12 would simply not work on the ESP-01. Well, it turns out none of this was helped by the MAKEFILE..

You’ll often see references to files at 00000 and 40000 (hex) and like me probably wondered what’s happening with all that space in the middle. Turns out much of it is thrown away.  I’ll soon put the new Makefile up that we’re using but perhaps the mere fact of this email will help some. You don’t have to have config information stored at 3c000 and you don’t have to have your code at 40000 either!

Thanks to reader Richard Burton who clearly knows more about Makefiles than I do, we’re now compiling our code starting at 20000.  It turns out that 7c000 is used by SDK – but 78000 is available and that is exactly where I am now storing non-volatile information (and this works equally well on the ESP-01, ESP-07 and ESP-12 boards and means we can now code from all the way down at 20000 continuously upwards through to 78000).  Whereas before my code was up to 73000 it now goes from 20000 to 53000 leaving a TON of room for more FLASH code.  It has to be said however that I’d not realised how close to the wind I was sailing with RAM and the outcome of that is – wherever at all possible add the ICACHE_FLASH_ATTR to your C code so that the code runs from FLASH rather than being permanently cached in RAM.

So..

If you have the start of a function like this..

LOCAL void temperature_cb(void *arg)

Just amend like this..

LOCAL ICACHE_FLASH_ATTR void temperature_cb(void *arg)

The only place I’ve found I could NOT use this was a couple of small, tight routines to handle WS2812B LEDS where time was of the essense (microsecond or so).

Shortly I’ll update this and put a link to the Makefile so you can compare with what you are using. I still don’t entirely understand the Makefile but I’m slowly getting there. Just a tad short of blogging time as we’re in the process of kitting out a house and we’re on a deadline but I plan a LOT more on this subject in the coming months as everything is starting to come together.

Below, the original article where you can see I was getting quite frustrated.

———————-

For now, I am defeated and I’m hoping one of you readers is a step ahead of me.

For a while now, we’ve had an issue blowing ESP-01 with my code which is based on TuanPMs MQTT code but just keeps getting bigger and bigger.  I’d have no problems blowing an ESP12 but once we got past API 0.96, ESP-01s would not work – then I hit on the idea of reversing the order of the two files I was blowing. That worked for a while.

 

Now the code goes all the way from 0 to 73000…. so the solution to get ESP-01s working is to use an option you see in some ECLIPSE setups for Windows – the Makefile there is a FLASHONEFILE option… this makes a single file that goes all the way up to 0x73000.  LOVELY… except – TUAN stores his variables like API and password at 3c000… so this gets wiped every time.

I thought I was being really clever by moving his pointer to 7c – so that must-keep variables would be stored at 7c000 – WELL above my code.

Nope… turn the thing off and on and the variables are remembered no problem. Update the code with FLASHONEFILE – and BANG! Variables gone, defaults loaded. I have ABSOLUTELY no idea why this is happening.

Any thoughts

Pete.

Facebooktwitterpinterestlinkedin

ESP8266 Progress

DS18B20, ESP-12, ESP12, ESP8266, MOSFET, Node Red, Raspberry Pi 2

There can be no doubt that I still have some way to go in terms of reliability with my test rig in Spain before putting this stuff in charge of the heating back home in the UK:

  • Raspberry Pi 2 is on an un-interruptible supply but does not 100% recover from loss of broadband. One example made my Apache instance disappear until I rebooted the Pi !! I’ve just instigated a check for Google connectivity every 15 minutes leading to a reboot if no success – hoping this will solve the problem.
  • ESP8266 board mostly recovers from power failure but I have one example of it simply not communicating until next power cycle. Will soon do some tests removing the power for various periods from milliseconds upwards.

Highcharts - click to enlargeOther than these points, I’m starting to get somewhere.  I have plant-watering control running, a kitchen light under dusk to midnight control using my Node-Red scheduler referred to elsewhere – and as of this morning I’m logging external temperatures locally every 15 minutes using MQTT and Node-Red to ask for temperature, MQTT, Node-Red and MYSQL to store the temperature (as read by a DS18B20 using my own ESP8266 fast code) and local HighCharts and PHP to read the temperature from the DB (including missing values) on a chart on the Pi (up to now I’ve always used GroveStreams for everything but I’d like to try storing information locally). I’ve documented all of this in previous blog entries. At some point I want to scrap the PHP and use JS within Node-Red.

Scheduler - click on the image for larger versionBuilding up to this seems such overkill – but then now it is done, the sky is the limit – setting these up (below – and remember – click on any image to show full size version) took no time at all. I used the scheduler with a new addition to my little ESP board, a timer option which turns the output (ESP-01 for example) on on request for X minutes – the board then turns the output off all on it’s own.

So for the watering I just sent the same message at dusk and dawn, a timed request for 4 minutes of watering. I figured dusk and dawn were as good a time as any and no chance of blasting hot water onto the plants (believe me, in Spain if you try this at lunchtime from a typical black pipe watering system, you’ll fry the plants).Node-Red

The lower block above simply puts out the temperature request every 15 minutes and above that an MQTT block picks up the incoming temperature and fires in insert command off to the MQTT node.

Si2302Meanwhile I’ve been pondering a device I’d not specifically come across until yesterday, the Si2302 N-channel MOSFET.  From EBay these work out at a few pence each (like, 3p in quantity) and are simply tiny SMT devices (but large enough to solder by hand).  I’m thinking these might do for powering LED strips, both simply on-off control and PWM.  If I’m reading the spec right, these should work just fine from the 3v + output of an ESP8266 with no other components (no base resistor for example) and with 1 amp’s worth of LED STRIP (12v) attached I reckon the chip should dissipate no more than 80mw. Of course my maths could be miles out but I’ve a few samples on the way to give this a shot and if they pan out I’ll stick them on the next board.

Has anyone had any experience of this particular MOSFET?

Facebooktwitterpinterestlinkedin

Moisture Sensing Conundrums

ESP8266, moisture sensing

I’ve been playing (as you’ll know if you’ve read previous blogs here) with moisture sensing.

soil sensorIt’s easy really to do this – you just put a low voltage through a couple of bits of metal and sense the current going through. All things being equal, the more current, the wetter the soil is (we’ll not get into discussions about salt water versus distilled etc.)

The problem is corrosion – too much current and especially DC current and your soil sensors soon go pretty horrible.

CorrodedSo with that in mind, rather than make my own sensors, I went off on the web in search of sensors. The very first thing you come to on EBAY are nice looking PCB-based sensors – so you get for almost nothing, a probe to go into the soil and a little circuit board to send analog or digital signals to your IOT project. You can choose to get a digital signal controlled by a POT as to what level of conductivity turns it from 0 to 1 – OR analog – the latter seems more sensible if you happen to have an analog input – as you do with an ESP-12 for example. Well, I figured if they have the market captured in low-cost sensors as there are so many ads for this particular example, they must be using low-voltage AC generated in the chip.  I connected everything up and it all works magically –

Except that I left the sensor in the soil for 2 days on test then pulled it out – and the result you see on the right. on each side of one of the sensors there is already considerable corrosion – there’s no scopeway this would last very long.  I got the scope out….

2 inputs – one blue, one yellow. The yellow is constantly at ground (oh dear), the blue at around 1.5v here…  and if you take the sensor out of the soil, the blue goes up to 2v.  So this is simply a DC current – next stop the meter – about 100ua.

It is  the positive + part of the sensor which is corroded, the ground part looking only very marginally degraded up to now.

So on the one hand, the current is indeed very low which you might expect would keep corrosion to a minimum but what you see is what you get – I can’t see how this would last more than a month or two and I would expect reading values to change during that time. 

It would not matter if this was a one-off but this design and similar seem to have cornered the very low cost project soil sensing market – there are loads of tiny variations but all it would seem using the same circuit. I can see a use for an ATTiny85 and 2 oscillating outputs coming up.   For my next trick I need to get a couple of bits of stainless rod and something plastic to hold them together – see if that works any better.  Low-cost, simple ideas welcome.

Update: So a couple of ways around this have come to my attention. One is to minimise the current by using a port bit to power the unit and simply turn it on when needed. Let’s say every 15 minute turn it on for a second, wait, read the data, turn it off.  Another thought that came from Raphael Siebenhofer is to abandon this solution cheap as it is and adopt a slightly more costly which requires you use i2c (2 wires) and use 2 insulated wires (no metal contact with the soil) and the Texas FDC1004 chip. The TI datasheet gives some ideas including the basics of a PCB layout for a capacitive sensor. http://www.ti.com/lit/ds/symlink/fdc1004.pdf

Further Update: Between reading comments from others – and a bit of grey matter burning… it is becoming obvious that this method is actually a bit of a waste of time. In winter, when it is frozen this device could indicate that the soil is dry – and needs watering – which of course it does not.  A couple of guys referred to the little buckets that Maplin do that detect rainfall. Well, that actually makes sense  so if it’s been raining today, don’t bother with watering the plants – otherwise water them say at the turn of dusk and the turn of dawn… but if it is COLD (temperature sensor), say below 3c, perhaps also don’t bother? Thoughts?

Facebooktwitterpinterestlinkedin

Deployment Beckons

Uncategorized

moisture sensorI’m now getting dangerously near the point where I have to DO something with all of this ESP8266 control stuff. We’re at the cave and I’ve a watering system to sort – a simple example – so one of the ESP012 boards has a relay on it and another has an ADC input. By the use a simple Node-red function combining timing and reading the ADC convertor (which is attached to a cheap Chines moisture sensor) and looking at the value coming out (already tongue-tested) I should be able to arrange to turn the watering system on and off twice a day – but also taking into account extreme levels of moisture either way (i.e. don’t’ bother watering the plants when it is pouring with rain… and give them a little extra when it is bone dry out there.  If I really trusted the moisture sensor I could do away with the timings – but I don’t – I am convinced the PCB-based sensor will corrode and die as the units are only £1 a time – they work incidentally from 3v3 to 5v and have 2 outputs – one is simply digital – you adjust the pot onboard to get a change of level from 0-1 etc at a certain level of humidity – the other output is analog –  I think I prefer the latter.  Anyway, one must try these things as they are cheap enough to put all over the place.

Yesterday however I came up with a problem. My wife, trying to fit a bulb in the dark, blew the fuses and of course the mains went off as did my broadband. On reconnect, it took the router a little while to get it’s act together – and I realised – the Raspberry Pi does NOT recover from no WIFI which means no controllers talking to each other.

This link to an article about using cron jobs and a script to reboot the PI  I’ve just implemented –very easy to do – just takes a minute or so… checks the router address every 5 minutes – and if it does not get a response – reboots the Pi. Hopefully that’s that problem out of the way. I already know that the little ESP boards with MQTT have a watchdog timer and so they reboot until they get a connection. Here’s hoping that is sufficient to guarantee operation under real-life circumstances.

Facebooktwitterpinterestlinkedin

ESP-12E with Extra Pins!

ESP-12, ESP-12E, ESP8266

ESP-12EHere’s the picture. £2.25 including post – what more could you want! So this is like an ESP-12 – already the best of the bunch – but with more IO – specifically 6 more IO lines… this just keeps on getting better – whatever next, built in Bluetooth??

Well that’s another board design in the bin – thankfully we were just looking towards doing and updated design… may as well fit the extra pins in – you never know when they might come in handy…

Oh, hang on it gets better – 5 off well under £2 each..

http://fr.aliexpress.com/item/2015-New-Version-ESP-12-ESP8266-ESP-12-Wireless-Serial-WiFi-Module-Authenticity-Guaranteed-Free-Shipping/32339199087.html

Facebooktwitterpinterestlinkedin

The Worlds first $9 Computer

Uncategorized

Oh yes, I like this.. By the look of it not available until next year – a tiny board with the power perhaps of something like a Raspberry Pi but tiny and lower cost (well, that’s IF the postage doesn’t kill it).  I’ll be keeping an eye on this one.. WIFI + Bluetooth  – that actually in SOME respects gives it a big edge over any alternatives in the low-price end. 512MB RAM, 4GIG Flash – I’m getting quite excited already.

Facebooktwitterpinterestlinkedin

DIL Adaptor for ESP07 and ESP12

ESP-07

So what started me off on this journey which led to a kluge fix for the ESP SDK 1.01 (YES!!) was a parcel which appeared yesterday from Baoshi (which in Chinese means “gem stone”) containing 2 of his ESP-07 ESP-2 adaptor boards which he very kindly sent me.

ESP adaptor boardThe boards come complete with the LUA code so you can use them out of the box but me being me I wanted me own software on there and so set my FTDI to 3v3, applied 5v power to the board and off I went… when my code didn’t work – I started to investigate and another blog here explains what happened – the end result – problem solved, nothing to do with the board but with the size of my code and the difference between the ESP-01, ESP-07 and ESP-12 boards (more FLASH in the latter – at least in the ones I have – LOTS more). Click on the image on the left for a larger version of the adaptor board with an ESP-07 on it.

ba0sh1.comSo where does that leave these adaptors? I think they are great – especially if you are working on 0.1” breadboard because what you end up with is a device you can plug straight into the breadboard complete with regulator and rather neat reset button – press quickly – you get a reset, press slowly (over 1 second) and you end up in programming mode!! The regulator and various passives are on the underside of the board so all in you have a very neat solution that is not much wider than the original ESP-07 and yes that’s a standard FTDI connection on the left. Here’s the website link. The diagram for the reset circuit and more is all on the site.  At the very end of the board, separated from all else is the ground and +5v (or more) connection. The board came complete with very comprehensive documentation as well…  schematic and board files are all available and there was a link included to a rather handy serial terminal that lets you look at that 78k baud crap that comes out of the boards at power on.. http://www.compuphase.com/software_termite.htm

Facebooktwitterpinterestlinkedin

ESP8266 FLASH SIZES and SDK issues

ESP-01, ESP-07, ESP-12, ESP12, ESP8266

 

Below you will see the MAKE file used in Windows for compiling ESP8266 code for, for example TUANPMs MQTT software which I often use as a base with the Eclipse programming environment.  My code is routinely compiled and run on ESP-12 boards and some time ago when I upgraded from the 0.96 SDK to 1.0 I stumbled on the fact that it would sometimes not run.

Well thanks to a conversation with Baoshi Zhu I may be getting to the bottom of this. It turns out that just maybe the ESP-12 has more FLASH memory than the ESP-01 and ESP-07.  My code runs on ESP-12 but using 1.0 or 1.1 SDK it will NOT run (though it compiles perfectly) on the ESP-01 or ESP-07. I discovered THIS when the above sent me a couple of samples of his excellent backboards for the ESP-07 (more on that later) and my code compiled on them but refused to run. It was not until I got an email from him suggesting that memory might be the issue (and I didn’t believe it at first). Sure enough I can repeat the problem on the 01.  The code compiles perfectly but nothing happens when you try to run it.

So – the question is – does anyone know how to modify this MAKE file to FORCE the use of a 4Mbit (512KB) FLASH… obviously the code fits or it would not work with the 0.96 compiler??? Once resolved this might prove useful for a lot of people.

# Changelog
# Changed the variables to include the header file directory
# Added global var for the XTENSA tool root
#
# This make file still needs some work.
#
#
# Output directors to store intermediate compiled files
# relative to the project directory
BUILD_BASE    = build
FW_BASE        = firmware
FLAVOR = release
#FLAVOR = debug

# Base directory for the compiler
XTENSA_TOOLS_ROOT ?= c:/Espressif/xtensa-lx106-elf/bin

# base directory of the ESP8266 SDK package, absolute
SDK_BASE    ?= c:/Espressif/ESP8266_SDK_1.01

#Esptool.py path and port
PYTHON        ?= C:\Python27\python.exe
ESPTOOL        ?= c:\Espressif\utils\esptool.py
ESPPORT        ?= COM6

# name for the target project
TARGET        = app

# which modules (subdirectories) of the project to include in compiling
MODULES        = driver mqtt user
EXTRA_INCDIR    = include $(SDK_BASE)/../include

# libraries used in this project, mainly provided by the SDK
LIBS        = c gcc hal phy pp net80211 lwip wpa upgrade main ssl

# compiler flags using during compilation of source files
CFLAGS        = -Os -Wpointer-arith -Wundef -Werror -Wl,-EL -fno-inline-functions -nostdlib -mlongcalls -mtext-section-literals  -D__ets__ -DICACHE_FLASH

# linker flags used to generate the main object file
LDFLAGS        = -nostdlib -Wl,–no-check-sections -u call_user_start -Wl,-static

ifeq ($(FLAVOR),debug)
CFLAGS += -g -O0
LDFLAGS += -g -O0
endif

ifeq ($(FLAVOR),release)
CFLAGS += -g -O2
LDFLAGS += -g -O2
endif

# linker script used for the above linkier step
LD_SCRIPT    = eagle.app.v6.ld

# various paths from the SDK used in this project
SDK_LIBDIR    = lib
SDK_LDDIR    = ld
SDK_INCDIR    = include include/json

# we create two different files for uploading into the flash
# these are the names and options to generate them
FW_FILE_1    = 0x00000
FW_FILE_1_ARGS    = -bo $@ -bs .text -bs .data -bs .rodata -bc -ec
FW_FILE_2    = 0x40000
FW_FILE_2_ARGS    = -es .irom0.text $@ -ec

# select which tools to use as compiler, librarian and linker
CC        := $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-gcc
AR        := $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-ar
LD        := $(XTENSA_TOOLS_ROOT)/xtensa-lx106-elf-gcc

####
#### no user configurable options below here
####
FW_TOOL        ?= $(XTENSA_TOOLS_ROOT)/esptool
SRC_DIR        := $(MODULES)
BUILD_DIR    := $(addprefix $(BUILD_BASE)/,$(MODULES))

SDK_LIBDIR    := $(addprefix $(SDK_BASE)/,$(SDK_LIBDIR))
SDK_INCDIR    := $(addprefix -I$(SDK_BASE)/,$(SDK_INCDIR))

SRC        := $(foreach sdir,$(SRC_DIR),$(wildcard $(sdir)/*.c))
OBJ        := $(patsubst %.c,$(BUILD_BASE)/%.o,$(SRC))
LIBS        := $(addprefix -l,$(LIBS))
APP_AR        := $(addprefix $(BUILD_BASE)/,$(TARGET)_app.a)
TARGET_OUT    := $(addprefix $(BUILD_BASE)/,$(TARGET).out)

LD_SCRIPT    := $(addprefix -T$(SDK_BASE)/$(SDK_LDDIR)/,$(LD_SCRIPT))

INCDIR    := $(addprefix -I,$(SRC_DIR))
EXTRA_INCDIR    := $(addprefix -I,$(EXTRA_INCDIR))
MODULE_INCDIR    := $(addsuffix /include,$(INCDIR))

FW_FILE_1    := $(addprefix $(FW_BASE)/,$(FW_FILE_1).bin)
FW_FILE_2    := $(addprefix $(FW_BASE)/,$(FW_FILE_2).bin)
BLANKER    := $(addprefix $(SDK_BASE)/,bin/blank.bin)

V ?= $(VERBOSE)
ifeq (“$(V)”,”1″)
Q :=
vecho := @true
else
Q := @
vecho := @echo
endif

vpath %.c $(SRC_DIR)

define compile-objects
$1/%.o: %.c
$(vecho) “CC $$<”
$(Q) $(CC) $(INCDIR) $(MODULE_INCDIR) $(EXTRA_INCDIR) $(SDK_INCDIR) $(CFLAGS)  -c $$< -o $$@
endef

.PHONY: all checkdirs clean

all: checkdirs $(TARGET_OUT) $(FW_FILE_1) $(FW_FILE_2)

$(FW_FILE_1): $(TARGET_OUT)
$(vecho) “FW $@”
$(Q) $(FW_TOOL) -eo $(TARGET_OUT) $(FW_FILE_1_ARGS)

$(FW_FILE_2): $(TARGET_OUT)
$(vecho) “FW $@”
$(Q) $(FW_TOOL) -eo $(TARGET_OUT) $(FW_FILE_2_ARGS)

$(TARGET_OUT): $(APP_AR)
$(vecho) “LD $@”
$(Q) $(LD) -L$(SDK_LIBDIR) $(LD_SCRIPT) $(LDFLAGS) -Wl,–start-group $(LIBS) $(APP_AR) -Wl,–end-group -o $@

$(APP_AR): $(OBJ)
$(vecho) “AR $@”
$(Q) $(AR) cru $@ $^

checkdirs: $(BUILD_DIR) $(FW_BASE)

$(BUILD_DIR):
$(Q) mkdir -p $@

firmware:
$(Q) mkdir -p $@

flash: firmware/0x00000.bin firmware/0x40000.bin
$(PYTHON) $(ESPTOOL) -p $(ESPPORT) write_flash 0x00000 firmware/0x00000.bin 0x3C000 $(BLANKER) 0x40000 firmware/0x40000.bin

blank512k: firmware/0x00000.bin firmware/0x40000.bin
$(PYTHON) $(ESPTOOL) -p $(ESPPORT) write_flash 0x00000 blank/blank512k.bin

test: flash
screen $(ESPPORT) 115200

rebuild: clean all

clean:
$(Q) rm -f $(APP_AR)
$(Q) rm -f $(TARGET_OUT)
$(Q) rm -rf $(BUILD_DIR)
$(Q) rm -rf $(BUILD_BASE)
$(Q) rm -f $(FW_FILE_1)
$(Q) rm -f $(FW_FILE_2)
$(Q) rm -rf $(FW_BASE)

$(foreach bdir,$(BUILD_DIR),$(eval $(call compile-objects,$(bdir))))

Facebooktwitterpinterestlinkedin