RaspberryPi + LinkMeter blue sky discussion


 
Originally posted by Bryan Mayland:
Thanks RJ but I think I've actually found another PCB issue that may require a change. The SPI driver always asserts !CE0 when communicating so it will cause the HeaterMeter to reset. I've got to make second version and I'll just redo the footprints to match what's available from DigiKey.
Click to expand...

Just going to throw this out there, if you need to redesign, have you considered making the switch to a ATMEGA32U4? More IO and a 2nd serial port. I only see it in the 44-TQFP form factor tho.

Thoughts?????
 
Originally posted by RJ Riememsnider:
Just going to throw this out there, if you need to redesign, have you considered making the switch to a ATMEGA32U4? More IO and a 2nd serial port. I only see it in the 44-TQFP form factor tho.
Click to expand...
Yeah I really like the ATmega32U2/4 chips, no need for an FTDI cable or anything! I'd really like to keep the project accessible for folks with not a lot of soldering experience and it is a pretty big jump from through-hole to TQFP soldering so I'd like to stick with through-hole components.
 
Why not just use the RPI GPIO in conjunction with a i2c ADC chip (<$3.00) and bail on the AVR all together?

What advantage does the AVR have, besides the ADC?

Build a daughter card for the RPI, load up the image on the SDCard and your ready to go. No flashing the AVR or anything.

dave
 
Originally posted by D Peart:
Why not just use the RPI GPIO in conjunction with a i2c ADC chip (<$3.00) and bail on the AVR all together?
Click to expand...
Because and I2C ADC chip costs about the same as the AVR and doing so would mean a complete HeaterMeter rewrite. That's not a big deal but it would mean abandoning everyone with a system currently and I don't want to work on two sets of code.
 
That makes sense. I was curious if there was a technical reason prohibiting it.

So I guess we will be getting support for a touch screen on the next rev? That way we don't need the LCD which has been a real pain
icon_biggrin.gif


dave

Originally posted by Bryan Mayland:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by D Peart:
Why not just use the RPI GPIO in conjunction with a i2c ADC chip (<$3.00) and bail on the AVR all together?
Click to expand...
Because and I2C ADC chip costs about the same as the AVR and doing so would mean a complete HeaterMeter rewrite. That's not a big deal but it would mean abandoning everyone with a system currently and I don't want to work on two sets of code. </div></BLOCKQUOTE>
 
