DCC++ Update Project 2020

FlightRisk Feb 16, 2020

  1. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    @haba Looking at the outline of the other system that uses assembly for the timing critical part. Here is the setup:

    • Output the number of preamble bits specified (1s)
    • Output the packet start bit (a 0)
    • Reset checksum to 0
    • For each packet byte
      • XOR for the checksum
      • Output the packet byte
      • Output the data byte start bit (a 0)
    • Output the checksum byte
    • Output the packet end bit (a 1)
    Not having completely poured through that code and also your recent changes, I have some questions. First, aren't we still bit shifting things all over the place to get the start and stop bits still so that our packets don't match the raw DCC packets? Or just before sending, do they match up? I guess I thought we could follow the above outline exactly, just like the way the "interface.print" functions send the return values back to the serial monitor:

    Serial.print("<N");
    Serial.print(COMM_TYPE);
    Serial.print(": ");

    The difference may be that for timing reasons, we may not be able to send a preamble, then send a start bit, then send a first data packet, then a stop bit, etc. as separate functions instead of building a stream and sending it all at once. Maybe I just need more education on what we are already doing, what is possible, and what is not possible.
     
  2. haba

    haba TrainBoard Member

    78
    32
    10
    The advantage with the interrupt routine which we have now is that it's very straightforward and contains very litte branches and calculation (like checksum) in the most common case. The most common case is just put out the bit and advance the bit counter. The bits may be shifted and that costs a byte but everything but the peamble-or-not-decision is precalculated.

    Regards,
    Harald.
     
  3. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    @haba. Ok, I looked at it some more and also looked at the machine code of the other method. Assembly may be faster, but we have the spare clock cycles and this is certainly more readable and more easily maintainable. I'm excited about the work moving this forward. Great job, Harald! How are you feeling about the ACK detection?
     
  4. haba

    haba TrainBoard Member

    78
    32
    10
    I got a trouble ticket at https://github.com/habazut/dcc-ardu/issues/1 and if anyone else has the same or other issues as Marty please let me know. Unfortunately I could not reproduce his problems right now. (I know the "works for me" is not that useful).

    Regards,
    Harald.
     
  5. haba

    haba TrainBoard Member

    78
    32
    10
    I missed that pin 2 is SIGNAL_PIN_PROG on the Mega. What pin should we use as scope trigger pin? Is there one that is available/free for this on both the Uno and the Mega (that would lessen the #ifdef-hell). Then it would be good if we could find a PROG_RAIL_AS_MAIN pin as well (for another idea I have).

    Do you think digital pins 4 and 6 are available (they look free to me on both Uno and Mega)?

    Regards,
    Harald.
     
  6. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    I know pin 4 is used if someone wants to use an Ethernet Shield. I can't think of a conflict on Pin 6
     
  7. Keith Ledbetter

    Keith Ledbetter TrainBoard Member

    279
    195
    12
    The original pin mapping https://github.com/DccPlusPlus/Documentation/blob/master/Motor Shield Pin Mappings.pdf shows the valid pins and what they are reserved for.

    Pin 6 is indeed the "best free" usable pin with PWM that works for both Uno and Mega but of course harold you are correct we could jumper on shield only and theoretically use underlying pins. Could also use the brake pins if you cut that trace and pin 9 is also free PWM pin for both as well if you cut brake trace.

    If a trigger and just need digital then 7 would also work no conflicts and 8 as well as ong as brake trace cut
     
  8. Dex

    Dex TrainBoard Member

    55
    30
    5
    Hey guys I'm still here just waiting on that update before I modify and push code to the Installer. I will keep watching GitHub for updates

    Sent from my Pixel 4 using Tapatalk
     
    Sumner likes this.
  9. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    Silly thing hanging me up, but I'm trying to decide what to names of the repository folders. Keep in mind I have to change the "src" folder to be named the same thing as the Arduino main project file name. So, the hierarchy is:

    Code:
    BaseStation-EX  (repository name)
    ...... DCCpp-EX       (folder name. can be DCCpp_EX, DCCppEX, DCCEX, etc.)
    ............ DCCpp-EX (this is the src folder now. Has to match the name of the .ino file)
    .................. DCCpp-EX.ino
    
    So this would lead to a confusing path. The project folder and the source folder can be the same or different as long as the source folder and main .ino files have the same name. So maybe this?:

    "https://github.com/DCC-EX/BaseStation-EX/tree/master/DCCpp_EX/DCCEX/DCCEX.ino" (the last two names have to match)

    I'm thinking about standardization (what are we calling the project and how much can we abbreviate it from "DCC++ EX". Is "DCC-EX" or "DCCEX" good, and ease of remembering/typing.

    P.S. Are there any rules about using dashes vs. underscores? (DCC-EX / DCC_EX)
     
    Last edited: Apr 7, 2020
  10. David Cutting

    David Cutting TrainBoard Member

    62
    29
    3
    Hi Everyone,

    I am interested in giving some big support to the DCC++ project. I can help in documentation or software, wherever I am needed. @FlightRisk where would you prefer for me to go?

    I'm rearing to design a new board for the project - I'm thinking about making a raspberry pi HAT that has an ATMEGA328 and dual motor controllers on it, then packaging the pi and HAT with an ATX power supply. My question is would there be a way to incorporate LocoNet or another similar interface so you could have a full-on base station?

    David
     
  11. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    Hi David. I saw your original HAT 2 or 3 years ago. Was that you or someone else with the same name? I suppose anything is up for discussion as to what people want and what is possible. We will probably limit the scope of DCC++ EX at some point, but there is room for more or versions like "DCC++ PiHat" or similar. You should also look at Atani's ESP32 version.

    What I think we need now is help organizing and getting documentation together. If you want to offer coding or suggestions, that's fine too. Keith and Roger are trying to get things going. I can give you access to the repositories, and you can get the Wiki or docs going. If you haven't, read this thread on the documetation: DCC++ 2020 Update Project documentation. See if that inspires you to offer your expertise.
     
  12. David Cutting

    David Cutting TrainBoard Member

    62
    29
    3
    That was me... problem with that project is I could never seem to get the darn thing to work. I've got a couple more boards under my belt so I'm probably able to make it work now. If I think about what beginner users would want, it would be a way to get up and running with DCC quickly without having to mess around with hardware and software. I don't want to run over what y'all are doing here... I'm just thinking about ways to make the hardware setup easier and more reliable. Something along the lines of a ready-to-run base station on the raspberry pi that includes JMRI already set up... you plug in your track, a monitor, and you're ready to roll.

    Something like that would allow DCC++ to function in a second area - as a "digitrax killer" of sorts. No need to spend hundreds of dollars on a base station, plus a locobuffer and a computer to make the system work. If we could integrate loconet into the project, we could even provide the ability to create booster stations with the DCC++ hardware.

    I'm not trying to destroy the current hardware setup, I guess my question is if there is a place within the project for a HAT, and if we want to add functionality like a LocoNet bus to make the project appealing to a wider user base?

    In the meantime, I'm putting together a test setup with an UNO and a Pololu shield and I've forked the repository to work on changes. I'll let you know when I'm ready to merge my stuff in.
     
  13. haba

    haba TrainBoard Member

    78
    32
    10
    DCC needs realtime to get the bits out. Therefore a microcrontroller _without_ OS is good for that task. Then a lot of other tasks of a base station can be better done by a computer _with_ OS. Like a Raspi with for example JMRI.

    DCC++ on an Arduino plus JMRI on a computer like the Raspi make a base station. You can run trains from your Android phone over WiFi-throttle and you can program quite comfortable with DecoderPro.

    On a base station some users want LocoNet. JMRI has LocoNet support unless you want to manage LocoNet throttles. For that you need today a $$ base-station or you would need a small piece of additional software in JMRI called SlotManager which does dispatch throttles to the so called Slots (table entries) which contain adress, speed, functions of each mobile decoder. JMRI can do a lot with LocoNet but does not have that capability yet. I have started a thread on the jmri-devel email list about how to add such functionality to JMRI but it's a bit of a big one for me as I am not so good in Java as I am in writing programs in C. It should not be that difficult as the SlotMonitor in JMRI is the listening part of a SlotManager. So if anyone would give a hand in that end, that would be nice.

    Regards,
    Harald.
     
  14. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    @Dex, go for it! I only did a quick test. It compiles for the UNO and Mega in both PlatformIO and the Arduino IDE. If anyone wants to upload this to a board as well to run it through its paces, that would be great. Next version will merge the development branch into master and be a major new version. It will have all the current monitoring changes and hopefully some of the refinements from @haba.

    The main changes are that the repository name changed, the source folder name changed form "src" to "DCCppEX", the main filename changed and the extension changed to .ino, and all the references in all the files have been changed to reflect this. So now we can create installs and zips that will work from either environment from the same codebase. One last change is the Platformio.ini file was updated so that it will recognize the DCCppEX folder as the new source file.
     
  15. David Cutting

    David Cutting TrainBoard Member

    62
    29
    3
    @haba understood. The first version of my raspberry pi HAT had an ATMEGA328P to talk with the pi and control the motor driver chip. You're right about the pi being the wrong choice for controlling the track.

    As for the SlotManager code, I don't have enough experience with Java to tackle that one either. I think I'll start by making the HAT with LocoNet, and we can take it from there.
     
  16. haba

    haba TrainBoard Member

    78
    32
    10
    I thought it would be nice if one from the Arduino could temporarily switch so that the DCC signal for MAIN track is geneated on the H-Bridge that normally generates the DCC signal for the PROG track. In that way you can test a loco without lifting it up or throwing a physical switch between the outputs.

    However you can not tell the Arduino to emit the PWM suddenly on _another_ pin (as far as I know). But with 4xNAND logic, you can make a small circuit that does precisely that: Remap the outputs. The trick is to replace the jumpers with a shield which has a 4xNAND on it. I have it working on a breadboard (I had no experiment shield at home).

    Now the question: Would you like this functionality so much that you for that would solder a 4xNAND on an experiment shield on top of the motor shield or would you in that case go "Nah" and stick with the physical switch?

    Regards,
    Harald.
     
  17. haba

    haba TrainBoard Member

    78
    32
    10
    @David: A LocoNet Hat which replaces a LocoBuffer can be a good thing to interrest folks to make the additions to JMRI. Not everyone has a LocoBuffer (as I happen to have).

    The question about Java coding was not only to David but open for all takers ;-)

    Regards,
    Harald.
     
  18. David Cutting

    David Cutting TrainBoard Member

    62
    29
    3
    I guess I should ask before I start developing a combo LocoNet and DCC++ shield... Will the libraries play nice with each other? Has anyone tried before? I checked and the pins don't conflict, so I guess my question is whether there is enough time between the interrupts?
     
  19. haba

    haba TrainBoard Member

    78
    32
    10
    DCC++ needs 2 timers which can do PWM, one for main and one for prog track (at least that's how the code is written today and if you don't want to interrup traffic on the main when you are programming you want it that way). The Uno hardware has only such timers. So you even use the Timer0 which is used for micros() and millis(). So if the library uses those or relies on that Timer0 is regular, it won't fly. I don't know if this is the case. How many LocoNet libraries are out there btw? If you base your HAT on the ATmega2560 which has 3 PWM timers you don't have this problem as then Timer0 is not used by DCC++.

    Regards,
    Harald.
     
  20. Keith Ledbetter

    Keith Ledbetter TrainBoard Member

    279
    195
    12
    Theorically the best way would be a hat/or shield and incorporates loconet. This would need to be done on a mega if a shield for sure and I'm not sure since loconet is not open source that you could pull it off but I am way over my technical knowledge with that comment.

    At some point you run out of space on a shield but fundamentally you could have a USB connection on the hat that did LCC, loconet etc so you can connect the Arduino seriel and the LCC/loconet/rocrail/whatever else from the shield to the computer.

    On a pi hat I think you would want to do the same have a USB that connects. Maybe even selectable from loconet to LCC to rocrail again I'd you can fit all that on a hat.

    Once we settle on the base code I absolutely think worth designing a custom motor shield with better hardware (current sensing, higher power, etc) and technology then the standard but we really need to settle on what we should include on that. I do agree if Loconet included a plus but again I think challenging. I would rather focus on open source support.

    Bit of a digression but I'd like to see the program track be a lower power highly accurate chip and the ops track be driven by a higher power but probably necessarily less accurate on small currents since in ops power is more critical and on programming your current sense and waveform cleanliness is critical.

    We probably should split thread into a hardware and software discussion thread to be honest.

    Folks that want to work generally fall into 4 catagories, software, hardware documentation, general project management. I am of limited use on software side,. Medium-sized use on hardware, good on documentation and proj MGMT.
     

Share This Page