The next round of test work #3486
Conversation
The NTest tests take a lot of RAM if we just run them there. So instead, push them into LFS to give us some more wiggle room.
Will use this to set RCRs and such as part of the test environment run
Notably, move updated wiring description to README and remove it from HardwareTestHarness
|
|
||
| -- Determine if a given Lua module is available for require-ing. | ||
| function NTE.hasL(m) | ||
| for _, l in ipairs(package.loaders) do |
There was a problem hiding this comment.
Ah, I see the difference. Your method will also find modules in SPIFFS.
But will it not load all available modules, that way exhausting memory if SPIFFS is not cleaned out?
But I am no expert in loaders.
| -- Determine if the firmware has been built with a given module | ||
| function NTE.hasC(m) | ||
| -- this isn't great, but it's what we've got | ||
| local mstr = node.info('build_config').modules |
There was a problem hiding this comment.
you could also just check if the name is available in the root namespace (and is a rom table maybe)
| end | ||
|
|
||
| -- Determine if a given Lua module is available for require-ing. | ||
| function NTE.hasL(m) |
There was a problem hiding this comment.
I'd prefer hasLua. On a host system (with more memory) I would even call it hasLuaModule
|
|
||
| -- Look up one (or more) feature keys in our configuration file, | ||
| -- returning the associated value (or a map from keys to values). | ||
| function NTE.getFeat(...) |
There was a problem hiding this comment.
How about getFeatures. The plural indicates that several params can be given at once
|
|
||
| local cstr | ||
| repeat | ||
| cstr = cfgf:read(); decoder:write(cstr or "") |
There was a problem hiding this comment.
Does it make sense to have smaller chunks than the default 1024 bytes?
Should we call an explicit garbage collect from time to time?
| assert (type(givenFeats) == "table", "Malformed configuration file") | ||
|
|
||
| local res = {} | ||
| for _, v in ipairs(reqFeats) do |
There was a problem hiding this comment.
Maybe this should be done only on request.
I imagine a test that behaves differently on existence of a feature.
Maybe have on of
- a separate function that errors on missing features
- a parameter that steers the behavior
- a separate function that is called with the result of
getFeatand the list of required features to error out
| if #p > 1 then return true end -- something we're keeping | ||
| if #p == 0 then return true end -- root table | ||
| local thisFeat = p[1] | ||
| assert (type(thisFeat) == "string") |
There was a problem hiding this comment.
not sure about json syntax but are there other keys than strings allowed?
w3schools states: "In JSON, keys must be strings, written with double quotes"
so this check can be removed
| -- Ensure that we're on DUT 0 | ||
| assert(NTE.getFeat('DUT') == 0, "Not on DUT 0") | ||
|
|
||
| -- Configure the ADC (this implicitly checks for having the ADC module) |
There was a problem hiding this comment.
Early checks with distinct error message are a nice thing to have. So since we now have respective methods we should use them. Maybe even have such checks for basic modules as sjson before using them in NTestEnv
| if adc.force_init_mode(adc.INIT_ADC) | ||
| then | ||
| node.restart() | ||
| error "Must reboot to get to ADC mode" | ||
| end | ||
|
|
||
| -- Configure the I2C bus | ||
| -- Configure the I2C bus (again, implicitly testing...) |
| #### DHTxx | ||
|
|
||
| On DUT1 pin D6/GPIO 12 there is a connection to a position for a DHTxx device. The silk screen indicates the | ||
| orientation of the device. | ||
|
|
||
| Note: Not yet used in the test harness. |
There was a problem hiding this comment.
you mean the software test harness? This is the documentation of the HWTH
| Note: Not yet used in the test harness. | ||
|
|
||
| Note: It would make sense to augment the 1-Wire testing facility to | ||
| include bus-drive power, perhaps via the MCP23017, especially if we ever |
There was a problem hiding this comment.
As states above there are already 2 devices possible, one without VCC connected which then would be bus-driven
| #### DS18B20 | ||
|
|
||
| There are two positions for DS18B20s -- one with the VCC pin connected and one without. The data pin is | ||
| connected to DUT1 pin D5/GPIO 14. | ||
|
|
||
| Note: Not yet used in the test harness. |
There was a problem hiding this comment.
meaning no tests available yet?
| ---------|-------------------------------------------------------------- | ||
| /RESET |DUT0 reset. This resets the chip whenever the host computer resets DUT 0 over its serial link (using DTR/RTS). | ||
| B 0 |4K7 resistor to DUT 0 ADC. | ||
| B 1 |2K2 resistor to DUT 0 ADC. |
There was a problem hiding this comment.
again B2,3 and 4 are not described in the readme
|
|
||
|
|
||
| ESP8266 Device 0 Connections | ||
| ---------------------------- |
There was a problem hiding this comment.
The description here is more exact and exceeds the spec in the readme, so it should be kept.
e.g.; D4/5 of DUT 1 is not described at all.
Also in general the setup might evolve in the readme but this document describes a hardware version, which will remain unchanged (else it will be a v2)
devbranch rather than for thereleasebranch.Here's a slice through the test framework I've had in my back pocket. Of importance:
NTestEnvmodule (and associated file in SPIFFS); this will let us flexibly extend the notion of "test environment" without requiring that everything move in lockstep.tests/all.sh) shows how the whole thing hangs togetherThoughts more than welcome.