แฟ้มประวัติHERMANรูปถ่ายบล็อกรายการเพิ่มเติม ![]() | วิธีใช้ |
|
13 กุมภาพันธ์ Testing times - PC to picaxe commsI've been inspired to get my teeth into picaxe coding again and so it was time to further develop the HERMAN code. One thing that I wanted to clean up was the duty cycle timing for the kettle power - the cycle time was way too long. I had the interrupt timer operating at 1 second for clock purposes, so to speed up the kettle duty cycle the interrupt now happens more frequently to update kettle duty each minor tick. A major tick still occurs every second, triggering all other timed functions, including one-wire timing. Once that was sorted, it was time to tackle PC to picaxe communications via the serial port. I've had picaxe to PC working for ages, but when I first tested the other direction I was perplexed at the lack of response from the picaxe. While working on the duty cycle function, I found a logic error that prevented the receive code from ever working. OK, so now the motivation to step forwards again. Things were not straight-forward, however. The first symptom was that data was received but the picaxe never recognised the header, so always timed out. It turned out that incoming data was mostly corrupted, through timing problems. This was eventually sorted using the calibfreq command. The manual says this command should be used with caution. Of course I forgot to read that bit ... and ended up with a picaxe I could not program for quite a while. A hard reset on the power side eventually fixed it! In hindsight it seems blindingly obvious that I could have implemented the calibfreq for the received comms code only. I now have this working reliably. With a header now recognised and information getting through, I ran into more problems. Most of the information sent came through ok, but it always seemed the last byte was corrupt. I still have no idea why, but I ended up shortening the data packet and sending a dummy end and now it all works. There is more work to do to make things more robust. I intend to implement both send and receive checksums, but for now I'm happy to finally have remote control capacity for the machine. 05 กุมภาพันธ์ Better the micro you know ...Until a few days ago the display part of my picaxe code on the brewing machine was a mess. It had been ages since I'd coded any revisions and the display only had rudimentary information on screen. For the last three months I'd needed to plug in the laptop just to see something intelligible from the 28X1 chip. Recently I bought an Arduino and I've been catching a few minutes here and there to learn about its capabilities. There is a lot more power in this new (to me) micro. Because of this I'd neglected further picaxe development.
So while I was looking at the new Editor, I discovered that I'd done some significant recoding for the picaxe in early November that I'd forgotten about. It never got uploaded and tested ... So all of a sudden there were display improvements and an easier way to keep track of updates ... and I'm inspired again by the micro I know. I've posted the current HERMAN code here. There are improvements to make, but generally I'm happy with progress. I intend to add in features like:
On the hardware side I've been impressed with the 'shield' idea on the Arduino. Essentially a shield is a board that can piggyback onto the base Arduino board. The connectors extend all pins, power, reset and the like. Shields can be stacked on top of each other to further extend functions. As an example, I have an internet board for my Arduino (not that I've done any experiments with it yet). I'm not sure I will implement 'shields' in the HERMAN project although the idea of beginning small and building up is appealing. Some possible 'shields' for the HERMAN project:
|
|
|