SparkFun Forums

[unexpectedly]

Update: made two changes and I can at least print the 384box.bin file from the SD Card successfully.

Mod 1: I bought this $7.50 12V -> 9V DC converter from Amazon and am using its 9V to feed the printer. I can report it does print faster. I can probably tweak other delays out of the system??

Mod 2: I removed the SPCR=0; from the printGraph function where my setup previously lost its mind.

Observation: My actual problem with the program "losing its mind" was my misuse of SPCR. Coincidentally, 5V really isn't enough to feed that printer. What sucks is I built my design around that nifty 5V/12V power supply. Ah well.

Current status: I can print the sample empty box in its entirety from my function. The print stalls in the middle and pauses for quite some time. The thermal.h code has a lot of delay added in which probably can be removed now that I'm using proper 9V power. So now I can go back to trying to read in the sample empty box, altering the few bits I need, then writing it to the SD Card to then be read and fed to the printer.

I just discovered chipKIT and its uC32. With 32K of flash, I can handily process a 19K array all within SRAM and be rid of micky-mousing around with the SD Card. It shows up tomorrow... we'll see if all this stuff is really "easy" when I transfer this reality over to there!

Next steps:
1) Try the uC32 and see if it works. I also ordered the proto board so I can attempt to rebuild my whole setup on the ChipKit stack.

2) If that doesn't work, I'm going to try and make SPI RAM work for my Mega. I'm really really over my situation of being size limited when trying to output the graph to the thermal paper. I would already be done with this project if the Mega had 32K of SRAM. ANY manufacturer making their own Mega really should find a way to get the "external" SRAM on-board, even if unpopulated. My Seeedstudio Mega has plenty of room for it on the PCB.

I have looked at Raspberry PI, the PC Duino, and the Beagle thing. I really don't want to have my gizmo running linux and to have to boot up. My first real SE job had vxWorks running on our equipment and I swore off ever using anything OS-like for embedded.

[unexpectedly]

Sweet! The chipKIT uC32 can physically interface with my project AND let me use normal headers on the Adafruit 1.8" TFT and not need to run the 4 SPI wires separately:

tps_bench_chipKIT.png

Here's the PDF user manual / reference to the chipKIT uC32.

[unexpectedly]

Hooked up the chipKIT uC32 and was able to make my personalized SOS blink example work. I put new headers on my 1.8" TFT so it could plug in to pins 10, 11, and 13 to get SPI. Annnnnnnd... it didn't "just work"...

I'm using the Adafruit_GFX and _ST7735 libraries and there is hardcoded AVR-specific SPI commands in them that it looks like I'll be converting to chipKIT. And the mpide/processing IDE chipKIT is using complained pretty heavily about converting variables from uint32_t to uint8_t, etc etc. But there are only a handful of those, not like my first vxWorks project where we had like 300 compile warnings we were told to fix...

I couldn't get the UTFT lib working, either. Then again, it never worked for any of the graphics shields I have bought, so GOT ME THERE.

Here's my "help me" post on Ada forums if you're curious, bored, or need to hurt the brains.

[unexpectedly]

Oooooo shiney:
http://www.digilentinc.com/Products/Det ... d=PMOD-SF2

16MB of SPI memory for $20

[unexpectedly]

YES!! Got the TFT working in chipKIT! It was a tad more difficult than I wanted, having to remove all AVR-specific code from Adafruit_GFX and Adafruit_ST7735, but over 3-ish days I was able to learn enough about it all that I got it done!

From here, it should be fairly simple to get back to where I was before the platform changed from Ardunio Mega to chipKIT uC32: solder up a new proto shield, re-wire up the power and SF "Easy Driver" then port over the thermal library. Now that I've gotten a fair idea of AVR-speific things and already have hacked my way through Thermal before, I'm hoping that won't be painful like the ST7735 was. :pray: Part of my problem with the ST7735 TFT was I don't know diddly about SPI and also didn't realize the TFT uses an additional 1 or 2 pins beyond SPI. I kinda based my SPI off of my experience with the SF I2C real time clock and didn't think outside the comms protocol.

