The Development Log


 

Bryan Mayland

TVWBB Hall of Fame
THIS IS NOT A WISHLIST THREAD
If you have a feature request or suggestion, create a thread for it.
THIS IS NOT A WISHLIST THREAD

I know there's not a lot of activity seen between releases and it may make folks wonder just what is going on if anything at all. I've decided to start keeping a little log of notes on things I'm working on because I get excited about them and I want to share them. The added benefit being you can see what's up without checking github all the time. So what's coming down the pipe?

* OpenWrt Attitude Adjustment release. This is done. I've moved off the RC1 and LinkMeter will be based on the Attitude Adjustment release that came out last month.

* rPi bootloader update. Updating to the latest firmware bootloader improves compatibility with new Pis which may come with a Hynix memory chip. Updates to the linux kernel to support this also brings with it a few bonus features.
-- Adjustable memory split means devices with more memory can allocate more to Linux and less to that worthless GPU we do nothing with. Up to 480MB for model B devices. Performance benefit? None. ePeen benefit? Immeasurable.
-- On the fly CPU clock rate adjustment. The CPU will scale between 700MHz and 800Mhz depending on load. Editing the config file can boost this to 900Mhz, 1GHz or more. Performance benefit? Minor. The CPU has a timeslice of 338ms so you've gotta be active for at least that long before you see any boost. Most the pages load in 500ms so they'll see relatively minor decreases in load time. You can also set the CPU to "performance" mode where it stays locked at the high speed to shave a little bit more off but it generally isn't worth it. (No web UI for this, next next version)
-- CPU core temperature readings. Because that seems useful.
-- Supposed 10% speed boost from using FIQ mode on the CPU. So they say. I don't see it.
-- Improved stability of SD card access
-- New USB driver, now with 0.03% less jankiness?
-- 47,065 new lines of code, 6,574 deletions. This was a real **** to merge.

* Low bandwidth HeaterMeter status page. Weighing in at 1.6KB and being entirely built on the server means even the lowest end mobile browsers can handle this

* LED configuration. The meaning of the LEDs can now be adjusted. Here's the list of things I've built in, and the status of these can be inverted as well. This is done in HeaterMeter but I still want to tweak it to get the size down a bit.
Code:
  None,
  UserOn,
  Alarm0L,
  Alarm0H,
  Alarm1L,
  Alarm1H,
  Alarm2L,
  Alarm2H,
  Alarm3L,
  Alarm3H,
  RfReceive,
  LidOpen,
  FanOn,  // fan > 0%
  PitTempReached, // Set once the pit has achieved setpoint for the first time since powerup or lid open
  FanMax, // fan at "max speed"

* Ability to prevent the configuration restore from launching on a new system. If you F up your config now, you can't just reflash the SD card and get back to stock, because the config system will restore your F-up and F you back the F up. This will be just creating a text file in the partition that windows sees that prevents the backup from restoring. It might be later extended to allowing configuration to be set right from this text file, but not in this release.

I've been working on the bootloader firmware the most. I've spent about 10 hours the past two nights trying to figure out why NONE of my Pis would boot on this new kernel and bootloader. No green light, no nothin. A real kick in the pants after the gobs of hours I spent merging the code to our kernel. Finally I noticed that the micro sd adapter was warped and wasn't making good contact. Damn you, free G.SKILL micro sd adapter! I've ordered a couple new reputable SD cards from Amazon because ain't nobody got no time for this.
 
Last edited:
hey bryan just a suggestion....maybe have a download thats presetup for access point mode. it eliminates changing the ip address and all that stuff to connect through the router. that seems to be were everyone has the most trouble with this. people could easily just connect to the heatermeter like a router then change it to a client easily if so desired. plus for people having trouble setting up the access point it would be a quick and easy download. I wouldnt mind making a image and uploading it to you of a barebones access point if you wanted. I now use 2 cards one for access point and one for client.
you have done a great job and everything you have done is appreciatted!!!
 
Bryan, ditto to the warped SD here. My rpi has bent 2 SD cards to where they no longer function in the rpi but still do in a usb reader.
 
maybe have a download thats presetup for access point mode. it eliminates changing the ip address and all that stuff to connect through the router.
Have you got the access point working? I can see my access point but no data ever goes. Can you post the backup file you get from System -> Backup -> Download backup?
 
I copied some stuff out of your config and now it works fine. I think the issue was that I didn't have dnsmasq listening on the wifi adapter and windows just kept saying "Nope! Can't connect". A mode switch won't be in the next version but now that I know it works thanks to you, it actually has a priority in my TODO list.
 
to be honest i like the dual card scenario... but it may not work with everyones case setup... I am buidling the one like dale so i can swap as needed....
hey stupid idea i know.... but could we use wifi adapters have one work as a access point and one work as a client... i may try to set it up like a range extender using my lan and wifi....that way you always have the option to to connect as a access point but if it senses a network it can use the one adapter as a client and you can access it through your home network... again i have no clue if this will work and it will prolly take a while for me to work on.
 
I don't see why not. That's actually a really great idea, and at $10 for another wifi is basically the cost of an SD card with no swapping. I'll try it tomorrow because I got a gaggle of adapters here.
 
I don't see why not. That's actually a really great idea, and at $10 for another wifi is basically the cost of an SD card with no swapping. I'll try it tomorrow because I got a gaggle of adapters here.

