THEMA: Turnout Controller without PIC!

If you use a lot of "standard logic" devices But that makes no sense at all. You can bye a 8 bit controller for less than 1 Eur and the programming software with c,c++ compiler and assembler is free. Maybe you use a avr or an other controller family which makes programming a bit simpler. I think you can get the software for some rail road protocol families also for free in the web. Why you try to use "standard logic" to make it more complicated as needed? You can switch up to 32 to turnouts with one! IC, eg a mega8515.

Maybe you have never used a controller before? OK, that is a good time to start with some simple projects like a turnout decoder If you need some support to start with avr feel free to ask.

Regards

Hello. Thanks for Your opinion.

I mean, that:
to receive sequental DCC address , pickout first bits - device address and decode last 2-3 bits to corresponding turnout signal inside device - there is no need to buy programmator, learn C++ ,  and write corresponding prorgamm.
This simply  task  needs only 1 - 2 chip of standard TTL or CMOS logic (see, for example, Marklin K83 turnout decoder) and simply DIP switch for choosing address.
This device becomes very relyable, and there no risk for occasionaly CV reprogramming due to noise error, or suspending of internal programm.

As I mean, using PIC's  can be reasonable for tasks which require sophisticaded calculations. For example, realization of ABC constant braking distance principle in Locos, RailCom communications, Sound Processing...etc.
For another example, RailCom applications of Turnout Decoders for switching position FeedBack would be very important an could be realized with PIC's. But  now we have PIC's in turnout controller, and there are NO feedback, no RailCom...  Only simply switching.

And therefore a GENERAL QUESTION occurs : Why PIC's used for so simly task?

-------
Vadim.

Vadim wrote:
"And therefore a GENERAL QUESTION occurs : Why PIC's used for so simly task? "

As already mentioned, using a uC is a very simple solution. If I take a look on my workbench, I find around 4 types of uC ready to use. If I want to have a full set of "standard" ICs (74xx and 40xx) I need maybe 50 or 100 different devices for the same purpose.

Vadim wrote:
"there is no need to buy programmator, learn C++ ,  and write corresponding program. "
C is enough and assembler is also enough for such simple problems. A programmer is available for less than 10 euro with usb. The software is free. I personal use uC's for everything. The simplest thing I ever programmed was a stupid running flashlight (10 channels). Maybe 20 lines of assembler code. 5 minutes work and all is ready to use. Why I should think about having a timer device (ne555?) having a counter (74xx) and a 5 bit to n decoder (74xx) and a lot of wires. Sorry, using TTL and CMOS "standard" devices is expensive, large and complicated. Holding all needed devices on stock is also not very handy.

If you have never used a uC, you will think it is complicated, but it isn't at all! To start with TTL logic or analog devices (timers) you also need knowledge. Now we can discuss which knowledge is important and which is "nice to have". My point of view: Starting with uC programming needs a few days of reading and few "projects" experience.

Vadim.
"This device becomes very relyable, and there no risk for occasionaly CV reprogramming due to noise error, or suspending of internal programm."
If your software will not allow write access to any internal program/data space, there is also no chance to "occasionally" change any device data. Maybe you put a simple switch "write allowed" on the board and all is safe, convenient and really ready for the future. And you need no dip switches, less space on layout, you have only a few connections which also targets a fail safe application.

My opinion: Use a uC always if it fit into the application. That safes time, space and money.

Thanks, Klaus.

You re right, uC is an universal thing, but if You ll open, for example,  Marklin K83 turnout decoder(without uC) and DCC Lenz one(with uC), and compare the quantity of components - they will be approximately the same.

I think, this is a simplest devices, and there is no sense uC or without uC it will be produced.

As to dip switch (for address)-  the turnout address settled once per layout. It's not so difficult or fiddly.

But if You forgot using POM mode at Your layout programming for other devices, all uC controller decoders will be reseted and  You ll must disconnect it and consequently programm again.
(i  suppose that's it's not so convenient)

May be components for large factory, as Lenz may, be unified, using uC's. You re right!
But, as to me, i make my home layout, and  there is no sense for me 5 or 10 different chips i must to get and solder.

