openlightingproject / rp2040-dmxsun Goto Github PK
View Code? Open in Web Editor NEWRP2040-based USB DMX dongle with integrated web server
License: GNU General Public License v3.0
RP2040-based USB DMX dongle with integrated web server
License: GNU General Public License v3.0
window system :-
I am getting complication error when run this command "make -j$(($(nproc)+1)) " and also window has issues finding libraries (lwip)
C:\Users\pico\Downloads\rp2040-dmxsun\pico-sdk\lib\tinyusb\lib\networking\dhserver.h:38:10:
fatal error: lwip/err.h: No such file or directory
i cant find .uf2 file in this repo. it will be helpful..
OLP has a generic Art-Net implementation (https://github.com/OpenLightingProject/libartnet). This should probably be preferred to the current "custom" implementation
It might be nice to push a demo version of the website up to GitHub pages or the Open Lighting website, assuming it could be made to work standalone or with some dummy JSON files without too much work.
See #35 : kicad-exports has been archived and https://github.com/nerdyscout/KiCAD-CICD-Template is the replacement, so our GitHub action needs to be reworked.
Currently, only DMX output is implemented. However, DMX input is highly desirable (so we can build an active DMX splitter, or receive DMX data from a console on an input port and forward that data to a PC or via wireless) and is also a requirement for RDM.
DMX input on the rp2040 has been implemented at https://github.com/jostlowe/Pico-DMX and I've verified it working (after some changes that have been merged in the meantime).
However, with the current "big locks" (which disable all interrupts as well) in the code, incoming DMX frames could be lost (if the end of an incoming DMX frame happens while the CPU is busy generating data for the next frames to be sent).
So besides changing the patching infrastructure and properly assigning the PIOs, SMs and GPIOs properly, the locking and interrupt disabling code needs to be re-worked.
Proposal: Split up the current "big lock"/spinlock to several smaller ones and think hard, when to disable interrupts and when not. Caution: Deadlocks can appear when code owning a mutex is interrupted by a service handler that also wants the same mutex that is locked by the interrupted code.
Also, the incoming data should NOT be immediately processed in the ISR. It should be appended to some kind of queue and be handled in the main loop.
Work in progress is here: main...kripton:dmxIn
When flashing the Pico over USB (instead of using the SWD-based debug port and OpenOCD), one needs to replug the board everytime it should be flashed. If fhe SDK allows it, add a command to the USB protocol to reboot to the bootloader.
Well, this project currently has 0 tests implemented. Might be nice to have some :)
This project is mainly focused on generating DMX data and driving RS-485-lines with it. However, due to the modular hardware design, the firmware can also be used to drive LED-pixel-strings with WS2812b or similar protocols.
The current boardconfig-data already has fields prepared for IO boards with that purpose. However, the hardware design and firmware implementation has not yet been done.
I see you've already mentioned this partly in #2 but given it's important we don't get UID clashes in our space so for now if you're using static ones it would be good to switch to some of the reserved ones here (any of the development blocks are fine):
https://wiki.openlighting.org/index.php/Open_Lighting_Allocations#UIDs
What serial(s)/MAC(s) does the RP2040 chip ship with and I can suggest some ways we could make use of them based on what we've done in the past.
The base board already routes the I2C bus to the IO boards. It would be nice if a Grove-compatible connector would allow additional extensions (OLED, LCD, input buttons, NFC?, ...).
Effort should be minimal.
Hi,
I am struggling to understand GitHub actions but I guess I don't have enough patience at the moment :)
If you just want to get started quickly find the most recent action run from the branch you're interested in, extract the attached artifact zip file (from https://github.com/OpenLightingProject/rp2040-dongle/actions/workflows/pico-build.yml ) and copy the rp2040-dongle.uf2 file to the Pico board when it's in bootloader mode.
I don't find any zip file or how to generate it?
Right now, the patching of incoming data to the internal DMX buffers and from there to output ports is hardcoded. What would be needed is the implementation to have the current patchings accessible and changeable via the HTTP API plus a visual representation on the Web UI.
https://github.com/OpenLightingProject/rp2040-dongle/settings/branches
This means that at least for PRs people know certain things have to pass before they'll be merged. You can optionally allow admins to ignore this.
Currently, the device chooses one IP address based on the chip ID in the flash memory (if no IP has been stored in the config) and provides another IP in the same subnet to the host machine via DHCP.
This might be easier using AutoIP/APIPA provided by the lwIP stack: https://www.nongnu.org/lwip/2_0_x/group__autoip.html. We just need to make sure that all host OSes we want to support don't treat network connections as non-functional if their DHCP requests go unanswered.
Zeroconf is the name of the technology / processes ifself. Apple Bonjour and Avahi are two widely-known implementations.
Also, usbsun should at least advertise some kind of hostname and the services it provides via mDNS (also already supported by lwIP).
Hello, I'm trying to test your project but I load the latest version of your software and my pico only flashes the led quickly but no network device appears. load some sample uf2 projects and it works. im very new with pico am i forgetting something?
thank you!
Currently, only the IOboards with 3-pin XLR connectors are done and have been ordered and tested. The 5-pin variants are not yet completed and/or tested. 5-pin XLR connectors a must to fulfil the actual DMX-512-A specification and for professional users.
Currently only a "full-blown", 4-slots baseboard has been designed to test the full capability of the hardware. However, most of the time, 16 universes are not needed and a smaller footprint would be desired.
Therefore, we should have:
Seeed studio provides an "Grove DMX module" (https://wiki.seeedstudio.com/Grove-DMX512/) which is basically an RS-485-driver + 3-pin XLR connector. It's not cheap, it's not 5-pin and it cannot do input or RDM.
However, we could support it by adding Grove-compatible connectors to the IO boards (before the RS-485 driver).
The current implementation emulates a network device via USB (CDC NCM) so that the host computer can transfer data via IP packets (web interface, ArtNet, E1.31/sACN). However, attaching a real Ethernet device could be beneficial. One could build a standalone 16-port ArtNet-to-DMX adapter.
However, the rp2040 only has a limited amount of GPIO pins and there are probably not enough to cater for a LAN8720 board (except if some of its pins were optional). There might be Ethernet-Boards that attach via I2C (no additional pins required) or SPI (one additional pin required for the CE line).
This will also require quite some refactoring on the software side. We could go all the way to allow packet forwarding from the emulated USB network interface to the "real" Ethernet hardware, so the dongle could be used as USB-to-Ethernet adapter as well. I assume that would not be worth the effort ;)
For cost reasons and since I didn't know for sure if all features I had in mind actually work, I only ordered, soldered and tested the "unisolated" variants of the IO boards.
The "isolated" (= galvanically isolated and better protected against ESD) variants are more or less done but are yet untested. They are more expensive since they require DC/DC-converters with quite some output power and the isolated RS-485-driver ICs are more expensive than the non-isolated ones.
Some IO boards (4ports_unisolated for example) feature the NC3FD-H connector. Since that part was not available in any KiCad-library, I created it myself. However, the drills on the PCB are now smaller than what the actual connector requires and as such the connector cannot be soldered to the PCB :(
Hi,
Im looking for any schematic to make one & try
If you have schematic i wll design pcb & share it.
Hello,
I want to know whether the project supports WS2812 LEDs and XLights software.
Thank you in advance!
It would be great to have some nice documentation about all classes and methods there are in the source code. I'm thinking of doxygen and the like but I'm open to other proposals as well.
i am trying to Ethernet( ENC28J60 ) configuration with pico rp2040 as per main...kripton:ethernet) but get error..
That's what I get when I finished uploading the uf2 file into my RP2040 Zero. There's a notification that says the USB device is malfunctioning. Don't know whether this is a Windows 11 issue, or RP2040 Zero issue. I've tried changing USB ports but the error is still there.
The RP2040 Zero have WS2812 LED built into port 16 as its DIN, and after the uf2 finished uploading, the LED somehow turn full white. I think this maybe the problem, as the RP2040 Pico doesn't have WS2812 built into it. I'm not really sure though.
My system is on Win 11 Home (build 22631), AMD Ryzen 5 5600H
The binaries for the Pico board should easily be generated by some kind of CI pipeline
You've currently got e.g.
https://github.com/OpenLightingProject/rp2040-dongle/blob/08e6e144c32b5bf002fd0e936cf510dbeb2a6162/src/jaruleproto.c#L15
In OLA we use __FILE__
too, but we also setup a macro to centralise and tidy most of the back-end commands (although I guess the latter might be a bit harder if it's all in a printf):
https://github.com/OpenLightingProject/ola/blob/ea3a18a925f123c8771ebc6c60327678e99ddcf2/include/ola/Logging.h#L59-L60
See jostlowe/Pico-DMX#27 and https://github.com/kripton/rp2040-dongle/tree/DirectDifferentialOutput: It's possible to directly control fixtures via the GPIOs, not necessarily do we need an RS485 driver. While one cannot drive 16 universes that way (not even 8), it might allow for a very cheap IO board
KiCad v6.x changed the file format, especially for the schematics (see https://www.kicad.org/blog/2021/12/KiCad-6.0.0-Release/). The current files in the hardware
folder should be migrated to this new data format.
Also, the GitHub-Actions might need to be updated/adapted.
Currently there is no way to get compiled .uf2 file from this Github. Would it be possible to check bot for automatic builds as all artifacts are long expired? It is pain in the *** to compile it on Windows and not all guys has dedicated linux machine for such a purporse. Thanks in advance
Hello! I'm doing some tests with the ws5500 branch, does it work? What would be the pins used to connect my ws5500 board to the rp2040?
Thank you!!
after the DHCP offer from the RP2040 over USB, the computer (USB host) requests the offered IP.
but the RP2040 does not ACK this request.
thus the DCHP negotiation does not complete and the IP is not assigned to the interface (at least nor under Linuc Arch using dhcpcd).
see attached trace where DHCP client repeats the unanswered request.
Lots of work to be done here :)
Depends on #21
I personally don't have much experience with RDM. I do understand the concept and benefits. However, I don't have any real fixtures to test it, only the "Arduino RDM responder".
Currently the Web UI uses HTTP call to the device's API to get/update information like device status, buffer content (Console page), log entries, wireless status counters. Usually, a one second update polling interval is being used which makes the Console seem laggy when the values update often or fade. Websockets provide a nice way to make the Web UI more responsive and faster. Some "live audio mixers" that can be controlled via web browser from a tablet or similar uss websockets for control and signal level display (Soundcraft's Ui series).
The client/browser part should not be a problem (and a fallback to polling could be done if the user-agent doesn't support websockets). On the server side (lwIP stack and its http server) impementation will be quite some effort.
At the moment, the way the Web-UI is being built is a bit of a hack. It runs during the "CMake" step, not during "make" where it actually should be. Also, it doesn't fail the build if for some reason (NodeJS missing, dependencies not resolving properly, ...) the compilation of the Web-UI fails. This is all mainly due to my very basic knowledge of CMake.
Currently, only "sniffer" and "broadcast" wireless modes are implemented. However, the RF24-library also supports a mesh mode (https://nrf24.github.io/RF24Mesh/index.html).This has the great benefit, that packets can hop from one node to another to extend the possible range. In the example topology (see https://nrf24.github.io/RF24Network/md_docs_tuning.html), let's assume the master node "00" is attached to a PC and receives DMX data from there. The nodes "015" and "025" are out of radio range of "00" and cannot directly receive the data. However, node "05" has "00", "015" and "025" in radio range and forwards data from "00" to "015" and "025".
However, the mesh is not "fully automatic" or self-healing. This means that some configuration needs to be done by the end user / operator.
Work in progress at main...kripton:mesh.
To clarify:
It's also easily backronymable, DMX Sixteen UNiverses laughing !
Nice one, didn't even think of it! Want it in the Readme? ;)
Originally posted by @kripton in #34 (comment)
I'll leave that bit up to you either way.
But maybe if it's now called dmxsun the repo should be renamed to match so people can find it? Unless you're going down the route we did with Ja Rule where the software and hardware had different names?
this is more a status report from trying the project, since the README does not mention it.
currently it is not possible to configure the IO boards on the slots.
cgi_config_ioBoards_config
in webserver.cpp
is actually implemented, and is reachable using an HTTP request (such as http://169.254.59.1/config/ioBoards/config.json?slot=0&boardType=3&port0dir=3&port0con=2&port1dir=3&port1con=2&port2dir=0&port2con=0&port3dir=0&port3con=0
, values are from boardconfig.h
), but the configuration is not reflected back (in the UI or functions).
currently 4 DMX outputs is hard coded and this can't be changed using the config.
Raspberry Pi released the Pico W including on-board WiFi ๐ฅณ https://www.raspberrypi.com/news/raspberry-pi-pico-w-your-6-iot-platform/
While the radio-module doesn't support narrow-band RF in the 2.4GHz band and Bluetooth is not yet supported/enabled, the new Pico W is pin-compatible (except the on-board LED) with the current one.
It sounds like a good "step up" from the regular Pico and to enhance the dmxsun with the web interface, Art-Net, E1.31 and EDP via the WiFi-interface in addition to the emulated CDC NCM via USB.
Things needing work:
lib/tinyusb/lib/lwip/
(where it already was before) and lib/lwip/
(where it was added to support IP via the cyw43 driver. This leads to the following compilation error (might be version conflict, needs investigation):In file included from /opt/raspberrypi/pico-sdk/src/rp2_common/pico_cyw43_arch/cyw43_arch.c:12:
/opt/raspberrypi/pico-sdk/lib/cyw43-driver/src/cyw43.h:118:17: error: field 'dhcp_client' has incomplete type
118 | struct dhcp dhcp_client;
| ^~~~~~~~~~~
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.