Tips on debugging changes to opensprinkler...How do you debug Ray?

[got1]

Hi Ray, I am making some changes to the code I am used to using the IDE to display serial prints to help in debugging.

However, I have hit two snags with opensprinkler.

1. how to debug given the is no serial console available.

2. there are only a few bytes left in program space so there is no room to put in debug code anyway.

That got me thinking, you must face this one a daily basis...how do you go about debugging your code and can you give any tips on how we might do the same (given the above constraints).

Thanks in anticipation for the hints.

[Ray]

First, you can use the LCD to display values (use svc.lcd.print() function). If you are writing out values frequently, you can add a delay after each printf so you have some time to look at the value before it's overwritten by the next value.

Second, if you really need serial communication, you can find the TX and RX pins and connect a USB serial cable to them, These two pins happen to be connected to the LCD, so you need to take off the LCD to access the two pins.

In short, either use the LCD, or take it off and use the TX/RX pins. As for the program memory space, you can always comment out some functions (such as the anything related to manual mode) to help you fit debugging code.

[got1]

Thanks ray. I'd like to keep manual control.

Re. the space...I might remove the weather function and get some space back that way.

any other items that you would consider discrete blocks that could be disabled? Just thought you might have some fat in there you are aware of that perhaps was held over for later use and I cld. trim.

Cheers.

[got1]

Bugger. Just worled out it's on the server side and not in the Arduino.

Back to the drawing board. There must be some space somewhere!  You must have a nightmare of a time adding new features with just 100 bytes to play with!

[Ray]

You are right, the weather part is in the javascript stored on the server.

Here is a list you can consider trimming:

- display icon of network status

- ntp sync (assuming you have rtc)

- run-once program or manual control

- remove some lcd display messages.

Indeed I made a lot of optimizations to fit all the features within the program memory space. It was quite painstaking. At one point I considered switching to ATmega644 which has 64KB memory. But I decided to first try to fit all features I wanted to ATmega328, then consider moving to a different chip. This way, people who bought opensprinkler previously will still be able to upgrade the firmware.

[garygid]

It seems like you might be beating your head on the wall to
not switch to the mega64.

What hardware changes would be necessary on the board?

Would the existing firmware source compile for the mega64?

If not, what changes would be necessary?

Beyond those issues, is it just cost?

Cheers, Gary

[Ray]

Cost is the lowest priority factor, since the differences between these chips are often just a couple of dollars.

One of the reasons I did not switch to mega664 is because its DIP package is significantly larger than mega328, which makes it tricky to re-design the through-hole (DIY) version. The surface mount version can definitely fit without a problem.

Software development is typically the major bottleneck. You will spend most of the time porting code to the new microcontroller. In this case, mega664 is not officially supported by Arduino, so I would expect more work to be done.

Another reason is that I don't want to just move on to a new chip and tell previous users that they cannot upgrade their software any more. 

OpenSprinkler 2.0 will certainly use a different chip, not necessarily avr any more.