Observations:
» Initially I thought Digilent DSPI library didn't work, so I developed on their SPI examples. I eventually noticed the LED for pin 13 blinking appropriately for what my loop() was doing... so I hit reset and it started working!!!
» I ended up removing ALL DELAYS from Arduino-land! And also running SPI at the fastest speed (40MHz?).
» Initially, with the SPI clock divider at 64 and all the delays, the code was slower than Arduino communicating with hardware SPI to the TFT shield. Now? It is obviously and appreciably faster -- so much that a fill screen is almost a blink, the curtain falling effect would be missed by anyone not looking for it.
» Attached zip archive has both my DSPI and SPI library examples. The current ST7735 library is the DSPI copy and is more recent than the SPI example. In the SPI version, I didn't remove any and all references to delay.
» When hitting RESET button on the shield, the sketch gets into loop() in approx 3 seconds.
» When powering up the chipKIT by plugging in the USB, the sketch gets into loop() in 6 or 7 seconds.

NOTICE: I did not perform complete and total tests of every feature and nuance of the code. I got it to print my text! All the Adafruit functions should work, given how everything is coded and structured...

To use my files, download Digilent's latest mpide IDE (which I put in Documents\mpide-0023-windows-20130715), make a Documents\mpide folder, unzip my file into there. It will make a Libraries and tft folders. Then make a desktop shortcut to mpide-0023-windows-20130715\mpide.exe Drag and drop the tft\tft.ino sketch onto the desktop shortcut and it should compile out-of-the-box. Mpide is a lot like Arduino IDE.

You are all welcome to use the attached code in any way shape form or fashion to help support your products (said to chipKIT, SparkFun, and Adafruit). I release it into the public domain.

[unexpectedly]

I hate to say it but I am regretting the choice to switch to the chipKIT based hardware. UNLIKE what everything says, Arduino does not run on it. Oh, my blink.ino example did. But nothing which actually matters does. Their fans and forums say to use DSPI lib for SPI, however, I couldn't get it to work at all. But the standard SPI I was able to get going.

Now, I'm trying to get the uC32 to talk to the Sparkfun Real Time clock via I2C. It is being more difficult than SPI!!!! What the hell?!? That RTC was the easiest thing I have ever done in Arduino! It was faster to get working than getting out a breadboard and wiring up an LED! Seriously! When I set it up on the Seeed Mega, I turned on the soldering iron, put a 4 pin header on the Mega's I2C pins. Then cut a 4 wire CD audio cable, plugged it onto the header so the Vcc pin was the red wire. Then soldered on the wires accordingly to the RTC. Cut n paste code. BAM! Done!!! Bob's your uncle.

Here's my post asking for help in chipKIT land. On that thread are fancy pics of the RTC module and my new shiny NKC Electronics Arduino proto shield. Rather than take apart the actually working hardware in the Arduino stack already built in this thread, I bought a new proto shield and easy stepper driver. I'm pretty good with the soldering iron and hot air station, but I thought it best not to take apart what was already actually working before I had this up and running. Good choice!

BTW, I bought this NKC proto shield because not only does it have the buses and linked rows of holes (a la breadboard), it has an area of I2C in the bottom corner. I'm using the row most inboard for the right angle 4 pin connector for the RTC module and then the next two rows, I have pull-up resistors on clock and data.

Sorry for sounding like I'm whinging or something, but come on, I was really expecting something a little better. I'm now contemplating hand coding I2C protocol on pins 4 and 5 thinking that might be faster than trying to convince their "libraries" to actually work.

[unexpectedly]

A shiny new FEZ Cerbuino Bee showed up today. I am pretty anti-m$ but seeing the comments a few people have made and the appearance of great community support, I thought I wouldn't dismiss .NET products entirely. Just because of .NET, I never looked twice at Netduinos.

First impression of FEZ / GHI Electronics: good luck making the development tools work. Today was spent installing uninstalling and reinstalling microsoft visual studio 2010 express and 2012 and all kinds of .NET SDKs and whatnot. Phew... I can only guess that the people who wrote their "getting started" pages haven't gone back to try it again. The last time I intentionally used MSVC was in college in the previous century.

