I have these boards: [attachment=2]This is an STMicro eval board with the accelerometer.
This is the other STMicro board I got over the summer: [attachment=1]
And this is my Beaglebone that I will use as an NTP server. This was supposed to be my summer project, but I couldn't get all the parts I needed in stock all at once. <sigh> I'm afraid this will be prologue when I get my Pi in a month.
The code is finished, I just need to finish the documentation and package it--work has not been kind to me. I understand about abundance of caution and was glad I could verify its safety for myself--it's running 24/7 on my computer desk, and I don't want it to cook anything either!
I've rewritten the firmware on my #twatch to implement a simple SNTP display. [attachment=0]
I've wanted an SNTP display clock for a long time. I work at a cable TV access facility and time is very important to us. Commercial NTP displays are very expensive, and until recently, we could not even consider any sort of NTP server.
While the #twatch is not the ideal display I envisioned, it was an excellent first try on my part. I had to make some simplifications due to the lack of configurability and the limitation of the flash memory in the Microchip controller. The clock only displays UTC, and in the American format at that. The display uses the default pool.ntp.org addresses to get its time from; it's not possible to specify a custom NTP server. (Both I and my workplace each have a Garmin GPS module and an NTP server, which were, ironically, much cheaper and easier than a display has proven to be!)
Code-wise, I removed Ian's twitter parsing code, and implemented new clock code using the UnixSeconds value that the Microchip stack provides, and the date/time determination code from a Maxim appnote. I added some routines to Ian's HD44780.c to display zero-filled and space-filled number fields.
In main.c, my code monitors the tick count (and monitors the state of the LCD server) and calls my clock display code once a second. The clock display code gets the Unix seconds from the stack and does the arithmetic to get the day of year, day of week, month, day, year, hours, minutes and seconds, which are all sent to the LCD (with English abbreviations for month and day.) Otherwise, main.c is very similar to the #twatch with the addition of some human-readable display state codes.
The LCDTCPServer.c code is nearly as-is--I added some debugging code to display the status of the LCD Server state machine as a single character on the LCD, since I had some trouble with display codes being lost. (The cause was due to some settings on my managed switch that the module is connected to; this problem would not be seen on a consumer router.)
I don't have Microchip programming hardware so I depended on the TFTP bootloader. I used the LCD itself for debugging quite a lot, and did a lot of commenting out until I got a time display that worked and counted. (The numeric display code proved to be the long pole in the tent. The LCD Server code was another thing altogether!)
I maintained full compatibility with the Matrix Orbital emulation on the original #twatch. Since I am in a Windows environment and I am a sysadmin, I wanted to use the LCD emulation in my management software. I wrote a module in PowerShell that accesses the display and allows scripts to interact with and use the display for notifications.
I fully implemented the MCHP discovery protocol in my Powershell code--I'm proud of that--so that it's not necessary to get the IP display on the #twatch to find its address, though I maintained that function. In my module, one function will send a MCHP broadcast to the device, get its IP address, and return it to the script as an object to supply to the other modules to clear the LCD, display text, position the cursor and so forth.
I've collected many different dev boards over the years, but this is the first project I've actually gotten to complete. While my clock doesn't have the big digits I wanted, or the NTP serving capability (that is next), I'm very happy with how it came out. It looks striking, and would be even more so if I had farmed out the case (I am so not good at mechanical design!) It's always good to have a first time and get through it--the next time will be easier, no matter what platform I work on!
(BTW, to put a question to rest here: Heat has not been a problem with my enclosure, which is considerably larger and deeper than the device itself. The #twatch barely gets warm. I'm using it with a Phihong 7.5VDC wall plug from Mouser. I have commerciallly-designed network hardware that you could cook off of! Why the #twatch is such a hazard and my oven-hot DSL modem isn't, I have no clue... I'd like Ian to have a talk with the engineers at Westell.)
The case I used (Bud NEMA box #PN-1332C from Digi-Key) is very similar to the one that Seeed Studios sells (ACC1319TB). It's wider than the LCD board by about 3/4" on both sides left and right and 1/2" wider on the top and the bottom. The depth of the case vs. the board is about 3/4".
In other words, there's lots of room around the board, particularly if you mount it on the transparent top cover as I'll probably do. The cover is gasketed, which won't be a lot of good if I put holes in the side for the ethernet and power cables.
I've been running the #twatch for a few hours propped inside the box. The temperatures haven't changed much from my initial tests in free air. What's most important is the big volume of air inside the box. I'm measuring 95 degrees F behind the board.
This seems to be nominal. A lot of overclockers would find these temperatures too cool! :)
In my other life in IT, I'm used to seeing board temps on workstations and servers be around 95-100F. I just measured the bottom of my DSL modem.
It's 107.5 degrees F.
Its power supply isn't even in the case; it's a wall brick like every other device. It had to have passed UL certification. I've had DSL for 9 years with that same modem and I'll never know why that modem didn't burn a mark on my desk.
The #twatch in its case is going to feel warm and I don't recommend wrapping it in a blanket. But I believe it'll be safe.
UPDATE: I rolled the library back to 5.20b. The project built. I'd stay with this version unless someone tells me otherwise. I have no clue why one version of the stack is "betterer" than the other; I just want the newest one that works with this particular hardware.
BTW, How does the "Objects - TCPIP Demo App-C18" folder in my build directory get named? I hate IDE's that seem to have some super-secret setting from which they pull the project name from. It isn't a demo app! It's "David Moisan's Brickware", I want to call it what I want and not have some leftover setting from who knows where? Of course the manual's no help.
I'm trying to build the original firmware (v0e) for the #twatch before I start modifying it. I cannot get a build.
I get these errors. I've redacted some banner and informational messages:
[code]MPLAB C18 v3.40 (evaluation) [...] C:Microchip Solutions v2011-10-18MicrochipTCPIP StackTCP.c:1454:Warning  type qualifier mismatch in assignment C:Microchip Solutions v2011-10-18MicrochipTCPIP StackTCP.c:4606:Warning  type qualifier mismatch in assignment C:Microchip Solutions v2011-10-18MicrochipTCPIP StackTCP.c:4619:Warning  type qualifier mismatch in assignment [...] C:UsersdavidmoisanDocumentsdevtwatch-v0emain.c:72:Warning  type qualifier mismatch in assignment C:UsersdavidmoisanDocumentsdevtwatch-v0emain.c:80:Warning  type qualifier mismatch in assignment C:UsersdavidmoisanDocumentsdevtwatch-v0emain.c:181:Warning  type qualifier mismatch in assignment C:UsersdavidmoisanDocumentsdevtwatch-v0emain.c:191:Warning  type qualifier mismatch in assignment C:UsersdavidmoisanDocumentsdevtwatch-v0emain.c:201:Warning  type qualifier mismatch in assignment C:UsersdavidmoisanDocumentsdevtwatch-v0emain.c:211:Warning  type qualifier mismatch in assignment [...] C:UsersdavidmoisanDocumentsdevtwatch-v0etwatchv1.c:283:Warning  type qualifier mismatch in assignment C:UsersdavidmoisanDocumentsdevtwatch-v0etwatchv1.c:287:Warning  type qualifier mismatch in assignment C:UsersdavidmoisanDocumentsdevtwatch-v0etwatchv1.c:530:Warning  type qualifier mismatch in assignment C:UsersdavidmoisanDocumentsdevtwatch-v0etwatchv1.c:533:Warning  type qualifier mismatch in assignment C:UsersdavidmoisanDocumentsdevtwatch-v0etwatchv1.c:536:Warning  type qualifier mismatch in assignment C:UsersdavidmoisanDocumentsdevtwatch-v0etwatchv1.c:538:Warning  type qualifier mismatch in assignment C:UsersdavidmoisanDocumentsdevtwatch-v0etwatchv1.c:549:Warning  type qualifier mismatch in assignment [...] MPLINK 4.40, Linker Device Database Version 1.3 Copyright (c) 1998-2011 Microchip Technology Inc. Error - section '.udata_StackTsk.o' can not fit the section. Section '.udata_StackTsk.o' length=0x0000000b Errors : 1
Link step failed.
Here is the partial map:
MPLINK 4.40, Linker Linker Error Map File - Created Sun Nov 13 23:22:21 2011
*Warning* - This is only a partial map file due to a link time error. Only sections which were allocated prior to the error are shown below.
I did some investigations myself as I got the #twatch to use as a 24/7 server status display, rather than for Twitter.
I am using a 7.5V/1A wall plug switcher from Digikey, and I am using a Bud NEMA box #PN-1332C for the enclosure. (I wish I'd had the box before I posted this, but I didn't put it on my last order from them so I had to try again.)
This is a NEMA rated box designed specifically for these kinds of devices. Unless the LCD bursts into flames, it's very unlikely that the enclosure is going to be hurt or even browned by the regulators on the #twatch.
In free air, with an IR thermometer, 125 degrees F is the hottest area on the device, over the two linear regulators (no surprise). The CPU is around 90 degrees F, and the LCD surface is around the same temperature. I had the #twatch running for about two hours with the backlight fully on, before I took these readings. Again, I would have tested it in a case if I had one, but this was in free air (propped on my workbench).
This presumes a normal home or office environment, of course. My device will likely sit on my computer desk nestled between my router and my managed switch, behind the flatscreen. (I wish the person that started this thread would talk with Westell--you can make toast on the top of my DSL modem, it's that hot!)
I'm concerned about reliability more than safety, and maintaining the backlight's lifespan for the few years I will probably use the device. To that end, I'm thinking of modifying the board to use a power switch; turn it off when nobody's watching.
Other possibilities are to dim the backlight if no updates have been received in the past 10 minutes, or even to employ a rudimentary time-of-day routine to turn off the display from 0000 to 0800 local, say. It's very likely I'm going to rewrite the firmware for my specific needs anyway.
I feel safe running this 24/7 with the power supply and case I am using with it. Whether it will stay working for three years is something I don't know yet (anyone have a environment chamber?)