Archive for October, 2011
I picked up Microchip’s PIC32 ethernet starter kit in order to check out their 32-bit processors as well as to get started on embedded web servers. The free TCP/IP stack from Microchip was my motivation, since it can be used on any of their chips, including the 8-bit versions. I also was interested in the C32 compiler, since it is free. I used MPLAB X for the test, along with the downloadable Microchip application libraries. I have been using MPLAB X for PIC18 development, and I really like it. It’s a nice IDE.
This review will cover getting the SKDE up and running with the TCPIP Demo App from the application libraries in MPLAB X.
I’ve reached the conclusion that this wireless router is pretty much useless. Despite my earlier efforts of heatsinking the processor (which did help), sending email logs when the log was full (unsure if that was useful at all), and updating the firmware to the latest and greatest the thing would still refuse to connect to the WAN randomly.
I did some more digging and figured out that the router doesn’t really have a WAN port, despite the port on the back being labeled as such. The switch controller is actually a six-port controller, and only five are used. Even though the WAN port on the router is physically separated from the other four ports, the switch controller sees it exactly the same as the rest. All five of the ethernet ports on the back are auto-sensing ports so any one has uplink capability. The polarity of the connection is tested during link or when more than three packets are received with inverted end-of-packet pulses. If any of the ports exhibit this behavior the switch controller reverses the port polarity and stores that status in a register. That port then becomes an uplink.
What I figured out was that if the switch ports are used for other devices, the router will eventually fail to uplink. That is, if you use it as an access point instead of a router, it’s fine. When you start using the switch ports it gets confused. I have successfully had the router running for a while by connecting my wired devices through a switch and then uplinking just the switch to port 2, with the router then uplinking to the gateway. Evidently the router’s processor has an issue with its mapped memory.
I’ve now bought a Linksys E2500 wireless N router to replace this thing. You can get refurbished wifi routers at Cisco’s store for about half price.
I’ve been wanting to get diagnostic data from my truck for quite a while, but I haven’t wanted to spend the big bucks on the tools. Recently though I came across the ELM327. It’s an all-in-one IC solution for a scan tool. It even has a UART. You just need a few external parts for different COM interfaces and an OBDII connector. However, the IC itself is $32.50, and you still have to source the OBDII connector, create the schematic, do the layout, make the board, etc. So I decided to try one of the “ELM327 based” products off eBay. It was $20 shipped from Hong Kong, and already has a USB interface.
The product is based on a PIC18, with an FTDI FT232R serial to USB converter. Use FTDI’s driver when you connect it to your PC though. I used the driver included on the CD that came with the tool, and it enumerated as a “high speed USB serial UART” and wouldn’t communicate. I had to use FTDI’s driver removal tool to get rid of it so I could reinstall the correct one.
I tried the device on my truck with a couple different software programs: ScanTool.net, OBD2Spy, and wOBD. However the results were underwhelming, as I got two different sets of codes with the first two and the last program wouldn’t communicate with the tool. ScanTool.net reported P0403, P0405, and P0460. OBD2Spy gave me P0204, P0304, and P0500. Obviously that’s not very helpful.
So I opened up the ELM327 datasheet and Realterm. Realterm is always my favorite terminal program, but in this case I had to switch to Hyperterminal since Realterm doesn’t have the “Append line feeds to incoming line ends” feature. Realterm overwrites everything from the device on the same line.
I started with a simple protocol test, to make sure everything is working. Then I tried pulling PID 05, which is coolant temperature. It responded with the proper value. So I moved on to checking the number of codes. There were two. Finally I pulled those codes. They turned out to be P0204, P0304, and P0500. I’m not sure why the ECU thought there was two codes but listed three. Anyway, OBD2Spy gets the nod here. If you look at the output you can see that the other program was off by one byte, which is why the codes are similar but incorrect.
So the emulator works as advertised, at least in this test. The next problem though is that there are only a handful of previously defined PIDs that auto manufacturers use so that they can get diagnostic tool companies to pay for the extended PIDs required to actually do any useful troubleshooting. In order to get real-time data of detailed systems, you have to pay for software that has the extended PIDs.
- Automotive rear fill “surround sound” with Boss DD-3
- Spring tester / weight scale
- Ducati 749/999 Tail Light
- Instruments for the GSXR
- Light pipe tail light for the GSXR
- M17x 6990m / 6970m overheating
- PAR / Spectrum analyzer
- Acrylic polishing and scratch removal
- 330W power supply for M17x update
- Continuous vs. batch water changes
- April 2017 (3)
- October 2015 (1)
- May 2015 (1)
- March 2014 (2)
- December 2013 (1)
- July 2013 (1)
- November 2012 (1)
- October 2012 (4)
- September 2012 (1)
- August 2012 (3)
- June 2012 (1)
- March 2012 (1)
- February 2012 (1)
- January 2012 (1)
- October 2011 (3)
- July 2011 (1)
- June 2011 (3)
- May 2011 (2)
- April 2011 (1)
- December 2010 (1)
- August 2010 (1)
- July 2010 (3)
- April 2010 (2)
- March 2010 (2)
- January 2010 (2)
- December 2009 (2)
- October 2009 (2)
- September 2009 (1)
- August 2009 (15)