Since I have a proper Netduino 2 is showing up Monday, I'm now reinstalling the tools for it. I'm wondering if I can get either the chipKIT or FEZ Cerbuino to talk to the RTC module by then??

My current product ratings:
chipKIT : B- it only misses a proper failing grade for at least providing a build environment. So far, I cannot recommend chipKIT based on its unfriendliness (IE, things like I2C don't work) and the very small community supporting it isn't enough. I was literally the 3rd person on the internet to make the Adafruit TFT shield work with it! The guy helping me the most bought one as the result of my work.
GHI Electronics FEZ Cerbuino Bee : F sorry guys, you fail. If I can't blink an LED on your product, who can? A tenured .NET developer?? Double-you Tee Eff!

[unexpectedly]

I got a really late reply on the GHI forums saying the firmware needs to be updated on the FEZ thing I bought. :shifty: ummm, really? And they started piling on bagging on me for expecting to open the box and it working without having updated the firmware. I was so bitter that on my way to work I stopped at Radio Shack and bought the Netduino Make Kit on the shelf for $79. Oh wait, I followed the steps on their site and it worked on the first try. Shocker. So I posted a mildly snarky picture in return with 10 targets at the top that could blink a LED without firmware updates ... and the Cerbuino at the bottom which couldn't. Oops it disappeared, not on the forum any more?

Meh. .NET takes forever to compile and "deploy" and then the target doesn't always take the deploy so the procedure is unplug USB, deploy in MSVC#, plug in USB, wait.

So I went back to chipKIT and was able to immediately get my I2C code to read the real time clock.

So we're back on chipKIT... the dev cycles on trying to get things going on .NET isn't going to work for me right now, but they've got LOTS of code, LOTS of RAM, so isn't a total write off.

[unexpectedly]

A month has passed and I got it done. Big thanks to majenko on chipKIT forums for his help with the TFT and my other various problems.

majenko talked me into hosting my ST7735 code on Github and he's developed an entire TFT library!! Incredible work. Once I figure out the commands, I'll put up my Thermal library there too.

Then I spent a week working on my struct based menuing framework. It might seem like a bit of work at first, but once you've got it going, it's super easy to add, change, remove, and move menus around. As many options as I've added and changes during the project, getting this working was totally worth the hassle.

The results:

tps2_pf09_good_640.jpg

As I tested hundred or so of each of my throttle position sensors, I honed the math which determines if a TPS is good or bad. I've got the stepper motor doing 10 microsteps via a 1:3 gear to the TPS, so that works out to about 3/4 of a degree per "step" of my test. I found a "RunningStats" Library which made quick work of standard deviation and average for me.

The TPS shown is non-linear, so I treat it like two separate lines. I find the knee then run the same tests on the steep and shallow parts of the response plot. I make the test on the steep slope slightly easier than for the other slope.

tps2_pf09_good_tft_640.jpg

[unexpectedly]

Some usability developments as I worked on finishing up the project:
» When a TPS is bad, I don't print out the report. Printing takes 10 seconds and I'd often re-test a few times.
» Detect if starting a test and the TPS doesn't react. Some are simply "open" and the shaft would turn forever; TPSs only have 90° of throw, so it's hard on the parts. If a TPS doesn't react within 30°, the test turns off the stepper and tells the operator something went wrong.
» When retesting TPSs, bad ones often clean up and become consistently good
» I set up an automatic retest (with menu configurable # of retests) for when a TPS is bad. This often leads to a good report coming out; see the picture below.
» I monitor the ADC once a test is finished. Rather than stay at the screen with "Press any key" all the time, unplugging the current TPS acts like pressing a key and the program returns to the menu, waiting for keypress to start the next test.
» Added a "skip detector" for when a TPS's return spring overpowers the stepper motor. This also helps if a TPS doesn't have the 100% expected final value. The code then adjusts to the slowest stepper motor speed and re-tests with maximum power. So far, this has been 100% perfect.

tps2_pf09_retest_640.jpg