Here is a version that works with the lan and wifi
BTW i see no reason to bridge the two network cards... not like you really need a extender... just need both active so you can connect through either. oh also when you setup the new image have access point be on wifi0 or whatever its called.... incase you need to plug in the keyboard. because if dhcp client is on "0" you have to set it up the old way. The new way to setup should be through the access point. makes life alot easier.
Well thanks again.
 
I shy away from pre-configuring the networking too much in the base image just because that's how OpenWrt is built. Unconfiguring it from the default to what someone wants might be more trouble than simply configuring it the way they wanted in the first place. I might consider it, but it is a topic for another thread.

Last night I blew up my OpenWrt source by pulling the latest AA branch, getting conflicts, resolving them, then sub branching a portion of my tree and now I can't figure out how to get it back. The reason being I was on the AA branch and not the AA tag like I should have been. Argh, just when I had the image building perfectly! This will take some time to sort out but I'm out of town most of this weekend so it will have to wait.
 
If this is where we are now putting feature requests, can it have sharepoint rolled in? My grilling station is more than 30 feet from the house and I have a couple of self-powered speakers I usually hook into an iPad or similar device. If I could interface them to the RPi, it would be awesome.
 
No, feature requests should probably go in their own thread (one per request). I also don't know what sharepoint is, apart from the giant Microsoft document repository. If you're talking about a music player that can play audio files stored in a sharepoint repository, that's a whole project in itself. Neat idea of being able to play music, but you'd have to write a whole web interface for it in lua which is a monumental task.
 
Hmm, smoker controller AND Juke Box you say? Interesting, but a bit far field for this project I would think.
The rPi is a pretty capable device, doesn't seem impossible, but like you said, someone would have to take the time to code it. If it were out there I would try it, but have no idea how to code it...

For now the feature I am hot after is the "light" web page that can show the HM temps on my clever phone, can't wait for that release to come out. (tried twice to install the beta but all I had was problems)

PS Speaking of apps that are off topic, gardening season has just started and it struck me that the HM+rPi could be modified to become a garden controller pretty easily. Could measure rainfall, temperature, light exposure, soil moisture etc, and switch on and off soaker hoses to give a garden just the right amount of water exactly when it needs it. Would just take a couple different pieces of hardware (sensors) and I guess RF wireless for them to connect to the rPi. That would be really cool... and if you could make it play music for me while I am gardening... LOL Just kidding 'bout the music, but a DIY garden computer would be awesome. I would love to be able to record data from the weather each year that I could review on a computer.
 
Last edited:
Shareport

No, feature requests should probably go in their own thread (one per request). I also don't know what sharepoint is, apart from the giant Microsoft document repository. If you're talking about a music player that can play audio files stored in a sharepoint repository, that's a whole project in itself. Neat idea of being able to play music, but you'd have to write a whole web interface for it in lua which is a monumental task.

Sorry for confusing the issue. It is really called Shairport and its git is here: https://github.com/mikejuni/OpenWRT-ShairPort

It is an Airplay hack for OpenWRT that allows you to stream music from your iOS / Android devices.
 
I fixed my local svn repository without having to redownload the entire svn tree! I'm now building from the Attitude Adjustment tag rather than the branch.

I poked around getting the `sysupgrade` system working on the RaspberryPi. This would theoretically allow you to upgrade OpenWrt without pulling the SD card out, which can appreciate because now we have cases which make it hard to get at the SD card. It pivots to the RAM disk, backs up the configuration, blasts in the new firmware, reboots, then promptly blows up requiring the card to be reflashed with Win32DiskImager. I still think it can be made to work though.

On the HeaterMeter front, the LED manager class is as lean and mean as it is going to get while still supporting inverting inputs and one shot blink indicators. I was surprised then when adding 4 bytes to the EEPROM config space to store the setting cause the program to jump up by 50 bytes. The whole system is crammed into only 548 bytes, I'll be damned I'm going to let 50 extra bytes of bloat just get tacked on after I worked so hard to keep it small. Something about the config loader is exceeding the 63 byte offset that can be referenced off the Y register and for every access beyond that, GCC spits out a bunch of code.
 
The Y register looked to be used for referencing stack variables so what do we do? Reduce stack usage of our config loader. GCC is kind enough to inline both the base and probe config loader code into one function, which means both big config structs are allocated off the stack. To reduce the stack usage I declared a union with both structs in it and used that in both functions. Magic memory explosion disappears as the same chunk of memory gets used for both functions. Neat trick huh?

LED config read/write/set/get is all in HeaterMeter, now up to 24974 bytes. The last release was 24614 bytes so the whole LED manager subsystem weighs in at only 360 bytes. Alarm LEDs still need testing. linkmeterd and placeholder web config is in, but still needs to be styled and prettied up.

sysupgrade is coming along. For some reason the SD card is staying somewhat mounted through the ramdisk pivot and that means the new filesystem ends up getting corrupted when the new image is flashed. I've even built dd with conv=fsync support which was what I thought was causing the errors but no dice. Really hoping to get this working before next release.
 
Last night I took out the final known bugs in the LED manager while simultaneously reducing the size to 24962 bytes somehow. Just need to get the web UI finished up now.

I think I'm going to skip the sysupgrade in this release because it is really holding things up. I've also logged into my Pi and found that it had rebooted at some point without my interaction. Not sure if there was a power flicker or what but it does cause some concern.
 
Bryan,

when you update the parameters in the 328p via the Rpi and AVRdude, do you have to bootload the chip every time or can you just update the program?

Not a programmer (I've written minor arduino code, but that's it), so if you could dumb it down for me I'd appreciate it. :)

Matt
 

 

Back
Top