1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
|
:document: Handover Report
include::share/meta.adoc[]
== Introduction
This is an informal document that summarizes how the 23-24 run of this project
went. We found the previous handover documents to be unhelpful when determining
the 'actual' state of the project in the first few weeks, and felt they did not
address the pitfalls of this project.
== Incidents
== Project History
=== 19-20
.19-20 group composition
[%autowidth]
|===
| Name | Study path
| Daniël Janssen | Software
| Dion Legierse | Software
| Jop van Laanen | Hardware
| Max van den Heijkant | Software
|===
=== 20-21
.20-21 group composition
[%autowidth]
|===
| Name | Study path
| Joost van Wiechen | Hardware
| Justin Maas | Software
| [[pn:creemers,Merel Creemers]]Merel Creemers | Hardware{empty}footnote:[The
handover report from 20-21 mentions: _"Het frame zelf is niet gelukt om te
realiseren, omdat er communicatie tussen het projectgroep en de CMD-student uit
het niets is verdwenen"_. <<pn:creemers>> was introduced as a hardware-student
in the project plan, but is no longer mentioned in the handover report, which
may indicate that they were removed from the project group. I am unsure if they
were a hardware student that worked on the PCBs or a CMD student working on the
puzzle box chassis.]
| Vincent Lengowski | Hardware
|===
=== 21-22
.21-22 group composition
[%autowidth]
|===
| Name | Study path
| Alex van Kuijk | Hardware
| Jef Baars | Software
| Julian de Bruin | Software
| Lucas van Gastel | Software
| Toon Rockx | Hardware
|===
=== 22-23
.22-23 group composition
[%autowidth]
|===
| Name | Study path
| Frank Bekema | Hardware
| Jasper Gense | Hardware
|===
=== 23-24 (current)
.23-24 group composition
[%autowidth]
|===
| Name | Study path
| Elwin Hammer | Software
| [[pn:faase,Lars Faase]]Lars Faase{empty}footnote:[<<pn:faase>> was removed
from the project group on 2024-06-03 following complaints about the lack of
communication.] | Software
| [[pn:blansch,Loek Le Blansch]]Loek Le Blansch | Software
| Thomas in 't Anker | Software
|===
== Resources
Previous years' groups have put their predecessor's documents inside their own
project folder, which has resulted in what we called the 'Russian doll folder
structure'. <<pn:blansch>> has separated out each year's project folder
('master file'), and is hosting these on
<https://media.pipeframe.xyz/puzzlebox>. This directory is also mountable as a
read-only WebDAV share on Windows, MacOS and Linux (using davfs2), and does not
require credentials to log in. Please note that this is very much unofficial,
and is not managed or endorsed by Avans. <<pn:blansch>> is the contact for
removal or transfer of these files.
== Recommendations
- The 22-23 design document already mentions that the application of the I^2^C
bus is in a multi-master configuration, but does not mention that this only
works when pull-up resistors are used on the SCL and SDA lines. The pull-up
resistors are required, as omitting them makes the bus arbitration process
very inconsistent which causes frames to be dropped entirely.
include::share/footer.adoc[]
:document: Handover
include::share/meta.adoc[]
== A Note Before Reading
The team of year 2023-2024 consisted of only software students, meaning no
hardware was developed in this year. We were tasked with simplifying the
software to the point where it would only have to be ported into the new hardware,
which was designed in the year 2022-2023. The goal of this year would be to create
a software framework which can be used to implement new puzzles and to make the
development process of these puzzles easier.
At the moment of writing, the documentation of previous years can be found at the
following link: 'https://media.pipeframe.xyz/puzzlebox'.
== Project State
The current project state is as follows: No new hardware has been designed
or developed this year. The software was completely revised, now consisting of a
a puzzle bus driver, a main controller, a simple CLI application, and two puzzle
modules. Namely the puzzle modules 'Vault' and 'Neotrellis', both using an arduino
as the controller. The main controller (a RPI Pico W) can interact with the
different puzzle modules using an I^2^C bus. The I^2^C bus has been configured to
be a multi-master I^2^C bus. allowing the puzzle modules and the main controller
to send and recieve messages on their own. The main controller is able to find
new puzzle modules on startup, and does not check for new modules afterwards. A
simple CLI application has been developed, which can communicate with the main
controller through a tcp connection and simple commands.
In short: A puzzle bus driver has been implemented, to allow for communication
between the main controller and the puzzle modules. A CLI application was developed
which connects with the main controller to monitor/edit the gamestate. And the
software for the puzzle modules 'Vault' and 'Neotrellis' is in the product state.
The hardware design can be derived from the year 2022-2023, and you can derive the
game rules from the year 2020-2021.
== Challenges
There were a multitude of different challenges we had to face before getting to a
working product. Most of these have been documented here, and it is highly recommended
to have a look at this before development.
=== Misconceptions
Make sure to know what you are developing and do some research beforehand, to make
sure you have the complete picture about what you are using. Sounds stupid, but it
happened for multiple project attempts, and cause time-loss. This also includes
documentation of previous years: go through the documentation and verify it on the
lowest possible level for the same reason as previously mentioned.
=== I^2^C
I^2^C is easy to implement but also easy to underestimate, this project requires a
multi-master structure as communication is otherwise too complicated compared to
other means of communication.
For I^2^C on hardware level: make sure to use pull-up resistors, 2k2 if bus is on
100khz, as it is otherwise impossible to use I^2^C due to incorrect messages. This
is also recommended for controllers which are connected to the I^2^C bus. Make sure
to use I^2^C arbitration to check if the bus is not busy when writing to it, as
this will result in complictions in the communication.
The RPI Pico W (RP2040) does not support multi-master to the point of being able to
receive messages from other multi-masters as a slave while being configured as master.
Everything else about the I^2^C bus works, but due to this limitation a workaround has
been implemented to be able to continue using the RPI Pico W. Under ideal circumstances
a different controller could be found which does support this, but one was not found at
the time of writing. To simplify; a controller is needed which supports multi-master
while being able to be addressed as a slave-type controller.
=== Available Hardware/SDKs
When choosing or using specific chips/sdks make sure it is available for (at least)
a few years. This makes it easier for the next project team to use the same chips/sdks
instead of having to find new ones because the previous project team did not think about
this possibility. This also includes having enough sdks for multiple people to program
using the same setup, eg. the RPI Pico W requires another RPI Pico W to be debugged.
Effectively requiring the project team to have at least 4 RPI Pico Ws to be able to develop
in the same environment (if there are 2 software students).
=== Arduino
Allocating memory using 'realloc' on arduino is not possible, which also denies usage of
the 'mpack_writer_init_growable'
== Imperatives
* Start creating prototypes as fast as possible, this benefits the project in the long run,
as you have already shown that certain parts of the project are already working and only
need to be integrated.
* The Atmega328P-chip is sufficient for the puzzle modules as it has enough IO and I^2^C
connectivity possibilities.
* The RPI Pico W has programmable IO modules, making it possible to create an I^2^C driver
that allows multi-master communication while still being addressable as a slave.
include::share/footer.adoc[]
|