As to my state:  I havent any information and catalogues about uC's market, and cannot even choose right chip type. I cannot evaluate an educational period. For example, when i study at my institute, i learn Texas Instruments DSP assembler and emulator  about half a Year!  

My opinion: uC's preferably must be used  where strong calculations required, or TTL/CMOS logic devices are too complicated.

--------
Thanks,
Vadim  

Hi Vadim,

the (old) Märklin protocol was initially introduced because it was possible to decode that signal with some LSI chip made by Motorola, although the Lenz DCC-predecessor system already existed on the marked. Caveat was that Lenz used Philips microprocessors and at that point in time, the small ones only had Mask-ROM (the larger ones required an external UV EPROM) - this was extremely expensive.

Decoding DCC is not as simple as you might think because there is no clock signal, so you need synchronize to the signal somehow. Nowadays, a small micros is so cheap that it will cost less money than 2 ordinary CMOS dumb gatters!

However, if you want a DCC turnout control why do you want to re-invite the 1001th decoder?
Just go for one of the public domain projects, e.g. start here:
http://www.digital-bahn.de/eigenbau.htm
You ain't have to develop the firmware program on your own - just download the HEX file for free and flash it onto the micro, that's it. If you wish to alter something, the source code is available.

BTW, it would be more useful in practical life if your institute offered a PIC and/or Atmel assembler course. BTW, C programming language is currently available for small micros. C++ would be way overkill.

Regards, Peter W.

Thanks!
I understood.
I watched link, but this link on Deutsch. I cannot read it, sorry.
I ll think about synchronisation problem. I think, Manchester or MFM one chip receiver must fit.

--------
Vadim.

You know Google translations? Give it a try:
http://translate.google.at/translate?u=http%3A%...amp;hl=&ie=UTF-8

This way you could invest the time save for re-inventing the wheel once more to learn a bit of German

Peter W.

I Agree, Peter. Mostly, railroad modelling are developing in Germany.
I ve found much more less information in English.
As to American - they dont like to control layouts, on the contrary - they like to ride the trains.
Therefore they have not so developed electronincs.

---
Vadim

Hello Vadim,

do you know http://www.opendcc.de ?
Many of the pages are available in english.

CU
KS

Thanks, KS,
I ll take in mind this information.

If i ll not found a special middle - integrated chips for DCC decoding  i ll learn assembler and do it by using DSP or PIC  UC's.

-------
Vadim.

Hi,

you will not find any decoder chips because there ain't any there. Trust me and stop searching! I definitely know what I am talking about.

Before I have newly started with PICs and Atmels, I have searched for a similar solution like you did - the only possbility was collecting very old Lenz/Arnold SMD Loco decoders or Marklin digital = accessory decoders and unsolder the preprogrammed microcontroller chips LE10, LE20 etc., but risking to fry the chip with the hot air gun, resulting in a dead circuit. I tried once and it worked, however it takes long time and much heat got get it off the board. As small PICs, Atmels und Silabs micros are so extremely cheap, it is not worth to do that.

Conclusio: Forget LSI/MSI decoder chips and forget DSPs, all these are overkill and way too expensive for such simple solutions. You may wish to attend Yahoo use group "selfmadecoders", communication done is in English language although the moderator named Georg Ziegler is German.

Regards, Peter

Thanks, Peter.

I ll take in mind this .

But how about another solution:

Now I have small layout with DCC locos.
Also i connected for test some motorola turnout decoders and s88 feedback for block section.
All these devices  are connected to main station, and work together without any conflicts.  
Motorola decoders are simply  and contains 2-3 small logic chips.
Now i think to expand my layout significantly.

Question:
May be is it worth to solder motorola decoders by himself, avoiding Uc's and learning assembler...etc?

---------
Vadim.

Hello Vadim,
just take a look at the NMRA pages (http://www.nmra.org/standards/DCC/). There you can download a lot of documentation regarding DCC (all in English).

When you take a look into the spec. you will see very quickly that it doesn't make much sense to try to develop a decoder by using TTL chips. There are some ASICs around (like in D&H decoders) but that's nothing you can buy or you would get documentation for. Most decoders are based on standard uControllers.

With kind regards,
Torsten

Thanks, Torsten.
I ll examine this link.

---
Vadim