So I have an idiot question on github. Where would I put something like The culprit is the packet sequence that is used to trigger programming, e.g. in RegisterList::readCV in PacketRegister.cpp loadPacket(0,resetPacket,2,3); // NMRA recommends starting with 3 reset packets loadPacket(0,bRead,3,5); // NMRA recommends 5 verfy packets loadPacket(0,resetPacket,2,1); // forces code to wait until all repeats of bRead are completed (and decoder begins to respond) This is the original code from the BaseStation. The DH10C does not perform the acknowledgement because of the last resetPacket that is used to wait until all bRead Packets have been digested. I changed the resetPacket to another bRead Packet and all works fine. loadPacket(0,resetPacket,2,3); // NMRA recommends starting with 3 reset packets loadPacket(0,bRead,3,5); // NMRA recommends 5 verify packets loadPacket(0,bRead,3,1); // forces code to wait until all repeats of bRead are completed (and decoder begins to respond) Similar changes are necessary in the routines for WriteCVByte and WriteCVBit. This is a known fix that needs to go into the base code (maybe fixed in whatever one we end up using) but anyway I'm just unsure how to make it an official pull request.
easiest way is navigate to the source file on GitHub and click edit, make the changes etc. At the bottom of the edit page is a "create pull request" option. Make sure to use that and it will create a PR for you.
The following are the steps that I believe we should use. This is a good test of the process, btw. We need to delete the current development branch. Its out of date. Create a new development branch from master. @Atani, we will need your help to set up the ci and scan in the development branch. Open an "issue" describing the fix. Create a branch from development named hotfix/1 assuming it's issue # 1. Push your updated code to this hotfix branch. Create a pull request to request hotfix/1 be merged into development referencing the issue in the pull request. Someone or some people review the code changes and and complete the pull request.
If everyone is in agreement I'll nuke the current development branch and recreate it from master. These can be combined for one-off fixes like the one above via the web code editor page. It will create the branch and PR automatically.
I'm all for the standard that most people would be familiar with, while at the same time wanting to keep it simple. The last one's organization is good, but is it is one level too much? "release", "development", "master"? On the one hand, we aren't Microsoft, but on the other we want the workflow to be smooth and cover all the bases. If you guys agree on option 3, and no one else chimes in. We can set that up. Does anyone have a chart for this organizational structure or a read.me? If not, we should create one just so if everyone gets hit by a truck it is all as nicely documented as we want DCC++ to be. Where in the hierarchy would that go so that people jumping in could immediately read it and see how things are working?
I am in agreement for Atani to nuke the branch and and recreate from master. Is there anything in hotfix1 to merge into development right now?
This has been completed. Should "master-2.0", "master-server-2.0" and "multi-serial" face the same fate? I'd vote for "master", "release/x.y" where x.y is the major.minor release version and we can tag commits as x.y.z where z is a point release. A point release would be simply a fix for an existing release (such as the above issue for prog track). A major version bump would typically indicate breaking changes from previous release and a minor bump could be something in between.
Best place for this would be directly linked from the top level readme file (which needs a number of updates). We should take that as one of the first steps of development (define how the development is going to be done going forward, etc).
I created a pull and think I did it correctly. I compiled it fine and tested on my setup and all works. I would not mind others doing so just to make sure I didn't break anything with the changes. You'll need to read and write CVs to test. I'll get to work on JMRI setup with DCC++ documentation this week.
Do we have at least 3 votes for this: Also, we my need a slight modification of something like this, but I think this is on the right track, no? What will the final "tree" diagram look like? Then our readme can include this and flesh out the steps and the git bash commands to do it. Someone will have to help with the GUI version of doing the same thing. I'm thinking the local git commands are something like where we are checking out from master as below or from develop: $ git checkout master $ git merge --no-ff new_feature $ git branch -d new_feature $ git push origin master Git-model@2x by FlightRisk posted Feb 24, 2020 at 3:38 PM Gitflow by FlightRisk posted Feb 24, 2020 at 3:38 PM
If you guys need a web site to post anything other than what you are doing on github my site is available. It could have its own section. You could send to me and I'd post or I could give permission to one person to be able to make changes. I wouldn't want passwords to the sever to be out there in multiple places. Sumner
@Keith Ledbetter, it looks to me like your pull request is trying to update master rather than development branch. This early in the project it probably doesn't matter.
Yup, it looks correct overall. There are minor formatting issues for the comments but that is really minor. In any case, the code is not quite right since it queues the reset packet before the ACK checks. The correct approach would be: reset packets read CV (bit or byte) check ACK(s) reset packet To make it more inline with NMRA spec I'd suggest queue up an idle packet instead of a second read and then add the loadPacket(reset...) after the ACK checks. Retargeted to development. GitHub also offers web hosting for projects which can be used as well. The content comes from a "gh-pages" branch or a dedicated repository.
@Atani, now you are quickly showing my novice code knowledge here I was more doing to test the process with something that was an improvement but we could use as a test case but certainly if there are further improvements lets do it. I like the version control that is coming together!
Hopefully we will keep organizing how to handle organizing all of this. We have the Taiga boards (https://tree.taiga.io/project/rogerb-dcc/kanban) and the projects page on Github and discussion here that could get cluttered. I think what I am about to ask will need to go on one of the first 2 or the "team" feature of github. But I would like to decide on how to handle documentation for ourselves/contributors and users. We have a read.me file for a project, the Wiki pages and the gh-pages Website we can create. I'm looking at how things are used now and wanting input on reorganizing this way: readme.md - hold general instructions for contributors (now holds a short "what is DCC++", "what's in this repository" and "important links") Wiki - hold detailed instructions for contributors on the branch structure and how we uses github (now holds the instruction manual for how to use DCC++) gh-pages - hold the user manual and whatever else we want (we haven't enabled this yet) Some sites use the readme.md for everything. Others use the read.me as an overview and contributor instructions and the Wiki is the user guide. They have no gh-pages website. If we set up a gh-pages site, do we use the "organization site" or the "project site"? Also, what do we use for an editor? Jekyll is not on Windows I don't think. Normally, the readme would be for contributors, but users with no understanding of coding or github might come here to download the project and need some help or a link right away. Here is a sort of standard readme format: Project name Description Table of Contents Installing Usage Contributing Credits License
Well I know I'm Kinda new around here but I am well versed in multiple code languages along with learning CPP currently. I am able to help the one thing I think that can be done right away would be an installer for DCC++. If written in c# based on latest branch that actually pulls from github, builds then flashes aurduino without user interaction would be the simplest thing for most users. They would just have to download the exe plug in auduino and press start. Now of course we would have them pick motor shield and Arduino type but even com port reading could be automatic. Automating the build, flash process is the fastest way to simplify it. Most of the Arduino compiler stuff is done via command line so execution of command line stuffs would be cake (done similar stuff in the past)
@Dex - Invite to Github sent. Maybe leave Trello for the time being? It's likely to be redundant shortly. R-
I'm not sure we want a windows specific component. Many people, like me, have a raspberry pi connected to the arduino where we run both the arduino IDE and the JMRI.
It's not about the code but compliance with the NMRA DCC spec. The DCC++ code violates it in a few areas and we should take this opportunity to fix it. You would directly edit the markdown files (readme.md, index.md, etc) in any text editor and when you commit the Jekyll system will take over and render it as html for the clients. Many have tried to make something like this for projects and it ends up being a major time sink and source of problems. I would hold off on investing into this for the time being and instead provide clear and concise instructions so the end user has a higher chance of success overall.
As for this being a time sink I am not sure, as long as we are only pulling from the master trusted code. If the installer is well developed from the start like specifically to download all required libraries and add them directly or even if we download a compiler ide like platformIO to make obtaining libraries a lot easier. All i know is once you cut out the extra steps required and make it super simple people are more likely to be on board. Yes i understand this and this is part of the reason why we have the raspi image that includes all of that which is in essence the same thing an all in one installer you just burn and go. I was looking to do something similar with the windows installer deal. Besides most persons that are around wanting to get into DCC most likely will have a windows computer laying around and if its targeted towards a lower .net Framework then we can even get it working on Windows 7.