Bryan (and everyone else) - Thanks for all the great info!
Do you plan to make boards available for purchase, for this solution or the linksys variant? (Sorry if this has been asked, I haven't really come across the question).

I have been following this thread and the previous router based thread for a while now but haven't seen mention of boards for purchase.
I have been tinkering for a while with an all PIC based solution for data acquisition, RF transmission and fan control, just because I enjoy starting from scratch for some sick reason. It is fun to re-skin a cat, but sometimes it just isn't necessary, so I was wondering if you are selling or plan to sell boards once the design hits a point you are happy with.
Thanks!
 
Originally posted by Burt H:
Do you plan to make boards available for purchase, for this solution or the linksys variant? (Sorry if this has been asked, I haven't really come across the question).
Click to expand...
They're not available for purchase from me, but the plans are available in a convenient ZIP file to ship off to Dorkbot for production. You get 3 in a batch though so people usually sell their spares in the other thread at cost ($10). The PCB designs are also available in EAGLE format on github and can be modified freely.

The HeaterMeterPi boards aren't in git yet, until I get them working.

I'm interested in your design! Did you do PWM fan control through a MOSFET like HeaterMeter does, or did you come up with something better?
 
Also, you may want to email the guys at Dorkbot first before you submit your order. They already had some boards printed and I was able to get them a lot faster.
 
Originally posted by Bryan Mayland:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by Burt H:
Do you plan to make boards available for purchase, for this solution or the linksys variant? (Sorry if this has been asked, I haven't really come across the question).
Click to expand...
They're not available for purchase from me, but the plans are available in a convenient ZIP file to ship off to Dorkbot for production. You get 3 in a batch though so people usually sell their spares in the other thread at cost ($10). The PCB designs are also available in EAGLE format on github and can be modified freely.

The HeaterMeterPi boards aren't in git yet, until I get them working.

I'm interested in your design! Did you do PWM fan control through a MOSFET like HeaterMeter does, or did you come up with something better? </div></BLOCKQUOTE>

Ok, thanks for the info, I'll look back at the threads again.
As for my implementation, it is really not too far along yet and nothing compared to what you guys have going here (due to work, family, 3 kids, etc). My initial goal/prototype is data collection for multiple probes (6 total - cooker temp + 5 food probes max), followed by temperature control. I am using a PIC for multiple ADC inputs, and then displaying them to an LCD and transmitting them over RF. The receiver is PIC based too, just to capture the transmissions, check for errors in transmission, etc. I still have to work on getting the data to my linux netbook, to serve as the logger and web server. I may do serial, but want to try usb.
I have been drawn to your solution as the router solves multiple issues (remote access, web front end, etc). But I stumbled onto all this after I had my basic prototype going, so I decided to stay the course as a learning experience. But now with the Raspberry Pi its looking pretty attractive! If only it had Analog inputs this would almost be too easy (yeah right)!
Now to figure out how to get my hands on a Raspberry Pi
icon_smile.gif
 
Got an email today letting me know my boards are back from fab. There's definitely a couple problems I'm going to have to fix but should work for basic testing. That said I got the SPI bus working under OpenWrt


That's a Boarduino with HeaterMeter firmware running off the Pi's 3V3 and connected to its UART and SPI. The UART works so data is coming in but the SPI still needs work to be able to program the chip via hmdude.

Interesting Linux fact, the RasberryPi (Broadcom 2708) uses what's called a platform driver for the SPI interface. That means you can't just build the kernel module and load it because unlike a PCI/USB/etc driver the kernel doesn't ask the driver to probe for the device. Knowing that the bcm2708 SPI bus is only present in the bcm2708 architecture, the architecture is responsible for acknowledging the hardware is present and requesting the kernel load the device module. This is done by supplying platform_driver and platform_device structures and registering them. It is a pretty interesting system which allows for connecting of devices without much intermediate infrastructure (like you'd have with, for example, a PCI bus) and without writing probe logic in the driver.

Why is this important? It means your kernel for the architecture has to be built with support for the platform driver/device in the architecture before it will connect to the device.
 
And we have flashing over SPI without a bootloader! Yeah it totally doesn't work properly but it is communicating and reading/writing. I think I just need to mess with the fuses. 2.1s to write the whole firmware too, that's some serious speed (4Mbit > 115kbit).
<pre class="ip-ubbcode-code-pre">
root@OpenWrt:/tmp# hmdude -P /dev/spidev0.0 -v -v -b 4000000 -U /tmp/heatermeter.cpp.hexA
hmdude: compiled on Jul 11 2012 at 18:54:57
Using port: /dev/spidev0.0
Loading ihex file: "/tmp/heatermeter.cpp.hexA" (22132 bytes)
SPI max speed: 4000000 Hz (4000 KHz)
Device signature: Atmega328P
100% |##################################################| 22132 (2.1s)
</pre>
 
Well Played, Sir.

That would save me $20 on a programmer if my dang rPi ever gets here. Not sure I can wait 10 weeks to run the heater.

This should make live heatermeter firmware updates a breeze.
 
Yeah definitely! Even better you never have to flash the firmware. It sees a blank chip on bootup and ZAM flashes new code. Or it will rather, when I'm done. Bad news is the first boards I made aren't going to work without cutting traces because there's no way to keep CE0 asserted between SPI transactions. Oh well, I can work around it.

Flashing Optiboot takes 1/10th of a second! Why does it take a minute with the USBtinyISP? (Actually you can cut down the time even that takes significantly if you modify the Arduino source to pass a speed to the programmer).
 
I got my first stab at the HeaterMeterPi boards last night and aside from the standard component placement problems which aren't going to be too hard to fix, I've got this problem.


This is how I envisioned the final assembly looking (with all the HeterMeter circuitry assembled on the underside of the purple board). The problem is that the LCD is taller than the button + cap so the LCD will have to stick through the case, which I was hoping to avoid. It can't mount below the HeaterMeter PCB because it is the same height as the Pi's USB jacks. I considered surface mounting it, which gives us a few mm but not nearly enough for the button to be able to make it out of the case. Another option is not mounting it to the board but wiring it with a bunch of short wires. Unfortunately then there's nothing to hold it in place.

I guess it isn't a deal breaker, considering the USB jacks and SD card are going to stick out anyway. I'm just a little disappointed. I looked at chip-on-glass LCDs which are perfectly thin, but they're 20% smaller in display area, and have a different pin spacing and pinout.
 
But the on the good news side: I think it is going to work!

I just barely had time to get it 90% built, popped a blank ATmega in (328 or 328P work now), aaaaaaaaand nothing. Hooked it up to the logic analyzer and remembered that stock ATmega chips come with CDIV set, which means it operates at 2MHz so the SPI bus couldn't talk to it. AHA! Lowered baud to 128kHz and set the fuses and it worked like a charm! I'm so excited but I have dinner plans so the rest will have to wait until tomorrow.

Things are moving though which makes me very pleased after such a long wait to get this project rolling.
 
could you add another button cap, double it up?



Originally posted by Bryan Mayland:
I got my first stab at the HeaterMeterPi boards last night and aside from the standard component placement problems which aren't going to be too hard to fix, I've got this problem.


This is how I envisioned the final assembly looking (with all the HeterMeter circuitry assembled on the underside of the purple board). The problem is that the LCD is taller than the button + cap so the LCD will have to stick through the case, which I was hoping to avoid. It can't mount below the HeaterMeter PCB because it is the same height as the Pi's USB jacks. I considered surface mounting it, which gives us a few mm but not nearly enough for the button to be able to make it out of the case. Another option is not mounting it to the board but wiring it with a bunch of short wires. Unfortunately then there's nothing to hold it in place.

I guess it isn't a deal breaker, considering the USB jacks and SD card are going to stick out anyway. I'm just a little disappointed. I looked at chip-on-glass LCDs which are perfectly thin, but they're 20% smaller in display area, and have a different pin spacing and pinout.
Click to expand...
 
Originally posted by Dave Smith:
could you add another button cap, double it up?
Click to expand...
That's actually not a terrible idea. I guess it would be up to the builder: either you let the LCD poke through or you have to use two button caps.

Also: You can plug 12V into the RaspberryPi's 5V input and not completely destroy it. Don't ask me how I know that.
icon_eek.gif
 
Actually I definitely broke something because the SPI only works sometimes and the UART mostly not at all. It seems to be getting worse the longer I spend trying to track down the problem. I definitely killed an ATmega chip too. DEVELOPMENT!

In good news: RaspberryPi are available for order. The lead time is 5 weeks right now at Element 14. I've placed an order for a new board.
 
You must log in or register to reply here.

 

Back
Top