From d38d1f7abd1b91b216172f1d356cec2124e62fac Mon Sep 17 00:00:00 2001 From: ThomasintAnker Date: Fri, 21 Jun 2024 15:03:06 +0200 Subject: WIP Added puzzle module i2c research --- docs/share/refs.bib | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'docs/share') diff --git a/docs/share/refs.bib b/docs/share/refs.bib index b6fe625..0af5f94 100644 --- a/docs/share/refs.bib +++ b/docs/share/refs.bib @@ -192,3 +192,22 @@ publisher = {Avans University of Applied Sciences}, year = {2022}, } + +@online{Joh21, + author = {Johnston, P.}, + title = {Embedded systems testing resources}, + url = {https://embeddedartistry.com/blog/2018/10/18/embedded-systems-testing-resources/}, + month = jun, + msbib-day = {10}, + msbib-accessed = {2024-02-25}, + year = {2021}, +} + +@online{RPI23, + title = {Hardware APIs - Hardware I2C}, + url = {https://www.raspberrypi.com/documentation/pico-sdk/hardware.html#hardware_i2c}, + month = jun, + msbib-day = {14}, + year = {2023}, + msbib-accessed = {2024-05-11}, +} -- cgit v1.2.3 From 8bd40843cbaafd82e11d897fe210c0975b5bd73c Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Fri, 21 Jun 2024 15:43:00 +0200 Subject: add disclaimers --- .editorconfig | 2 +- docs/design.adoc | 8 +++++++- docs/handover.adoc | 11 ++++++----- docs/reqs.adoc | 40 ++++++++++++++++++++-------------------- docs/research.adoc | 19 +++++++++++++++---- docs/share/refs.bib | 8 ++++++++ docs/theme.yml | 8 ++++++++ 7 files changed, 65 insertions(+), 31 deletions(-) (limited to 'docs/share') diff --git a/.editorconfig b/.editorconfig index cd37156..bd1f474 100644 --- a/.editorconfig +++ b/.editorconfig @@ -5,7 +5,7 @@ indent_style = tab end_of_line = lf insert_final_newline = true -[*.md] +[*.{md,yml}] indent_style = space indent_size = 2 diff --git a/docs/design.adoc b/docs/design.adoc index 6a52b38..06cd100 100644 --- a/docs/design.adoc +++ b/docs/design.adoc @@ -146,7 +146,13 @@ The criteria for the main controller are: The requirements document compares various microcontrollers that fit these criteria. After this comparison, the decision was made to utilize the Raspberry Pi Pico W as main controller during development. -// TODO: this was a bad choice + +NOTE: This was written while we did not know the puzzle bus specifically +requires slave-addressible I^2^C multi-master controllers to function properly. +While the research concludes the RP2040 is a suitable microcontroller for the +main controller, it is not. The RP2040 was still used, but has required +implementing workarounds. Please see the handover report for more details on +how this impacted the project cite:[handover]. [[fig:main-controller-top]] .Main controller top-level block diagram diff --git a/docs/handover.adoc b/docs/handover.adoc index 6918256..77d5da0 100644 --- a/docs/handover.adoc +++ b/docs/handover.adoc @@ -29,16 +29,17 @@ removal or transfer of these files. [[tab:proj-comp]] .Project group composition +[cols="15,35,20",width=55%] |=== | Year | Name | Study path -.4+| 19-20 +.4+h| 19-20 | Daniël Janssen | Software | Dion Legierse | Software | Jop van Laanen | Hardware | Max van den Heijkant | Software -.4+| 20-21 +.4+h| 20-21 | Joost van Wiechen | Hardware | Justin Maas | Software | [[pn:creemers,Merel Creemers]]Merel Creemers | Hardware{empty}footnote:[The @@ -51,18 +52,18 @@ were a hardware student that worked on the PCBs or a CMD student working on the puzzle box chassis.] | Vincent Lengowski | Hardware -.5+| 21-22 +.5+h| 21-22 | Alex van Kuijk | Hardware | Jef Baars | Software | Julian de Bruin | Software | Lucas van Gastel | Software | Toon Rockx | Hardware -.2+| 22-23 +.2+h| 22-23 | Frank Bekema | Hardware | Jasper Gense | Hardware -.4+| 23-24 +.4+h| 23-24 | Elwin Hammer | Software | [[pn:faase,Lars Faase]]Lars Faase{empty}footnote:[<> was removed from the project group on 2024-06-03 following complaints about the lack of diff --git a/docs/reqs.adoc b/docs/reqs.adoc index 8ad24a8..611c8f3 100644 --- a/docs/reqs.adoc +++ b/docs/reqs.adoc @@ -108,7 +108,7 @@ describes all functional requirements of the puzzle box. === The puzzle box .Puzzle box specifications -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -165,7 +165,7 @@ describes all functional requirements of the puzzle box. === The bomb .Bomb specifications -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -198,7 +198,7 @@ describes all functional requirements of the puzzle box. === The game .General game specifications -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -239,7 +239,7 @@ describes all functional requirements of the puzzle box. ==== NeoTrellis puzzle .NeoTrellis puzzle requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -262,7 +262,7 @@ describes all functional requirements of the puzzle box. ==== Software puzzle .Software puzzle requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -297,7 +297,7 @@ The specific details for this puzzle are not present in the previous documentation. Due to time constraints, the section will be left empty. .Automation puzzle requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -308,7 +308,7 @@ documentation. Due to time constraints, the section will be left empty. ==== Hardware puzzle .Hardware puzzle requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -397,7 +397,7 @@ documentation. Due to time constraints, the section will be left empty. ==== Vault puzzle .Vault puzzle requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -447,7 +447,7 @@ documentation. Due to time constraints, the section will be left empty. === Battery .Battery requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -464,7 +464,7 @@ documentation. Due to time constraints, the section will be left empty. === Network Communication .Communication requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -477,7 +477,7 @@ documentation. Due to time constraints, the section will be left empty. === Framework -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -497,7 +497,7 @@ documentation. Due to time constraints, the section will be left empty. === Puzzle box hub .Puzzle box hub general requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -516,7 +516,7 @@ technical specifications of the puzzle box. === Wireless communication .Wireless communication requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -527,7 +527,7 @@ technical specifications of the puzzle box. === Framework .Development framework requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -550,7 +550,7 @@ technical specifications of the puzzle box. === Main controller .Main controller requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -575,7 +575,7 @@ technical specifications of the puzzle box. === Puzzle module controller -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -601,7 +601,7 @@ technical specifications of the puzzle box. === Vault puzzle .Vault puzzle requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -627,7 +627,7 @@ technical specifications of the puzzle box. === Bomb .Bomb requirements -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification @@ -650,7 +650,7 @@ This section describes the aspects of the project which have been set as preconditions and cannot be changed. .Preconditions -[cols="8h,~"] +[cols="9h,~"] |=== | ID | Precondition @@ -666,7 +666,7 @@ preconditions and cannot be changed. This section lists requirements that apply to documentation produced during this project. -[cols="8h,5h,~"] +[cols="9h,6h,~"] |=== | ID | <> | Specification diff --git a/docs/research.adoc b/docs/research.adoc index 753206c..acab4ab 100644 --- a/docs/research.adoc +++ b/docs/research.adoc @@ -143,6 +143,13 @@ than the other options. It also happens to be less expensive than all other options. Due to these reasons, the RP2040 was chosen as main controller MCU. The Raspberry Pi Pico W board is utilized during development. +NOTE: This was written while we did not know the puzzle bus specifically +requires slave-addressible I^2^C multi-master controllers to function properly. +While the research concludes the RP2040 is a suitable microcontroller for the +main controller, it is not. The RP2040 was still used, but has required +implementing workarounds. Please see the handover report for more details on +how this impacted the project cite:[handover]. + [[tab:main-mcu]] .Main controller MCU candidates [%autowidth] @@ -173,10 +180,10 @@ manufacturers: Atmel, STMicroelectronics, Raspberry Pi. All the MCUs listed in <> support some version of a low-power mode. The RP2040 is again included and appears here because it supports clock speed -configuration and has a clock gate for each peripheral [2], which may make it a -feasible option with regards to power consumption. Choosing the RP2040 may also -simplify the development process as only a single MCU toolchain needs to be -maintained. +configuration and has a clock gate for each peripheral cite:[rp2040ds], which +may make it a feasible option with regards to power consumption. Choosing the +RP2040 may also simplify the development process as only a single MCU toolchain +needs to be maintained. The Microchip PIC16F15276 is the most power efficient on this list and is the recommended MCU for puzzle modules. It supports both extreme underclocking and @@ -187,6 +194,10 @@ Because this year's run of this project was carried out by a team consisting only of software students, this choice remains as a recommendation. The puzzle box hardware may still use the ESP32 development kits from the 21-22 group. +NOTE: This was written while we did not know the puzzle bus specifically +requires slave-addressible I^2^C multi-master controllers to function properly. +We have not verified if the PIC16F15276 supports this feature. + [[tab:pm-mcu]] .Puzzle module controller MCU candidates [%autowidth] diff --git a/docs/share/refs.bib b/docs/share/refs.bib index b6fe625..1c37465 100644 --- a/docs/share/refs.bib +++ b/docs/share/refs.bib @@ -166,6 +166,14 @@ year = {2024}, } +@techreport{handover, + author = {Blansch, Loek Le and Hammer, Elwin and Faase, Lars and in 't Anker, Thomas}, + title = {Handover Report}, + location = {'s-Hertogenbosch}, + publisher = {Avans University of Applied Sciences}, + year = {2024}, +} + @techreport{2021_design, author = {Creemers, Merel and van Wiechen, Joost and Lengowski, Vincent and Maas, Justin}, title = {Ontwerpdocument}, diff --git a/docs/theme.yml b/docs/theme.yml index b26ad75..49f729f 100644 --- a/docs/theme.yml +++ b/docs/theme.yml @@ -61,6 +61,7 @@ toc: caption: align: center end: bottom + margin_inside: 6pt image: align: center @@ -98,3 +99,10 @@ footer: center: content: '{page-number}' +admonition: + column_rule_color: '#000000' + column_rule_width: 1pt + padding: [3pt, 6pt, 3pt, 6pt] + label: + font_style: bold + -- cgit v1.2.3 From 807e1499a683209f7ca310e65a6a268772e0409d Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 23 Jun 2024 15:40:50 +0200 Subject: final documentation check --- docs/design.adoc | 79 ++++++++++++++++++++++------------------------------- docs/handover.adoc | 33 +++++++++++++++------- docs/research.adoc | 7 ++--- docs/share/refs.bib | 8 ++++++ 4 files changed, 67 insertions(+), 60 deletions(-) (limited to 'docs/share') diff --git a/docs/design.adoc b/docs/design.adoc index 9e48fd4..6df83b6 100644 --- a/docs/design.adoc +++ b/docs/design.adoc @@ -13,7 +13,7 @@ structure, and has three levels of design 'depth': Only design details deemed relevant by the document authors are documented here. Low-level implementation details such as API interfaces, code paths and -workarounds are documented inside the source code repository. +workarounds are documented with Doxygen cite:[pbdox]. [[sec:lv1]] == Top-Level @@ -34,8 +34,9 @@ main controller and multiple puzzle modules. Other notable details include: time of writing (2024-03-11), and this project only describes the interface between the puzzle box and the bomb. * The puzzle box is capable of bidirectional communication over Wi-Fi. This - connection is used to configure the puzzle box before gameplay or modify its - state during gameplay. + connection is used to configure the puzzle box before gameplay or modify its + state during gameplay (<>, + <>). [[fig:system-top]] .Context block diagram @@ -92,8 +93,11 @@ The criteria for a puzzle module controller are: The research document cite:[research] compares various microcontrollers matching these criteria. As a result of this research, the Microchip PIC16F15276 was selected as the recommended microcontroller for future puzzle -modules. The current development hardware utilizes an ESP32-PICO-D4 module, so -the puzzle module software is written with portability in mind. +modules. + +NOTE: The current development hardware still utilizes an ESP32-PICO-D4 module, +but due to a misunderstanding cite:[handover], Arduino boards were used to +implement the puzzle modules. [[fig:puzzle-module-top]] .Generic puzzle module top-level block diagram @@ -149,10 +153,9 @@ Pi Pico W as main controller during development. NOTE: This was written while we did not know the puzzle bus specifically requires slave-addressible I^2^C multi-master controllers to function properly. -While the research concludes the RP2040 is a suitable microcontroller for the -main controller, it is not. The RP2040 was still used, but has required -implementing workarounds. Please see the handover report for more details on -how this impacted the project cite:[handover]. +The RP2040 was still used, but has required implementing workarounds. Please +see the handover report for more details on how this impacted the project +cite:[handover]. [[fig:main-controller-top]] .Main controller top-level block diagram @@ -187,8 +190,10 @@ multi-master I^2^C bus, and all puzzle modules are specified to be I^2^C multi-master controllers that are slave-addressible. The multi-master part is required to prevent I^2^C transmissions from being corrupted in the event of a bus collision, and the slave-addressible part is required to both send and -receive messages on the same controller. This is the only hardware-level -specification made this year. +receive messages on the same controller. This can also be achieved by using 2 +I^2^C peripherals on the same bus simultaniously, which is what the RP2040 +currently uses. This has required changes to the wiring, and is the only +hardware-level specification made this year. More details on the messages sent over the puzzle bus are described in <>. @@ -253,7 +258,7 @@ development of future puzzle modules (<>). === Puzzle module framework This subsection defines aspects of the 'puzzle framework': the interface that -allows puzzle modules to integrate with the puzzle bus main controller. All +allows puzzle modules to integrate with the puzzle bus and main controller. All communication described within this subsection refers to 'internal' communication between the main controller and puzzle modules on the puzzle bus. @@ -295,7 +300,7 @@ is shown in <>. The messages are (de)serialized using mpack. This choice was made after considering various alternative options for sending structured messages cite:[research]. Note that all messages are sent as I^2^C writes. Due to this, the I^2^C address of a message sender is included in the -header. +header to facilitate network-like features over I^2^C. [[tab:pb-msg-fmt]] .Puzzle bus message format @@ -332,7 +337,8 @@ is solved. | ``PROP`` | The PROP command type is used for exchanging arbitrary data between puzzle modules and/or the puzzle box client (pbc) over the <>. These properties are not used by the puzzle framework. +bridge>>. These properties are not used by the puzzle framework, and serve as +an extensible interface for puzzle module developers to use. |=== <> lists the different command actions. @@ -362,7 +368,7 @@ main controller firmware (<>). The specific format of the 'cmd' field from <> is different for each command type, and is for this reason only documented in-code using -Doxygen. +Doxygen cite:[pbdox]. [[sec:framework-state]] ==== State @@ -401,16 +407,15 @@ expansion without modification of the main controller software The RPI Pico SDK prohibits the use of I^2^C addresses reserved by the I^2^C specification. This means different addresses from previous years are used. -These addresses are indexed in the code under a shared header (see -``lib/pbdrv/pb.h``). - -The same I^2^C address may be used by two different puzzle modules, but this -will make it impossible for them to be used simultaniously. +These addresses are indexed in the code in a header exposed by the puzzle bus +driver cite:[pbdox]. The I^2^C addresses are also used to determine the puzzle sequence (i.e. the order in which puzzle modules are set to the 'playing' state). The sequence is determined by the main controller on startup, and consists of the connected puzzle modules' addresses in descending order (i.e. highest address first). +Note that the same I^2^C address may be used by two different puzzle modules, +but this will make it impossible for them to be used simultaniously. === Main Controller @@ -423,14 +428,15 @@ startup. Puzzle modules start in the 'uninitialized' state (see <>), during which they do nothing. Puzzle modules in this state are still able to reply to requests, including MAGIC REQ commands. When the main controller receives a MAGIC RES command, the I^2^C -address of the sender is added to an internal list for puzzle modules. +address of the sender is added to an internal list of I^2^C devices that are +considered puzzle modules. After the initial handshake request 'wave' (bus scan), all puzzle modules are repeatedly asked for their global state using a STATE REQ command. This request also includes the global state of the requesting puzzle module, which is always the main controller (under normal circumstances). Upon receiving the first STATE REQ command, a puzzle module knows it has been registered successfully by -the main controller, and may transition into the 'idle' state. +the main controller, and transitions into the 'idle' state. [[fig:sequence-puzzle-module-init]] .Puzzle module initialization sequence diagram @@ -479,10 +485,7 @@ Due to the separation of the puzzle bus driver code into a standalone library for reading/writing puzzle bus commands, and a puzzle module-specific code, the puzzle box client is able to read/write raw I^2^C commands directly. A separate library was made for serializing I^2^C messages so they can be sent over the -TCP connection. - -Detailed specifications on the TCP socket server are in -<>. +TCP connection. This library is documented in detail using Doxygen cite:[pbdox]. ==== Operating system @@ -494,13 +497,6 @@ choice was between FreeRTOS and Zephyr. FreeRTOS was chosen because it is the simplest solution, and because the features Zephyr offers over FreeRTOS are already present in the Raspberry Pi Pico SDK. -NOTE: Due to the issues with the RP2040 that were later discovered -cite:[handover], delays are used within the puzzle bus driver's message -handling logic. This means that due to the use of the RP2040, *all puzzle -modules* are required to use a task scheduler or similar mechanism for -deferring calls to the puzzle bus driver from the I^2^C interrupt service -routine (ISR). - === NeoTrellis puzzle This subsection defines aspects of the 'NeoTrellis puzzle' module and gives a @@ -515,8 +511,8 @@ button. The way to solve this puzzle is by dimming every Neopixel in the 8x8 matrix. This is done by clicking on a button, which switches the state of the Neopixel underneath the pixel and the Neopixels in each cardinal direction from the pressed button. This means that if a Neopixel was on and the button was -pressed it will turn off and vice-versa. A visual example can be found in -Appendix B. +pressed it will turn off and vice-versa. +// A visual example can be found in Appendix B. ==== Puzzle inputs & outputs @@ -544,7 +540,8 @@ have their own logical circuit engraved in the box, and the 6 input ports on the right side of the puzzle have a letter (A through F) engraved in the box. The way to solve the puzzle is by connecting the banana plug cable from an input port on the left side of the puzzle to the corresponding input port on -the right side of the puzzle. An example of this can be found in Appendix C. +the right side of the puzzle. +// An example of this can be found in Appendix C. When the puzzle starts, the participants of the game will have 6 code-fragments written on paper, corresponding to the logical circuits on the puzzle box. The @@ -605,14 +602,4 @@ clicked the vault resets and they need to start over from the beginning. .Vault puzzle in-out image::img/vault-io.png[] -== Components -[[sec:lv3-remote-control]] -=== Remote control - -[appendix] -== NeoTrellis puzzle example - -[appendix] -== Software puzzle example - include::share/footer.adoc[] diff --git a/docs/handover.adoc b/docs/handover.adoc index 77d5da0..efeec00 100644 --- a/docs/handover.adoc +++ b/docs/handover.adoc @@ -84,6 +84,8 @@ The current project state is as follows: ** two puzzle modules ('Vault' and 'NeoTrellis') integrated using the puzzle bus driver +Functionality: + * The main controller (a RPI Pico W) can interact with the different puzzle modules using a central shared I^2^C bus (referred to as the 'puzzle bus') * The main controller is able to find new puzzle modules on startup, and does @@ -92,6 +94,11 @@ The current project state is as follows: main controller through a TCP connection and allows control over various aspects of the puzzle box using simple commands. +Documentation: + +* These project documents +* Detailed usage and API documentation for all software modules cite:[pbdox] + == Incidents During this year's run of the project, we encountered several difficuties we @@ -142,10 +149,11 @@ Please note the following differences between I^2^C devices: regular I^2^C slave devices. - I^2^C multi-master controllers that are slave-addressable in master mode are the only kind of I^2^C controller suitable for use in puzzle modules. + Microcontrollers with 2 I^2^C peripherals on the same bus (one in master + mode, one in slave mode) can also be used to achieve the same effect. The RP2040 supports multi-master, but is not addressable as a slave in master -mode. Due to time constraints, this was mitigated using a workaround (see -<>). +mode. This was mitigated using a workaround (see <>). === Development hardware availability @@ -161,6 +169,12 @@ multiple people to develop using the same setup. Note that the RPI Pico is a special case, as it requires another Pico for debugging, effectively requiring double the amount of hardware to support developers. +Due to a misunderstanding, we also thought our development boards went missing +somewhere during week 13. Double-checking if project materials were actually +stolen, or making clear where the materials are stored by sending an image of +its location could have easily avoided this from happening; make sure to do +either. + === Auxiliary workarounds and technical limitations This section details workarounds that were implemented instead of being fixed @@ -170,10 +184,9 @@ mentioned in this section. [[fixme:rp2040-i2c,RP2040 I^2^C limitations]] <>:: -- All puzzle module drivers have a hard-coded 2 second delay between receiving - the MAGIC handshake request and the MAGIC handshake response handler. This - was done to ensure responses are not ignored by the RP2040 (main controller) - while it is still in I^2^C master mode. +- The RP2040 is not slave-addressable while in master mode. A workaround that + uses both I^2^C peripherals simultaniously was written to work around this + issue. Memory management on Arduino:: The Arduino's built-in memory management functions do not seem to work @@ -208,7 +221,7 @@ are critical for project success: - The RPI Pico (and Pico W)'s I^2^C peripheral supports multi-master, but does not support being addressed as a slave while in master mode. This is required for puzzle bus integration, and was mitigated using a workaround (see - <>). A replacement controller should be used instead. + <>). === Other suggestions @@ -216,13 +229,13 @@ These points are suggestions for future project groups. While we do not think these are critical to project success, we still think they are important to mention. -- Implement the hardware design from the year 22-23. +- The hardware design from the year 22-23 should be implemented. - The original game rules are described in a separate document from the year 20-21. - The RPI Pico W has programmable I/O modules. Due to time constraints, we did not research if these modules can be used to create a custom I^2^C peripheral (and driver) that allows multi-master communication while still being - addressable as a slave. If this is possible, the RPI Pico W can still be used - as main controller without the use of workarounds. + addressable as a slave. If this is possible, the RPI Pico W could be used + without the use of workarounds. include::share/footer.adoc[] diff --git a/docs/research.adoc b/docs/research.adoc index 7a9d56c..6f9b494 100644 --- a/docs/research.adoc +++ b/docs/research.adoc @@ -145,10 +145,9 @@ The Raspberry Pi Pico W board is utilized during development. NOTE: This was written while we did not know the puzzle bus specifically requires slave-addressible I^2^C multi-master controllers to function properly. -While the research concludes the RP2040 is a suitable microcontroller for the -main controller, it is not. The RP2040 was still used, but has required -implementing workarounds. Please see the handover report for more details on -how this impacted the project cite:[handover]. +The RP2040 was still used, but has required implementing workarounds. Please +see the handover report for more details on how this impacted the project +cite:[handover]. [[tab:main-mcu]] .Main controller MCU candidates diff --git a/docs/share/refs.bib b/docs/share/refs.bib index 481d4d1..299d621 100644 --- a/docs/share/refs.bib +++ b/docs/share/refs.bib @@ -219,3 +219,11 @@ year = {2023}, msbib-accessed = {2024-05-11}, } + +@techreport{pbdox, + title = {puzzlebox Doxygen documentation}, + author = {Blansch, Loek Le and Hammer, Elwin and Faase, Lars and in 't Anker, Thomas}, + url = {https://media.pipeframe.xyz/puzzlebox/23-24/doxygen}, + year = {2024}, +} + -- cgit v1.2.3 From fc22aec1eef1872c25a624672d31f57db5c7bb26 Mon Sep 17 00:00:00 2001 From: ThomasintAnker Date: Sun, 23 Jun 2024 19:37:44 +0200 Subject: Added references --- docs/research.adoc | 23 ++++++++++------------- docs/share/refs.bib | 27 +++++++++++++++++++++++++++ 2 files changed, 37 insertions(+), 13 deletions(-) (limited to 'docs/share') diff --git a/docs/research.adoc b/docs/research.adoc index 6f9b494..e1fbfb8 100644 --- a/docs/research.adoc +++ b/docs/research.adoc @@ -437,7 +437,7 @@ wire library on both the Arduino Mega and the Arduino Uno. ===== PIC16F15276 & ESP32 -Both the PIC16F15276 and the ESP32 MCUs show possibilities to be addressable as a slave while being in master mode. However, at the moment of writing this +Both the PIC16F15276 cite:[PICData] and the ESP32 MCUs show possibilities to be addressable as a slave while being in master mode. However, at the moment of writing this has yet to be tested. // TODO: Add the following reference: @@ -453,26 +453,23 @@ has yet to be tested. ===== PIC16F15276 Registers -In the case of the PIC16F15276 not support master addressable as slave the +In the case of the PIC16F15276 cite:[PICData] not support master addressable as slave the following approach would most likely work. As the PIC16F15276 uses specific registers for its master receive functions, namely the RCEN register, it can be manually set to receive data from the I^2^C bus. However, this also has -yet to be tested. - -// TODO: Add the following reference: -// PIC16F15276 - 25.2.4.3 -// https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/PIC16F15256-74-75-76-Microcontroller-Data-Sheet-40002305.pdf +yet to be tested. ===== Multiple I^2^C Peripherals ==== ESP32 & RP2040 -The ESP32 and the RP2040 both have multiple peripherals for I^2^C -communication, while also supporting simultaneous configuration. This allows -both two I^2^C peripherals to be active, one being configured as a master and -the other being configured as a slave. This enables the controller to send and -receive data to the I^2^C bus without much difficulty. This does introduce -increased code complexity but is a valid option if it is succesful in testing. +The ESP32 cite:[I2CESPAPI] cite:[I2CESPTECH] cite:[ESPSPECS] and the RP2040 both +have multiple peripherals for I^2^C communication, while also supporting +simultaneous configuration. This allows both two I^2^C peripherals to be active, +one being configured as a master and the other being configured as a slave. This +enables the controller to send and receive data to the I^2^C bus without much +difficulty. This does introduce increased code complexity but is a valid option +if it is succesful in testing. // TODO: Add the following reference: // https://docs.espressif.com/projects/esp-idf/en/v4.3/esp32/api-reference/peripherals/i2c.html diff --git a/docs/share/refs.bib b/docs/share/refs.bib index 299d621..138ca57 100644 --- a/docs/share/refs.bib +++ b/docs/share/refs.bib @@ -227,3 +227,30 @@ year = {2024}, } +@online{PICData + title = {PIC16F15276 - 25.2.4.3}, + url = {https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/PIC16F15256-74-75-76-Microcontroller-Data-Sheet-40002305.pdf}, + author = {Microchip}, + year = {2022}, +} + +@online{I2CESPAPI + title = {I2C Driver - ESP32}, + url = {https://docs.espressif.com/projects/esp-idf/en/v4.3/esp32/api-reference/peripherals/i2c.html}, + author = {Espressif Systems}, + year = {2021}, +} + +@online{I2CESPTECH + title = {ESP32 Technical Reference Manual}, + url = {https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf#i2c}, + author = {Espressif Systems}, + year = {2024}, +} + +@online{ESPSPECS + title = {ESP32 Specifications}, + url = {https://www.bitsandparts.nl/documentation/482/ESP32_Specifications_EN_v1.pdf}, + author = {Espressif Systems}, + year = {2015}, +} -- cgit v1.2.3 From 84f729a8ff5c82bd7cf512d2a8a0dbe1433f7e0d Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 23 Jun 2024 19:40:46 +0200 Subject: protect corporate authors in bibtex file --- docs/share/refs.bib | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'docs/share') diff --git a/docs/share/refs.bib b/docs/share/refs.bib index 138ca57..7c8e511 100644 --- a/docs/share/refs.bib +++ b/docs/share/refs.bib @@ -230,27 +230,27 @@ @online{PICData title = {PIC16F15276 - 25.2.4.3}, url = {https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/PIC16F15256-74-75-76-Microcontroller-Data-Sheet-40002305.pdf}, - author = {Microchip}, + author = {{Microchip}}, year = {2022}, } @online{I2CESPAPI title = {I2C Driver - ESP32}, url = {https://docs.espressif.com/projects/esp-idf/en/v4.3/esp32/api-reference/peripherals/i2c.html}, - author = {Espressif Systems}, + author = {{Espressif Systems}}, year = {2021}, } @online{I2CESPTECH title = {ESP32 Technical Reference Manual}, url = {https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf#i2c}, - author = {Espressif Systems}, + author = {{Espressif Systems}}, year = {2024}, } @online{ESPSPECS title = {ESP32 Specifications}, url = {https://www.bitsandparts.nl/documentation/482/ESP32_Specifications_EN_v1.pdf}, - author = {Espressif Systems}, + author = {{Espressif Systems}}, year = {2015}, } -- cgit v1.2.3 From b0c5e2f2bd1f9116f09803cf841d45e82c0212c0 Mon Sep 17 00:00:00 2001 From: Loek Le Blansch Date: Sun, 23 Jun 2024 19:42:22 +0200 Subject: fix bibtex file --- docs/share/refs.bib | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'docs/share') diff --git a/docs/share/refs.bib b/docs/share/refs.bib index 7c8e511..6386fec 100644 --- a/docs/share/refs.bib +++ b/docs/share/refs.bib @@ -227,28 +227,28 @@ year = {2024}, } -@online{PICData +@online{PICData, title = {PIC16F15276 - 25.2.4.3}, url = {https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/PIC16F15256-74-75-76-Microcontroller-Data-Sheet-40002305.pdf}, author = {{Microchip}}, year = {2022}, } -@online{I2CESPAPI +@online{I2CESPAPI, title = {I2C Driver - ESP32}, url = {https://docs.espressif.com/projects/esp-idf/en/v4.3/esp32/api-reference/peripherals/i2c.html}, author = {{Espressif Systems}}, year = {2021}, } -@online{I2CESPTECH +@online{I2CESPTECH, title = {ESP32 Technical Reference Manual}, url = {https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdf#i2c}, author = {{Espressif Systems}}, year = {2024}, } -@online{ESPSPECS +@online{ESPSPECS, title = {ESP32 Specifications}, url = {https://www.bitsandparts.nl/documentation/482/ESP32_Specifications_EN_v1.pdf}, author = {{Espressif Systems}}, -- cgit v1.2.3