RPi shutdown...

One thing to point out is that the RPi needs to be properly shutdown every single time. Randomly turning off power like we would do for an embedded command station will quickly result in sdcard corruption (and it won't be apparent at first). 

There are lots of complicated solutions to make the sdcard read-only but that won't work very well here since you'd want JMRI to keep any updates to things like the roster or panels.

Hardware solution to that problem exist: e.g. the supercacitor approach, or one "simple" workaround is to put a push button on the gpio and have a small program initiating a shutdown when pushed. 

JMRI is also quite verbose in its logging so unless that logging is directed to some kind of ramfs, it will wear the sdcard prematurely (e.g. remount /tmp and /var/log to a ramfs or to dev/null...)

Also if possible you'd want to backup your jmri config once in a while such that when the sdcard fails you can just restore it from an image and then simply copy the JMRI xml config over. (I have a git repo on bitbucket where I just push my jmri config once in a while).

I've been running a similar

I've been running a similar setup on my home layout and on our N-trak club layout. We tested the wi-fi performance at a show a few weeks ago and it worked much better than expected.  I quit testing when I got about 100 feet from the layout.  The photo was taken while the test setup was on the workbench.

Pi Shutdown

I am very aware that improperly shutting down the Pi will result in corruption. I ended up with a corrupt SD card that ended up in the trash. To solve the problem I have installed VNC on both my laptop and phone so I can control it remotely for shut down. Perhaps a button might be easier and less complicated. 

Super caps

Unfortunately a lot of people don't treat RPis as normal computers that need a proper shutdown sequence so I think it's worth overstating. The Pi Touch approach is a good way to have a button on screen to do that, or have a physical push button monitored via the GPIO. It does require users to actually care and push that button and not brush it away as irrelevant.

Another hardware option I wanted to try on mine is this super capacitor approach:

http://www.sensorsiot.org/safe-shutdown-for-raspberry-pi-with-super-capacitors-133/

Andreas has a video of the same here: 

If you go that route you need to be careful that any addon device on the RPi (usb, pi touch, gpio) might affect the shutdown time.

SD card corruption

Not that I don't believe you, but this is hard to believe that the corruption caused the card to be unusable, possibly it was a bad card to start.

If a card gets corrupted by improper shutdown you should be able to reformat / reload the card. You could reformat the card by putting it in a windows PC and selecting format, or put in your digital camera, or smart phone and have it format the card. That should at least give you a good card you could copy the image onto.

sdcard formatting

Jim,

The sdcard corruption from an improper shutdown will corrupt the ext4 fs on the sdcard. To recover from that, you need more than just reformat using Windows or a phone. The raspbian partition scheme creates 2 or more partitions on the sdcard and these won't be properly erased (only the small fat boot partition will be visible, not the main data ext4 one). On Windows you can use the SDFormatter utility to properly reformat the card, or use diskpart on the command line (google [ rpi diskpart] for details) to get rid of the custom partitions and then use Windows to format it. There are similar ways to deal with this on Linux or MacOS.

The other issue is sdcard wear, which will inevitably happen due to the incessant logs being written on disk.

The RPi can also be nitpicking about sdcards. Even brand names that work flawlessly as usb or in photo cameras sometimes fail on the RPi.

I'm not saying that

I'm not saying that corruption can't happen if the RPI is shut down un-gracefully, BUT in conversations with the author(Steve Todd) of the RPI image told me that after years of using his own system, and never gracefully shutting down, he's never experienced any corruption. I specifically raised the issue with him. Unfortunately, I can't seem to find the email........

Granted, it'd be best to shut down correctly, but as long as there's no real activity when shut down, it shouldn't cause an issue.

Bad Card?

All I know is I went to boot the system after the last unsafe shutdown and the card was toast. I could not format it in Windows using ANY method. The message continually said the SD card was write protected and there was no way around that. The card reader did not have any write protect switch, as some do. There was a trick using the registry to get around the write protect as well, but that didn't work. Maybe the improper shut down did something, maybe the card was just a dud. It wasn't a high quality card, something that came with a complete Pi kit I bought. I bought a new card and all is well. 

RPi UPS and DCC++ Hardware

I have several projects that use Raspberry Pis and several other boards in Headless configurations including two JMRI systems where startup(s) and shutdown(s) need to be managed automatically. To manage system power I rely on several available Uninterruptible Power Supplies (UPS) or power controllers. Although there are other UPS's available for the RPI, for my installations I have found the SmartUPS and UPS PIco to be very effective.

It is a little bizarre that this configurations requires two microprocessor boards to function. RPis have enough processing power and speed to perform all of the DCC coding and motor driver functions without the need for the Arduino board. All that is need is a DCC driver for RPi Debian Linux. Actually there are several Linux drivers, but like the driver for the Beagle Board Blacks  with TI PRUs, they are specific to the hardware available on the boards. Any of you RPi Linux coders out there have the time for another little task?

Oops Greg

Greg,

I also wanted to say thanks for a great post and tutorial.

@Ken

Thanks, I am hopeful it would be helpful. I should provide a disclaimer that what I wrote down worked for me and is based on information gleaned from various internet sources. I am by no means proficient in Linux and while I understand the basics of what I did, am no expert in anything. I'd like to thank Google for everything I know... lol

Another vote

I, too, would like to have a Linux developer put together an image for the Raspberry Pi that would create the DCC signal directly while running JMRI, then output the DCC signal thru the GPIO to a motor controller board.

Linux is not an RTOS

Linux is not an RTOS (realtime operating system). As such, it does not offer *strong* guarantees in execution time. Remember that DCC works by emitting bits with a very precise timing. A program that runs on Linux can be paused at any time when the system needs to do something more critical. To simplify, the CPU responds to interrupts from the display, usb, sdcard, whatever, and these pause the main program for tiny fractions of time. At a human scale it seems like several things happen at once when in reality it's more a succession of tasks.

An Arduino or similar such as an ESP will run its code at a guaranteed rate and will make sure its program executes with a very precise timing. Interrupts can be tightly controlled so the author of a program relying on interrupts knows exactly when things happen.

In practice, that means that trying to write a DCC coder/decoder in userland on Linux accessing the GPIO or so would be a bit amateurish. The timings might work, but they might also be off without control, most of the time. I guess a kernel driver would offer more guarantees but not that much. 

It's not impossible. There is a class of operating system called "RTOS" which do offer these guarantees. There are various RTOS that have been ported to the RPi in some capacity or other. Google them for details. They are in general very much less user-friendly than your average Linux distrib.

Keep in mind that generally speaking the RPi isn't the greatest hardware around. It has a catchy name and gained a lot of hype and coverage, but it's not without design flaws. E.g. the usb and ethernet stacks have their quirks, as does the sdcard thing. It's not exactly the hardware I'd rely for anything critical. Example in point: the sdcard / shutdown thing. Yes most of us will be lucky and most of the time a random power off will do nothing, but that's just luck, and not something to rely about. "Hope is not a strategy" as we say in engineering.

Having multiple "CPUs" is not a new thing. It is actually more common than you think. Your mouse, your keyboard... heck even that tiny SDCard contains an ARM microcontroller.

I think the way Greg has it setup is a very good way -- you have 2 pieces of hardware, each dedicated to what they do best. The DCC++ arduino for proper reliable control and then the RPi for its flexibility in presenting a user interface and running non-critical stuff like JMRI.

Thanks Ralf.....

........for explaining the differences in the two types of hardware.  That makes total sense so I'll live happily with what I have.  Yes, Gregg is to be commended for putting together DCC++ and making it available for the model railroading public.  I am using it on one small layout and have three different versions of the DCC++ Base Station.

Regards,

Real Time is Relative and RT Linux is Real and Deterministic

Actually the processing requirements for DCC are well within the operating capabilities of Linux on an RPi, and, through the use of available timer functions, PWM and associated hardware available on Broadcom 28XX Micros, would be fairly easy to develop. However, driver development is best left to the few engineers who specialize in uPC driver software, and I have but hate writing drivers. In addition, if push comes to shove, there are several version of Real Time Linux kernels compatible with Debian distributions that are running very effectively on RPi's controlling substantially more time critical (or more properly deterministic) applications. In many ways the simultaneous handling of WiFi / LAN and GPU is significantly more demanding than DCC, and since RPi's seem to effectively handle multiple channels simultaneously at data rates significantly beyond those of DCC RPi's can handle DCC.

To put it in a different perspective, the first microprocessor based real time operating system (RTOS) I worked on ran at a whopping 1 MHz where RPi's can easily run at over 1 GHz. Those RCA 1802 processors managed to get us to the moon and and beyond our solar system. Although a gross over simplification - The minimum pulse width for a DCC pulse is 58 microseconds (uSec) or minimum pulse period of 116 uSec which, with RPi's Broadcom ARM processors executing an instruction about every picosecond, means that the processor only has to deal with a DCC pulse about every 58,000 instructions or with hardware timer and PWM support every 116,000 instructions. Now Linux operating systems have a lot of other things to going on, but for a dedicated DCC application, where I do not expect to deal with streaming video, I think there is enough timing headroom.

So now we are down to semantics and a little history where you should see the conundrum of when is an operating system a Real Time System? If you only have to deal with a event every few hundred microseconds then a human can be a pretty good RTOS. It's called driving. If a 1 MHz processor was running real time software (actually where ARM processors execute an instruction almost every clock cycle the 1802 required 16 to 24 clocks per instruction for a execution rate under 100 kHz), how can we say that a processor running  more than 10,000 times faster, even if running Linux, is not capable of running real time processes. I love (trashing) semantics.

I was going to say, there are

I was going to say, there are Linux based RTOS and there are things far more time critical running on non RTOS versions of linux. Look at the open networking standard. Openswitch is not a RTOS.