CMakeLists and Readme updates.

This version of the cmakelists includes a hal directory, but i haven't
yet figured out how to make that work, so this is fairly broken.

README.md

@@ -24,7 +24,55 @@ fun stuff, but blinking LEDs is pretty good.
 
 Thus, we need FastLED.
 
-# The other FastLED-idf
+# Use of ESP32 hardware
+
+The ESP32 has an interesting module, called RMT. It's a module that's
+meant to make arbitrary waveforms on pins, without having to bang each pin at
+the right time. While it was made for IR Remote Control devices, 
+it works great for LEDs, and appears to be better than the PWM hardware.
+
+There are 8 channels, which tends to match well with the the desires of most
+people for LED control. 8 channels is basically still a ton of LEDs, even
+if the FastLED ESP32 module is even fancier and multiplexes the use of these
+channels.
+
+The FastLED ESP32 RMT use has two modes: one which uses the "driver", and
+one which doesn't, and claims to be more efficient due to when it's converting
+between LED RGB and not.
+
+Whether you can use the "direct" mode or not depends on whether you have other
+users of the RMT driver within ESP-IDF. 
+
+Essentially, if you have the Driver turned on, you shouldn't use the direct mode,
+and if you want to use the direct mode, you should turn off the driver.
+
+TODO: insert specific information about turning these things on and off in `menuconfig`
+
+# A bit about esp-idf
+
+ESP-IDF, in its new 4.0 incarnation, has moved entirely to a cmake infrastructure.
+It creates a couple of key files at every level: `CMakeLists.txt` , `Kconfig`. 
+
+The `CMakeLists.txt` is where elements like which directories have source and includes live.
+Essentially, these define your projects.
+
+The `Kconfig` files allow you to create variables that show up in MenuConfig. When you're building
+a new project, what you do is run `idf.py menuconfig` and that allows you to set key variables,
+like whether you want to bit-bang or use optimized hardware, which cores to run on, etc.
+
+One element of esp-idf that took a while to cotton onto is that it doesn't build a single binary
+then you build your program and link against it. Since there are so many interdependancies -
+it's an RTOS, right - what really happens is when you build your code, you build everything
+in the standard set too. This means compiles are really long because you're
+rebuilding the entire system every time.
+
+There's no way to remove components you're not using. Don't want to compile in HTTPS server? Tough.
+The menuconfig system allows you to not run it, but you can't not compile it without
+going in and doing surgery.
+
+# History 
+
+## The other FastLED-idf
 
 It appears that set of code was an earlier version of FastLED, 
 and probably only still works with ESP-IDF 3.x. There was a major
@@ -36,7 +84,7 @@ Thus, updating both, and using eskrab's version as a template,
 I attempt to have a running version of FastLED with the ESP-IDF
 4.0 development environment
 
-# ESP-IDF already has a LED library
+## ESP-IDF already has a LED library
 
 Yes, I saw it once, I'm having trouble finding it now. It does
 really cool timing tricks, but it's not got all the fancy-fancy
@@ -44,3 +92,48 @@ of the FastLED library, which has a better designed and time tested
 programming interface. I reached out on the Espressif forum to the
 company and suggested they support FastLED ( why not? it's open source! )
 and they told me to get lost.
+
+# Updating
+
+This package basically depends on three packages: two that you pull in,
+and the fact that you've got to use the version that works with your intended version
+of esp-idf. Those two packages are FastLED, and also arduino-esp32, since FastLED is
+using the arduino interfaces.
+
+It would have been possible to just have at the FastLED code and nuke the portions
+that are Arduino-ish, however, that removes the obvious benefit of eventually
+being able to update FastLED.
+
+As a starting point, then I've taken the choice of keeping the libraries as unmodified
+as possible.
+
+## FastLED
+
+Drop this into the FastLED-idf directory. Now, it might have been cleaner to create a subdirectory
+with nothing but the FastLED-sourced code, this could be an organizational change the future.
+
+## Arduino-esp32
+
+You need a few of the HAL files. Please update these in the subdirectory hal.
+
+# Gotchas and Todos
+
+## ESP32 define
+
+I banged my head for a few hours on how to define ESP32, which is needed by FastLED to choose
+its platform. This should be doable in the CMakeLists.txt, but when I followed the instructions,
+I got an error about the command not being scriptable. Thus, to move things along, I define-ed
+at the top of the FastLED.h file.
+
+Someone please fix that
+
+## lots of make threads makes dev hard
+
+It seems `idf.py build` uses cores+2. That means when you're actually building your component, you're in line with
+all the other esp idf components, and you'll see a lot of stuff compile then finally what you want.
+
+The best way is to do a few builds - which will all fail, and the other components without errors ( the ones in esp-idf )
+will finally get built, then you'll be left with only your errors.
+
+Building without `-j` parallelism would be nice, but I haven't found a way to do that. And, it would be slow.
+

components/FastLED-idf/CMakeLists.txt

@@ -11,9 +11,10 @@ set(srcs
 		"platforms.cpp"
 		"power_mgt.cpp"
 		"wiring.cpp")
+
 # everything needs the ESP32 flag, not sure why this won't work
 # going to hack by adding the ESP32 define in the h file
 	#`target_compile_options(${COMPONENT_LIB} PRIVATE "-DESP32")
 
 idf_component_register(SRCS "${srcs}"
-			INCLUDE_DIRS "." )
+			INCLUDE_DIRS "." "./hal" )