Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Large commit, semiworking state, Driver C->OCaml
This commit represents a lot of work which went into rewriting the driver in OCaml. Unfortunately I did not commit during this port but hopefully this won't cause any problems in the short and long run. Summary/Observations: - The directory is now divided into bin/ for the executable and lib/ for the library. This has the advantage that one can now test the library interactively via "dune utop lib" (and then open Epd in utop). Furthermore this should smooth the way to creating an opam package which can then be used in multiple different programs (terminal, vnc server, graphics driver, ebookreader, etc.). The scope and feasability of these programs will be determined later, for now we are stuck with a terminal and use it for everything (via curses or other programs) - The 5 layers of which the library consists have been ported with the exception of the lowest level. The levels are, from lowest to highest: * bcm: Interacting with the bus (Transmitting values) * IT8951: Interacting with the IT8951 controller (Transmitting instructions) * cmd: Stringing those commands together to achieve complex behaviour. Here we finally have an effect on the display. This could perhaps be merged with the IT8951 layer because they both represent interaction on roughly the same level. Some of the features of cmd are simply single commands and therefore the distinction is not as clear. * interface: Another well chosen name. This layer implements even more complex behaviour but is actually quite simple and can most likely be absorbed in both the layers above and below. Currently it handles the initialisation of the board, reading details about the IT8951 and the screen, creating the initial buffer, transmitting it and displaying it. Essentially it provides an abstract interface: display areas, draw points and text (only points work currently). It does therefore not provide any important functionality itself and handles things in a probably too complex manner (which is a relic of the original driver). * EPD: Essentially the same as interface. Should originally reimplement the graphics library from the OCaml stdlib but as that is hardly useful for anything serious this has been abandoned. - Horrible performance: The program is about 2 times slower than the C version which is most likely the result of the interface layer and its handling of the images. As of now I'm not all that certain exactly what must be transmitted and as that is the limiting factor in regards to speed this will be investigated soon. The original driver was built around having multiple buffers which can be loaded onto the driver board. This most likely eased the drawing of images (as can be seen in the original driver code). As this is no longer the focus of the driver and not idiomatic for OCaml this could perhaps be changed to a single buffer which contains everything drawn. Then the interface layer would only provide a display area function which actually transmitted the buffer and displayed it. Another cause for this issue could be that utop does not compile the code but interpret it and is therefore significantly slower. Should not be as relevant on this IO bound task Perhaps the distinction between transmitting and displaying is worthwhile preserving but I personally doubt it as it would save, in the worst case, a single transmission of the whole buffer at small but not negligible overhead when writing any code. Most likely these issues will resolve once the bus usage has been cut down to the minimum. - Unclear and inconsistent naming: Across the modules exist 3 load_image variations, additionally to load_image_start/end, multiple display variants, multiple inits etc. Exactly what each layer achieves is not obvious from the name alone. - Port the lowest layer to WiringPi or create own library for the pins.
- Loading branch information