RaspberryPi + LinkMeter blue sky discussion


 
I started with an Ubuntu Server x64 10.04 VM, but after I was confident that the whole build process was self-contained, I copied everything over to my media center PC, which runs the latest Ubuntu Desktop. I'm not a big fan of the "Unity Desktop" they include but I do everything over ssh / vi anyway so it doesn't bother me much. Any heavy lifting text editing I need to do (mass reformatting, complex replacement, etc) , I use Notepad++ on my windows machine and save it over SMB/CIFS.

I got my second try boards already! 12 day turnaround is just amazing, and they included a few promotional SOIC/TSOP to through-hole converters. I can't say enough good things about those folks.

Bad news is I am apparently growing more incompetent as time goes on. I can't believe I made the my very first 2 PCBs for HeaterMeter v3.0 and v3.1 and only had minor silkscreen issues, yet this board continues to be a problem. 3 large stupid problems:
-- The part for the probe jacks I made should have 2 large holes and 1 small hole and I did it the other way around.
-- The RCA jack as the wrong pin assignments. I got this part directly from the SparkFun EAGLE library and I can't find one with this footprint so I'm pretty sure they're the problem.
-- I somehow re-positioned the LCD connector 0.1" closer to the front of the board which means it juuuuuust doesn't clear the Pi's composite output

Minor things I need to look into more (I was already up until 1AM by this point)
-- The serial AVR TX is working but I don't think the RX is
-- The power and blower jacks are too close together to use comfortably
-- RCA jack silk is on wrong side of board
-- LCD untested

Good news is that the Boxy Robot image came out OK though!
 
That seems like mixed news, but thanks for the update. Sounds like those boards would still be usable with a bit of tweaking. Soldering 'remote mount' cables to the LCD will get it up and running, and swapping RCA at the cable end is not too big of a deal for testing. It sounds like it is very close.

I dual boot ubuntu, I REALLY wish VMWare would let you boot a vm from a partition on a local disk. There must be some challenge there that I do not understand, but I hate to run a vm identical to my second boot partition so that I can run it while still using windows for work. Also, I'm not a fan of the new desktop they put in in version 12 or so.

One other thing...

I do everything over ssh / vi anyway so it doesn't bother me much. Any heavy lifting text editing I need to do (mass reformatting, complex replacement, etc) , I use Notepad++ on my windows machine and save it over SMB/CIFS.
Click to expand...

I'm not sure if you have used it, but you should install Xming Remote X Window server... when you ssh in via Putty in windows, you can check an option for "X11 Forwarding", and then when you open a graphical window such as `gedit`, you get the gui on your local machine, but the filesystem and processing is done on the remote computer. It is nice for those times when you really need a gui for something but do not want to change machines or worry about mapping drives over the network.
 
Actually you should be able to boot a Ubuntu VM from a physical partition in VMWare. You need to set up a small virtual disk as your "boot drive" where GRUB will install the boot loader then have the second virtual disk of type physical. The reason it can't boot it directly is because the GRUB loader if installed to your main physical drive (installed to /dev/hda) points to that other partition (/dev/hda2 for example), which has no boot loader installed. Installing GRUB to a separate VM drive may allow it to work. The larger problem I'd say would be the completely different hardware in the VM vs the physical machine.

I used to do remote X windows like 10 years ago but I can work in vi over ssh almost as fast as I can in gedit. I prefer Notepad++ over gedit by a large margin anyway.

The boards are still probably usable. I'll have to see what's up with them tonight because I got started so late last night when I ran into problems I didn't have the time to work them out. The RCA jack is simple, just cut the extra trace. The probe jacks, the datasheet lies. It clearly says "2.1" and then "1.6 2 PLCS" which totally says two small one large. The LCD header... I can't wait to get home and look at again. I checked the board file and it is still the same distance from the Pi expansion header so I can't understand why there's a collision now and not on the previous PCB. The serial is another real headscratcher. Hopefully when I look into that tonight I'll see I just tested it incorrectly.
 
Thanks for the suggestion on GRUB.. You are right about the hardware though. I'm up and running with Ubuntu 64bit so I can get familiar with OpenWrt.

Edit: So far so good. I got my first image built in OpenWRT. What an excellent system, I see why you use it over customizing the base rPi image. Still working out all the pieces though.
 
Last edited:
Yeah the OpenWrt build system is the major reason I picked it over DD-WRT which is just awful. DD-WRT has a longer list of compatible products but don't try to extend the system because it isn't made for that. Wrt is designed around integrating whatever you want into it and the build process is frustrating as hell but I'm sure that is true of any distribution that tries to incorporate other random projects.

Oh hey good news, the serial ports are working fine on the new PCBs after all. It was just the web interface which I have broken, possibly with the checksum code now that I think about it. There are still physical dimension problems but at least electrically it isn't too bad.
 
