I am looking to add I2c LCD support to my BrewPi - as I cannot get the discontinued PCB that was part of the original kit, I2C is really the most feasible way to do this.
I’ve looked through several threads and then stumbled across this firmware (https://github.com/herrfrost/firmware/tree/feature/SoftwareI2C) that looks like it would be perfect and is based on the same 0.2.10 FW I’m using. The problem is I can’t get it to build in AtmelStudio 6.2. The only option I had for build type was ‘Debug’, ‘Release’ isn’t an option. I had the same issue with the 0.2.10 from the BrewPi repo. With the much older version found here (https://github.com/BrewPi/brewpi-avr), I had an option for a release build, but that failed with errors indicating missing files. I read that was resolved in later releases.
I assume the version in the ‘herrfrost’ repo is based directly off the official FW, so my guess is what will allow one to build a release build will do the same for the other.
Or another thought, what would the odds of incorporating the Software I2C support found in that project into the official firmware as another release, similar to there currently are ‘brewpi-arduino-uno-revA-0_2_10.hex’ and ‘brewpi-arduino-uno-revC-0_2_10.hex’ files built, adding something like ‘brewpi-arduino-uno-revC-I2C-0_2_10.hex’? I seem to recall Elco saying he wouldn’t be against doing that if someone got it working (or something to that effect) in a post somewhere.
Can you elaborate on what you mean when you say that you can’t get it to build?
“DEBUG” is simply a name for a particular build configuration in Atmel Studio. You can add another configuration in the configuration manager if you need to compile it with different flags, or modify the existing ones in project properties. They should give a pretty good build however as it is, even though the name might not be all that fitting for what it does.
Build/compile as is. Upload hex file in brewpi’s web interface.
I am not very familiar with Atmel Studio, although I’ve done some playing around with it in the past with some other things I had played with. All the other times I’ve done anything with it, in the ‘Solution Configurations’ drop down, there have always been ‘Debug’ and ‘Release’ options. When I wanted to build the project that I was going to write to something, I’d select ‘Release’, then ‘Build > Build Solution’ and it would generate the files needed and flash the device.
With the BrewPi 0.2.10 FW, I only have ‘Debug’ as an option there (This is the first time I’ve ever seen that).
Or does that not really mean anything and in fact ‘Debug’ and ‘Release’ are actually the same?
If you’re setting up a new project in Atmel Studio then by default release and debug does somewhat different things. You can add, rename and remove configurations. They can be customized in project properties. Statements such as “#ifndef NDEBUG” will include/exclude code depending on build config by default. In brewpi’s case, I strongly suspect that “DEBUG” was the configuration left after the other one was removed. It’s quite customized however, and the name of it is just that, a name.
Ahh, you’re the ‘Daniel’ that built the Software I2C version of the firmware.
Thanks for the help - Having never not had the ‘Release’ option, and not being real familiar with Atmel Studio other then real simle things, I didn’t realize that the build option labels really didn’t mean much.
I successfully built the hex files, however, when I upload yours to the Arduino, it ends up not working. I have the LCD wired up with 2k pullups, but when the firmware loads, I get the generic ‘Warning: Cannot receive version number from controller. Your controller is either not programmed yet or running a very old version of BrewPi. It will be reset to defaults.
Resetting EEPROM to default settings’ message, and I have gibberish on the LCD. I just loaded up the solution and clicked build > Build brewpi-avr for both yours and the ‘official’. The official one works.
Am I missing something else? on your GitHub page, you say ‘Copy and modify /app/controller/Config.h to /app/controller/Config.h’, but that doesn’t make sense - did you mean something else?
Thank you for pointing out the error, yes, /app/fallback/Config.h is the file that needs to be copied to /app/controller/Config.h and modified. In particular, the display type and TWI/I2C defines.
Well, I’ve gotten somewhere, but I must be doing something wrong. If I copy the config.h from fallback to controller and build it without changing anything, it works, and is recognized as a 0.2.10 FW controller.
If I change only the LCD parameters, uncommenting only ‘#define BREWPI_LCD_TYPE BREWPI_DISPLAY_TWI_LCD’ and the #defines in the ‘Set TWI/I2C LCD parameters’, the RPi can’t detect the version, so it doesn’t work.
Am I missing something else? Shouldn’t hte project work as pushed to git if unzipped and built, other than maybe I2C address differences (Mine happens to be 27)?
The build I’m using is in here. Standard revC, but using I2C on two of the SPI pins (10 and 11). I’ve used it on official Uno and now presently a clone Nano.
Yes, something is wrong and It’s either software or hardware.
The micro controller is not responding in a way that brewpi-script expects when asking for version number. There’s a reason for that. Check the brewpi wiki, forum (old & new) or docs for information on how to communicate with it without using the web interface. This might give you some information.
Verify that the LCD works. Try one of the I2C “libraries” available for the arduino. Set up a simple project using feliasfogg adaption of Peter Fleury’s I2C assembler code and try it out.
Check circuit. Check configuration. Check code. Scope/Analyze the bus. Check voltages. Etc.
DIY is sometimes done out of necessity, sometimes simply because you enjoy doing it. I2C on brewpi is really not necessary as in there are options, unless one is steel set on using that LCD one bought on ebay or some such place. There are LCDs with different backpacks that can handle multiple protocols. There’s a ready made solution (brewpi spark). These are always options, and might save varying degrees of hair.
Thanks - I’ll have to wait until one of my BrewPis are available (both are currently controlling fermentation).
The thing that has me baffled is the I2C implementation shouldn’t have any impact on the USB Comms between the RPi & Arduino, and if the LCD is not connected or is wired wrong, that also shouldn’t affect the USB Comms, so considering nothing (physically) changes between the Arduino and RPi between the Official firmware and the I2C firmware, it should still be detected by the RPi and work, even if the LCD doesn’t.
With the LCD connected, I get some text that seems to be in the right place, but it’s mostly random characters. Truthfully, I don’t NEED the LCD, It would just be a nice addition, and I’m sure there are other implementations that could be used, but it seems like the I2C backpack is the easiest to come by (or is there one out there that I missed that uses the same chip and code to drive it as the original BrewPi Arduino Shield).
“if the LCD is not connected or is wired wrong, that also shouldn’t affect the USB Comms”
Sometimes a big assumption can lead to an even greater bafflement. Maybe “shouldn’t”, but most certainly “can”.
Imagine someone adding an LCD screen to a controller responsible for heating some tonnes of oil. Code is updated with only display related code.
If OilTempTooLow
Start heater
Send Update Display
Do WaitHere
While DisplayAcknowledgeNotReceived
If the display has lousy connections, weak pull-ups, long wires etc., likely the least of your worries would be the downed USB communication.
Now, for an even simpler and less disastrous example: Connect an output to ground. Connect another one to an LED and resistor. Make code. Light led. Update code, light led and output high on the output connected to ground.
I don’t think the former example is your problem, I actually tried crappy connections (where Arduino’s wire & twi previously went TU) when testing the code. Here’s how I’ve got my LCD wired:
I ended up throwing together a third BrewPi just for testing, rather than waiting another week plus to test with my other BrewPis. I loaded up the stock firmware and that was happy. I then loaded up your firmware and that works fine on this one.
The only differences I can come up with are before, I didn’t have the 100nF cap, which doesn’t seem to be the issue because I pulled it and reset the arduino and it was still happy, and at the time, I didn’t have any 2.2k resistors, so I used three 1k resistors - one from +5v to a row on the breadboard, and then another one each for the SDA & SCL lines for a total resistance between the +5v & the SDA/SCL lines of 2k. After some testing, it seems the resistors might have been my issue. I connected up the resistors the way I did before and LCD acted up (not the exact same way, but not right) and the arduino & Rpi got got lost in the weeds until I pulled the three 1k resistors and replaced the 2.2k resistors. Then life was good again.
So I learned something new :). I thought he LCD code was like UDP packets over a network - the Arduino just kicked the packets ‘out the door’ to the LCD and if it got them it got them and if it didn’t, the Arduino didn’t know or care and marched on with life. That would seem to not be the case.
Thanks for your help, hopefully my issues with the other BrewPi were just user error on my part.
danf: with your LCD connected to D10 and D11 - how is it set in the config.h? I your fallback had pins 2 and 3 set. Is that correct? Because setting those to 10 and 11 I receive an error when compiling, saying it needs to be less than 8.
