From: <rli...@at...> - 2013-08-31 21:29:34
|
Hello, Here's some hardware that should be able to control relays via ethernet. Can't say how good they may be since I haven't used any personally. Also their choice of software tool chain seems a bit odd, but without having tried them I really shouldn't be critical. https://www.ghielectronics.com/catalog/product/349 for $30, mainboard https://www.ghielectronics.com/catalog/product/333 for $20, ethernet shield https://www.ghielectronics.com/catalog/product/391 for $60, 16 mechanical relays A little over your target of $99, but having a working prototype should help speed up your design cycle. Rich. |
From: donhamilton2002 <don...@gm...> - 2013-09-01 19:39:16
|
Found this on ebay: http://www.ebay.com/itm/IOS-Android-Smartphone-control-4-Channel-Wireless-Relay-Kit-for-Cars-WIFI-AP/321191029473?_trksid=p2047675.m2109&_trkparms=aid%3D555003%26algo%3DPW.CAT%26ao%3D1%26asc%3D142%26meid%3D962216198496163743%26pid%3D100010%26prg%3D1076%26rk%3D5%26rkt%3D15%26sd%3D190587779059%26 |
From: Rich B <ric...@at...> - 2013-09-08 21:03:35
|
Hello All, Here's a question, would it make sense to run a memory test of a microprocessor, such as the 8052? For example, on power up, write a pattern of bits to each RAM location and then read back the pattern to verify that each byte of RAM is working properly. With only 256 bytes of RAM in the typical 8052, it wouldn't take long to test the RAM. Would it make sense to write such a routine in C or would it better to use inline assembly? Several other questions then come to mind, such as what do you do upon a failure. Likewise is there some way to perform a similar test on read only code memory or on in system programmable flash memory? Just curious what other people have done in this area. Thanks! Rich. |
From: Georg O. <ge...@ot...> - 2013-09-08 22:25:52
|
Mem test dunno ... but checking rom or flash with a checksum like crc is quite common Gesendet mit AquaMail für Android http://www.aqua-mail.com Am 8. September 2013 23:03:31 schrieb Rich B <ric...@at...>: > Hello All, > > Here's a question, would it make sense to run a memory test of a > microprocessor, such as the 8052? > > For example, on power up, write a pattern of bits to each RAM location and > then read back the pattern to verify that each byte of RAM is working > properly. With only 256 bytes of RAM in the typical 8052, it wouldn't take > long to test the RAM. > > Would it make sense to write such a routine in C or would it better to use > inline assembly? > > Several other questions then come to mind, such as what do you do upon a > failure. > > Likewise is there some way to perform a similar test on read only code > memory or on in system programmable flash memory? > > Just curious what other people have done in this area. > > Thanks! > > Rich. > > > > > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Dave M. <mc...@ne...> - 2013-09-09 00:53:24
|
On 09/08/2013 05:03 PM, Rich B wrote: > Here's a question, would it make sense to run a memory test of a > microprocessor, such as the 8052? > > For example, on power up, write a pattern of bits to each RAM location > and then read back the pattern to verify that each byte of RAM is > working properly. With only 256 bytes of RAM in the typical 8052, it > wouldn't take long to test the RAM. > > Would it make sense to write such a routine in C or would it better to > use inline assembly? I'd use assembly for something like that. One typically wants a RAM test program to be as small as possible, for obvious reasons. For a high-rel system, I'd do it. Bear in mind, however, that effective testing of a memory subsystem requires some knowledge of how it's implemented, to know what types of errors it makes sense to test for. For example, to test for adjacent-bit errors, one needs to know what bits are *actually* adjacent to what other bits. It can be an interesting in-depth exercise. > Several other questions then come to mind, such as what do you do upon a > failure. Sit and blink an LED.. > Likewise is there some way to perform a similar test on read only code > memory or on in system programmable flash memory? As another list member noted, this is usually done by storing a checksum somewhere in the firmware load, and computing/testing it. That's pretty effective, and very commonly done. -Dave -- Dave McGuire, AK4HZ New Kensington, PA |
From: Duncan B. <dhg...@fa...> - 2013-09-09 01:16:01
|
> > Several other questions then come to mind, such as what do you do upon a > > failure. > > Sit and blink an LED.. > > -Dave "I'm sorry Dave, I'm afraid I can't do that." ;) -- Duncan Bayne ph: +61 420817082 | web: http://duncan-bayne.github.com/ | skype: duncan_bayne I usually check my mail every 24 - 48 hours. If there's something urgent going on, please send me an SMS or call me at the above number. |
From: Dave M. <mc...@ne...> - 2013-09-09 01:23:41
|
On 09/08/2013 09:15 PM, Duncan Bayne wrote: >>> Several other questions then come to mind, such as what do you do upon a >>> failure. >> >> Sit and blink an LED.. > > "I'm sorry Dave, I'm afraid I can't do that." > > ;) ROFL!! Nicely done. :-) A big, red, ominous-looking LED. :) -Dave -- Dave McGuire, AK4HZ New Kensington, PA |
From: Rich B <ric...@at...> - 2013-09-09 02:28:01
|
On 9/8/2013 9:23 PM, Dave McGuire wrote: > On 09/08/2013 09:15 PM, Duncan Bayne wrote: >>>> Several other questions then come to mind, such as what do you do upon a >>>> failure. >>> Sit and blink an LED.. >> "I'm sorry Dave, I'm afraid I can't do that." >> >> ;) > ROFL!! Nicely done. :-) > > A big, red, ominous-looking LED. :) > > -Dave > That is definitely funny! Rich. |