Everybody laugh it up, because I just placed an order for my third set of HeaterMeter v4.0 boards. Fixes:
  • Larger drill holes for the probe jacks, let's hope not too big
  • Proper pinout for blower RCA
  • Blower RCA moved apart from power input jack
  • LCD header moved up 0.05", let's hope that is enough
Boards go out on Aug 10th, so optimistically I'm looking at the 20th for the earliest I'll get them. That should give me some breathing room to get the software more bug-free by then.

Here's a fun "Did you know?" I learned last night: Setting the tty to "raw" mode doesn't disable echo. On both the WRT54GL and rPi platforms, the tty was echoing back all the data it got from HeaterMeter (actually even more data than it got), which probably contributed to the "tty overrun" error I was getting at higher baud rates.
 
Bryan Mayland said:
Everybody laugh it up, because I just placed an order for my third set of HeaterMeter v4.0 boards. Fixes:
  • Larger drill holes for the probe jacks, let's hope not too big
  • Proper pinout for blower RCA
  • Blower RCA moved apart from power input jack
  • LCD header moved up 0.05", let's hope that is enough
Boards go out on Aug 10th, so optimistically I'm looking at the 20th for the earliest I'll get them. That should give me some breathing room to get the software more bug-free by then.

Here's a fun "Did you know?" I learned last night: Setting the tty to "raw" mode doesn't disable echo. On both the WRT54GL and rPi platforms, the tty was echoing back all the data it got from HeaterMeter (actually even more data than it got), which probably contributed to the "tty overrun" error I was getting at higher baud rates.
Click to expand...

Do you need any button boards to go with all the boards you have ordered,j/k lol.
 
I tried to flash my rPi with the newest Openwrt image, without much luck. After much reading, frustration, and general discomfort, I decided the problem is my SD Card. I was trying to use an old 2GB Sandisk that came with my laptop, as to not 'waste' a good 8gb on this project when even a 256 would suffice. Turns out the rPi is a picky little B. Firmware updates to the GPU code (start.elf) and (kernel.img) have fixed many of the problems, but even the newest code still crashes out on my card once in a while.

I have another 8GB card full of photos that I need to clear off, so I'll do that tonight and give it a go. 8GB Class 10 SDHC cards are below $10 now (when did that happen?!??!), so I'll pick one up to replace the one I steal from my spare camera if it works out. Just beware, if you plan to use some old junky card like the one that came with your elliptical machine, have a backup on hand so you don't lose a night of hacking over a $10 card.
 
Yeah actually I only have 1 card out of 4 that works really well with the rPi. The OpenWrt kernel is actually even more picky about the SD card you use, on account of it not yet containing many of the fixes that are in the raspberrypi git yet. Figuring out the best way to do that is pretty high on my TODO list, right after getting the 8192cu driver working perfectly with the wifi config subsystem.

The 115200 was still a no-go, 2 errors overnight. That's a lot lower than it was, which was a few to a few dozen every hour. I'm testing now at 57600, and will leave that running over my vacation and see if there are any errors. I might just go with the 19200 which I know works though.

I've also built in an auto-installer so the first time you boot (or install the linkmeter package), it it detects a blank ATmega chip it will install a version of HeaterMeter on it like magic.
 
Excellent! You are quite the service oriented programmer.

Isn't the process to update the boot loaders and kernel to the newest version simply copying over the current kernel.img and start.elf files to the vfat location? I would know this for sure, but I had very mixed results. It might be worth locking into a git version of the kernel and having it update to that... then you dont have to rely on openwrt to keep up to date.
 
I don't use the rPi kernel kernel from git, because a lot of the OpenWrt networking stuff is pinned to a kernel version (3.3.8 currently) so you've got to build the kernel yourself. The process takes a stock 3.3.8 and applies your platform patches to it. The platform patches are from like 4 or 5 months back and it isn't straightforward to try and generate new patches from the rPi git. You can export the diffs but then you have to manually adjust them to apply them to Linux 3.3 instead of Linux 3.1.

But yeah all you have to do to update the kernel is replace kernel.img. I don't know where start.elf comes from, but it isn't tied to a particular kernel version so the OpeWrt build process just pulls a specific version from the rPi git. What we're really hoping for is for BCM2708 to get accepted into Linux mainline before OpenWrt releases "Attitude Adjustment" and pins to a new kernel version.
 
Start.elf comes from "the foundation", and is a binary blob. From what I've read, it is code that lets the gpu mount the vfat filesystem to boot the kernel.img, which then boots and points to your ext4 partition to establish the rootfs to boot from. Maybe I'm off a bit on that though. I did notice the new versions have a 240mb split now. I read before that a 224 arm/gpu split was maxium to keep a 1080p frame buffer, but maybe someone optimized that, who knows. Not that the extra 16mb will really be needed in our implementation, never hurts though.
 
