vmario/doodle3d-firmware
0
0
Fork 0
mirror of https://github.com/Doodle3D/doodle3d-firmware.git synced 2024-11-13 01:17:56 +01:00
Code Issues Releases Wiki Activity
77723fb000
doodle3d-firmware/TODO.md

14 KiB
Raw Blame History

  • chroma kleur

  • size() mag alleen getallen voor export?

  • fullscreen via osc

  • animata (- lijstje vakantie: spuitbus deo, kortingsbon Bever (tentje kopen?), Schotland pakken, andere tas ohm?) (- issue aanmaken voor clementine:

te doen voor werkend prototype (beta testers)

  • (testen) server logging
  • (testen/verder implementeren) stopknop
  • volgorde chunks (en vaker voorkomen?): elke chunk naar los bestand en op het laatst samenvoegen
  • (client) autopreheat wanneer er een printer aanwezig is
  • (fw) temp gcode pad veranderen naar device-specifiek (i.e. /tmp/UltiFi/ttyACM?/combined.gc)
  • (fw) bij (her)initialisatie printer altijd alle state weggooien (i.e. /dev/UtliFi/ttyACM?)
  • client feedback
    • voor ontwikkeling: debugoverlay
    • vaker op 'print' drukken moet niet kunnen (knop disablen en op basis van polling (isPrinting?) status up-to-date houden) -> maar! de firmware moet geen nieuwe printopdrachten accepteren wanneer er al een print bezig is
    • temperatuurindicatie (alleen wanneer temperatuuruitlezing via api mogelijk is) -> dus ook indicatie van draaiende printserver
  • (misschien?) verticale shape aanpassen
  • preheaten voor het starten van een print
    • (fw) wachten op targettemperatuur - 20 graden (hoe om te gaan met afkoelen?)
    • (client) in config bij temperatuurinstelling: opmerking dat de printer gaat printen vanaf lagere temperatuur (bv. -20)

te den voor final release

  • start/end-codes configureerbaar maken (via los endpoint) (duplicate)
  • printerlijst opvragen
    • data: per printer: {id, path, type}
  • gcode: printer busy rapporteren vanaf moment dat gcode wordt verzameld, niet pas bij begin printen (of gcode verzamelen per remote host?)
  • op wiki over openwrt/osx svn checkout veranderen naar git clone
  • image met alles erin
    • in postinst op kastje: ook wifibox start doen (enable doet dat niet) (ook voor ultifi)
    • firewall net wordt nog niet aangemaakt in 'Y'-mode
  • nadenken over loggen (procedure voor testers hoe ze problemen kunnen rapporteren zodat wij ze kunnen reproduceren)
    • verzamelen+zippen van logread output (of uci system.@system[0].log_file?) + /tmp/wifibox.conf + printserver log
  • na /network/disassociate is wifi uitgeschakeld -> kan geen macadres opvragen -> openap bv. 2x nodig om weer goed macadres te vinden
  • client: netwerkkeuze toevoegen?
  • herstart van uhttpd en reboot uitstellen tot na sturen van response (closure queue in response.lua)
  • consistentie REST API
  • code documenteren
  • codedocs uitwerken naar apidocs
  • optie voor loggen toevoegen aan printmanager
  • AP en client tegelijk (VAP / multi-ssid?)
  • auto-update (zowel package als geheel image; <- kijken hoe luci dat doet)
  • serieel:
  • initscript testen (lijkt vaker dan eens te worden uitgevoerd)
  • printerExists: ook nagaan of basispad ultifi bestaat?

NU MEE BEZIG

lokale notities

TODO (new functionality)

  • fix init script handling as described here: http://wiki.openwrt.org/doc/devel/packages#packaging.a.service
  • implement (automated) test code where possible
    • in 'test' dir next to 'src', with API tests under 'test/www/'
    • www tests check functionality of the test module
    • www tests also provide an interface to run arbitrary get/post requests
    • test path splitting as well
  • document REST API
    • fail/error difference: fail is a valid rq aka 'could not comply', while error is invalid rq or system error
    • modules/functions prefixed with '_' are for internal use
    • rq IDs and endpoint information can be supplied (but it's probably not useful after all)
    • list endpoints+args+CRUD type
    • success/fail/error statuses are justified by drupal api
    • unknown values (e.g. in network info) are either empty or unmentioned fields
  • define a list of REST error codes to be more descriptive for clients (e.g. errortype=system/missing-arg/generic)
  • steps to take regarding versioning/updating
    • versioning scheme
    • create feed location (e.g. www.doodle3d.com/firmware/packages) (see here: http://wiki.openwrt.org/doc/packages#third.party.packages)
    • create opkg (already present in bin/ar71xx/packages as .ipk file)
    • create listing info for package list (checksum, size, etc. ...is this inside the .ipk file?)
    • find a way to add the feed url to opkg.conf (directly in files during image building?)
    • determine how opkg decides what is 'upgradeable'
    • at this point manual updating should be possible, now find out how to implement in lua (execve? or write a minimalistic binding to libopkg?)
    • expose through info API and/or system API; also provide a way (future) to flash a new image
  • generally, for configuration keys, it could be a good idea to use the concept of default values so it's always possible to return to a 'sane default config'
    • use a uci wifibox config to store configuration and a uci wifibox-defaults config as fallback-lookup (which contains a complete default configuration)
    • specify min/max/type/regex for each config key in separate lua file
    • perhaps defaults should be specified together with min/max/type/regex
  • dynamic AP name based on partial MAC (present in default config so it can be overridden and reverted again)
  • require api functions which change state to be invoked as post request
  • can this be modelled like java annotations or c function attributes?
  • otherwise maybe pair each function with _attribs = {…}?
  • add API functions to test network connectivity in steps (any chance(e.g. ~ap)? ifup? hasip? resolve? ping?) to network or test
  • handling requests which need a restart of uhttpd (e.g. network/openap) will probably respond with some kind of 'please check back in a few seconds' response
  • add more config options to package, which should act as defaults for a config file on the system; candidates:
    reconf.WWW_RENAME_NAME, wifihelper.{AP_ADDRESS, AP_NETMASK, (NET)}
    https://github.com/2ion/ini.lua

Ideas / issues to work out

  • add system api module? for check-updates/do-update/etc
  • licensing (also for hardware and firmware) + credits for external code and used ideas (http://www.codinghorror.com/blog/2007/04/pick-a-license-any-license.html)
  • (this is an old todo item from network:available(), might still be relevant at some point) extend netconf interface to support function arguments (as tables) so wifihelper functionality can be integrated but how? idea: pass x_args={arg1="a",arg2="2342"} for component 'x' or: allow alternative for x="y" --> x={action="y", arg1="a", arg2="2342"} in any case, arguments should be put in a new table to pass to the function (since order is undefined it must be an assoc array)
  • perhaps opkg+safeboot could be useful in the update mechanism?
  • add config option to compile sources using luac or add an option to minify the lua code

Bugs

  • in captive portal mode, https is not redirected
  • using iwinfo with interface name 'radio0' yields very little 'info' output while wlan0 works fine. However, sometimes wlan0 disappears (happened after trying to associate with non-existing network)...why?
  • protect dump function against reference loops (see http://lua-users.org/wiki/TableSerialization, json also handles this well)
  • relocatabilty of package (take root prefix into consideration everywhere)
  • openap vanuit assocmode gaf tenminste 1x nil in getMacAddress (daarna niet meer)

Logos

Check http://geon.github.io/Programming/2012/04/25/ascii-art-signatures-in-the-wild/ for inspiration.

  D o o d l e 3 D
 --------      ____     .---  v 1.0.1
|  |  |  | __ |  __|.--.| ._| .---..-.-.
|  |  |  ||--||  _| |--||  . || . |\   /
|________||__||__|  |__||____||___|/_._\


  D o o d l e 3 D
 --------     ____   .----  v 1.0.1
|  |  |  |--.|  __|-.|  ._|---.-.-.
|  |  |  |--||  _|--||  . | . |_ _/
|________|__||__||__||____|___|_._\


....D o o d l e 3 D
...________     _____  _____  v 1.0.1 
../  /  /  |__ /  __/ /  - /___ __
./  '  '  /--//  _|-//  - | . /v /
/________/__//__/__//____/___/_^_\

CONFIG KEYS overzicht (wel/niet in firmware opgenomen)

--[[ hop=0 ? minScale=.3 ? maxScale=1 shape=% -- one of: / | \ # $ % ^ * ? twists=0 ?? debug=false ?? loglevel=2 ? zOffset=0

  • server.port=8888 autoLoadImage=hand.txt loadOffset=0,0 showWarmUp=true loopAlways=false useSubpathColors=false maxObjectHeight=150 maxScaleDifference=.1 frameRate=60 quitOnEscape=true screenToMillimeterScale=.3 targetTemperature=230 side.is3D=true side.visible=true side.bounds=900,210,131,390 side.border=880,169,2,471 checkTemperatureInterval=3 autoWarmUpDelay=3 ]]--

voor volgende keer

  • Greenhopper (Atlassian)? (en JIRA?)
  • toch anders plannen, meer rekening houden met onvoorspelbaarheden (aka subtaken)
    • zie de 2 dagen voor geplande betarelease…dat lukte niet omdat er meer mankracht nodig was, veel dingen extra tijd kostten (bv gcode maken en sercomm), en eindeloos veel kleine 'hejadatmoetooknogeven'-dingen (die in de 'x2' van de planning moeten vallen maar eerder 'x5' oid lijken)…en dan nog blijft het documenteren liggen
  • te weinig gedaan: daily standups -> planning aanpassen
  • meer continuïteit nodig?
  • meer tijd…
  • duidelijker kunnen volgen wat gepland is en wat echt gebeurd (icm met standups)