I am a student from Germany, who is primary a software dev, but very interested in FPGA design and hardware in general.
- User Since
- Jul 25 2017, 2:45 PM (77 w, 2 d)
- Nickname on IRC
Sep 3 2018
Do you have foto-documentation of the build process online? And/or footage?
I would love to see your 3d prints and early assembly's :)
Aug 15 2018
Some updates on this front:
Last ccc @vup @leftshift and me decided to build a cheap development version of the Beta.
We wanted to have a cheap camera to be able to develop soft- and hardware for the Beta without the need to invest a lot of money.
Research was done, the cheapest Zynq FPGA development board was found, the cheapest suitable CMOS with okayish documentation was picked and we designed a first Interface PCB to connect the sensor to the FPGA dev board. We build FPGA designs and wrote some software and in the end we had the first still images. The first prototype of the AXIOM micro was built.
However, the initial PCB was quite rough and had major problems (we were doing serious PCB design for the first time in our lives).
This led us to the creation of a second revision, which now is able to shoot moving images, has a proper lens mount and some case.
Mar 11 2018
we could also have multiple clients... ie. one webremote and one cli (in case we are merging the server and the controldaemon).
sorry for being unclear. When writing rest server, i actually didnt think about rest but exposing an interface with webstandarts. we could also replace any rest with websockets.
hm... dont really get, why we would want to disable the rest server / the control daemon seperately. if we dont want to expose http from outside, we could pervent this by binding the rest server to a local adress and do reverse proxying with ligthttpd. in this case disabeling lighttpd would disable the accessibility from outside.
moreover, what is the transport mechanism for the flatbuffers? notwork? unix sockets? files? fifos?
why do we split the control daemon and rest server into two different programs? couldnt the contol daemon directly expose some kind of web compatible api (websockets / rest), the webapp and the cli should use?
Feb 27 2018
maybe move this to the OC git repo, which would make it more likely to be foud by people who want to contribute?
many thanks :)
now, can we finally make this new structure a bit more clear for people coming from github? this would be quite nice. maybe making it clear by putting a readme inside the hardware repo which links to the fileserver and/or to the wiki and clarifies what should go into git and what belongs to the fileserver.
Feb 21 2018
503 is not forbidden but service temporarily not available. maybe gitlab has a temproary outage (they sometimes do ;))
Feb 20 2018
There are some things, that are good to consider, when we build something like this:
- The camera has plenty of resources. When designing something that only works on the parameters, and not on any image data it is almost impossible to design a system that is to imperformant to run on the cam. This means no performance optimisation is needed.
- The software has to work without requiring internet access at all. (in my opinion) I think it would be handy if everything is served from the camera.
- The software should manage the state of the hardware (is the fpga configured? what bitstream should be loaded? what bitstream is loaded? what plugin modules are plugged in?
- New Plugin Modules should be easy to integrate (new bitstrams and new parameter space)
- An open API should be exposed to allow other interfaces (maybe hardware) to be easily developed
Feb 19 2018
As far as the my.apertus.org idea is concerned, it might be worth looking into a scheme that serves unique / registered apertus hostnames on a subdomain with the cert being held on the device.
Yeah you are completely right! Axiom Firmware would be a much better name!
Moreover, I quite like the idea of having repos for each topic (like gateware, web-gui, daemon, configs, ...)
All the PHP is still from the axiom alpha and will be deprecated in favour of the new REST api. (correct me if Im wrong).
Some of your suggestions are already taken care of in the next-gen firmware on github (ie. lighttpd not having sudo rights)
Sounds cool :).
I think we dont need to optimize for speed so caching is not really important (for now).
i think aes256 would be much more practical to use. with otp one would need to store twice the data, which is not very practical in terms of bandwidth and storage price.
Moreover, when crossing borders with footage, one would most likely carry both storage mediums (the footage and the key), which would make the encryption useless. when using aes, we could encrypt the key with a password and therefore keep the footage secure, even if all the storage mediums are confiscated.
Feb 2 2018
what about checkboxes? they can be styled with css, so they look like toggle switches: https://codepen.io/mburnette/pen/LxNxNg
Jan 1 2018
can we make this behaviour default for the nowiki snippets?
another example: https://wiki.apertus.org/index.php/Beta_Power_Board#Calibrating-Voltages
I think, that <nowiki></nowiki> should preserve newlines
I think that having a single point of information is quite valuable. I like the idea of having the code/the design files in the same file tree as the docs, but having the WIki as the only central point is fine for me, too.
Maybe readthedocs would be a better tool choice, because it can create beautiful PDFs, but it can also be viewed and searched online. Moreover, it has a lower entry barrier for contributes. What do you think?
Dec 8 2017
Nov 18 2017
I think, I won't manage to be there for a long time but im happy to join you for some time. Especially if you have a Beta ;)
Error at line 79, file devmem2.c (13) [Permission denied]
Nov 17 2017
I will be there too :)
Nov 5 2017
Closed in favour of T757. If this is wrong, just reopen this task.
reference and close?
So close the other two tasks?
Can this be closed?
I think a ubuntu docker container with the required tools installed would be simple to create (this is the current solution for the ci-builds). However, I think, that distributing xilinx tools implys some licensing and export-control related issues. The simplest way to deal with them would be to just ignore those or make the container somehow protected.
When T697 is finished
The original task is done. The mentioned binaries are linked to /user/local/bin as axiom-* by make install
Nov 3 2017
@sebastian could you please remove the URL, as it shouldnt be public ;)
Nov 2 2017
Yes! Just now i created this (https://github.com/apertus-open-source-cinema/beta-software/pull/7) pull Request. If you want to bring the work on this forwards, you could test this (https://gitlab.com/nein/beta-software/-/jobs/38788789/artifacts/download) image and report your findings. edit: bertl is already doing this.
Nov 1 2017
Oct 28 2017
Aug 14 2017
I began to do this with your help...
Jul 25 2017
at this point of time this would be some more work. because the gitlab is only a mirror of GitHub, the repo doesn't need any maintenance, so I would vote for keeping the gitlab account a "person".
The beta-software is now mirrored to https://gitlab.com/apertus/beta-hardware. Wen somebody who's more into building the software manually could write a .gitlab-ci.yml and add it to the GitHub repository the builds would start automatically on every commit.
gitlab ci is indeed a good idea :). the mirroring from github is also possible in the public instance but very bugy. to work around this we can create another repository with gitlab ci, which only pulls from github and pushes to gitlab, and is triggered by a github webhook. I did exactly this setup for another project and it works very well...
(https://github.com/freifunkks/site-ffks/tree/beta) the mirror repo can be found here: https://gitlab.com/freifunkks/mirror-scripts
I think travis wouldn't be the optimal solutions for firmware builds, because we need some special tools with proprietary licenses for building the fpga bitstreams and more build time than the 50 minutes travis gives you for free. Imo http://concourse.ci would be a good solution, because it would allow us to create quite modular pipelines for the firmware.