That's exactly what I was talking about saving - all the headaches. It's going to be a lot more than 50 lines of code to implement all 4 programming methods - though you really only need to implement one. No one does Register mode any more, you can leave that one completely out. Pick one, implement that. All systems support at least 2 of the other 3, most still support the ancient register mode just in case you have some very old decoders, but of all the ones you might NOT find on a modern system, that would be the one.
Consisting - well, I guess this is where Digitrax's way is better. The decoder gets no changes when I consist, I just need to know the address. And it's not likely a function decoder for controller the lights of a passenger car would be consisted with anything anyway
You were talking about making a function decoder for a apssenger car - and you're the one programming it, so you know the address.
I still don;t understand why it would matter what system you are using. I have multiple methods of programming decoders and I can assure you that each and every decoder does not have some code in it to tell if it is getting programming commands from Digitrax or NCE or MRC or Roco or some DIY DCC system. Unless you mean support for the 4 methods, but the only thing that might not give you the option of any of them would be a homemade DCC system. Most any commercial system does at least 3 out of the 4. And it's not like you're giving this to other people who might have no clue - if you are building it then you know what program mode(s) you included in the code.
If you don;t allow programming and hard code the address - just keep a list, or use JMRI to keep it for you. So the next one you program, you give a different address. I keep coming back to the whole idea of, once set up and running, how often do you actually change anything? Especially the address - if you've addressed the loco to the cab number, why would you ever change it, other than removing the decoder and putting it in a different loco? No, this is not good for making these by the dozens and selling or giving them to people, especially if trying to create a marketable product, you need to follow ALL NMRA specifications. But for experimenting with for yourself? At least START simple and then add in CV programming or whatever other features you want. Decoding the packets and making calls to functions based on the packet type or command is kind of the easy part. Acting on that data, or pulling the data from the command is where it starts to get complex. For all the things you aren't implementing initially - just make the function a trivial one that does nothing. Your program will be a whole lot of do nothing trivial functions plus a few that actually do something. Then as you want to add another feature, fill out the code for that function.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.