Bryan,

I failed again with a PNY SDHC Class 10 8GB this time. :( I get card init errors and such.

Just to be sure I am not doing something stupid... I am flashing openwrt-brcm2708-sdcard-vfat-ext4_224.img from your site, I've tried various versions, one from just now, and one from a few days back.

I am able to boot Wheezy on both cards without a problem.

I don't mind spending $10 on a card that will work with the old kernel... do you know which you are using? It looks like the transcend 8GB supposedly works, as well as the Amazon Basics 8GB.

Transcend: http://www.amazon.com/dp/B003VNKNEG/?tag=TVWB-20

I'll probably grab a $7 Transcend tomorrow if I don't hear back, but if you know of one that works maybe I'll go that route instead. Thanks.
 
I have that exact card, actually two of them, and it doesn't work. Well it works in that it boots but then it spews errors at the end of the kernel boot for about a minute then "works". It is usable but every few writes it spazzes out for a while. The card I have that works perfectly was actually a freebee I got when I last bought RAM:
http://www.newegg.com/Product/Product.aspx?Item=N82E16820231509

You should be using the zip file in that directory... which I just realized gets wiped when there's a clean done so it isn't there any more. The openwrt-brcm2708-sdcard-vfat-ext4_224.img as of last night should work though. Up until about 9pm it would boot but the kernel didn't have USB HID support so even though the keyboard would be recognized, you just couldn't use it. Try that and wait a minute to see if the error messages stop, then you should be able to press enter to get a shell.
 
Yea, I've never seen the zip file in there... and my openWRT instance does not make one either, I get:

-rw-r--r-- 1 evanmj evanmj 345 Aug 7 11:26 md5sums
-rw-r--r-- 1 evanmj evanmj 48M Aug 7 11:26 openwrt-brcm2708-ext4.img
-rwxr-xr-x 1 evanmj evanmj 3.0M Aug 7 11:26 openwrt-brcm2708-Image
-rw-r--r-- 1 evanmj evanmj 69M Aug 7 11:26 openwrt-brcm2708-sdcard-vfat-ext4_128.img
-rw-r--r-- 1 evanmj evanmj 69M Aug 7 11:26 openwrt-brcm2708-sdcard-vfat-ext4_192.img
-rw-r--r-- 1 evanmj evanmj 69M Aug 7 11:26 openwrt-brcm2708-sdcard-vfat-ext4_224.img
drwxr-xr-x 2 evanmj evanmj 4.0K Aug 7 12:13 packages

I've yet to try one of my boot images since my computer is always up at work, but I'm bringing it home this weekend and will give it a shot.

Thanks for the info on the SD Card, I would have been mad if I had another that did not work. I got one of the G.Skill ones you linked for $5.25 shipped from amazon (Prime). I'll give that a go when it gets here on Monday.
 
I made the zip myself from a known-working configuration, because the .img files are always in flux and could contain massive bugs. I forgot to save the last working one when I did a `make dirclean` though so I lost it.

The images generated by a default OpenWrt probably don't have a lot of the stuff that my builds do. I'm still heavily hacking at the source to get it working, then figure out the best way to get from stock to where we need it, then check it into git. The default builds should boot, you just can't do anything once they're started because I think it has no network defined and definitely doesn't have support for the keyboard.
 
My apologies in advance for the slightly off-topic post, but I wanted to chime in with thanks to Bryan and everyone else who has contributed to this project (and say howdy to my fellow Austin-area folks).

A couple of years ago I developed my own laptop-based controller using an old National Instruments data acquisition device, which is still working fine, but it's bulky and not feasible to duplicate for friends. When the Raspberry Pi came out I thought it would be a great base for a new controller design. Congratulations for your success on getting this working. I can't resist the desire to roll my own solution from the ground-up, so I'm currently planning to use a Silabs C8051F350 as the ADC & PWM, connected to the Pi through I2C. The C8051F350 has a 24-bit ADC which is a bit overkill, but the part is only around $5 and I figure I might be able to use thermistors or thermocouples since there is an on-chip temperature sensor for the cold-junction compensation.

Anyways, keep up the good work!

Joe
 
Joe,

Are you planning to go rPi only with no AVR? If so, keep in mind how nice it is to utilize the controller in the absence of the rPi, or for that matter, a computer / phone to control it with. I'll check out that chip though, it sounds cool.

Share your progress as you go, good luck!
 
This is a good question. The c8051F350 would take the place of the AVR, so it could potentially run without the RPi. But I was thinking to design the hardware such that it runs off the 5V provided from the RPi GPIO header pins, and implement the PID loop inside the RPi, so the MCU would be more or less an analog front-end for the RPi.

Tonight I'll create a separate thread for my updates so this one can get back to RPi + Linkmeter discussion.

Cheers!
Joe
 
You must log in or register to reply here.

 

Back
Top