Archive for January, 2006

SmartRF Studio settings

Tuesday, January 24th, 2006

I am using SmartRF Studio to generate register settings for the CC2500, which is no doubt true for anyone using these parts. :) The code export function is cool. If you use it, be sure to save your configuration in addition to exporting code. I left out that step and had to re-configure the registers, although it wasn’t a big deal since I’m still using mostly defaults.

I set up the export code section to do the following:
- C-style comment delimiters
- normal view summary
- header:
const unsigned char cc2500_reg[][2] =
{

- for each register:
{ 0x@AH@, 0x@VH@ }@,@ // @RN@: @Rd@
- footer:
};
const unsigned int cc2500_reg_size = sizeof(cc2500_reg);

This gives a nice listing and is easily included into a build. I also use a header file with the following:
extern const unsigned char cc2500_reg[][2];
extern const unsigned int cc2500_reg_size;

Nothing too fancy, but it seems to work well. I set up my SPI tx routine to take a character pointer and a length, so sending the configuration is really easy and takes no effort aside from updating the settings in SmartRF Studio and exporting them to the C file.

STK500 zapping parts

Tuesday, January 24th, 2006

I have been beating my head against the wall trying to figure out how my software kept working less and less well. It’s awful. Code would work, then it would eventually quit working — apparently. In particular, I’m trying to get the CC2500’s working on my boards. I was getting happy status bytes back until I included the c file I’m creating with Chipcon’s nifty ‘export code’ function in SmartRF Studio. I did have an issue compiling for the ATmega165, but got that fixed. Still nothing, or at least something tantalizing followed by nothing.
(more…)

Building updated avr-gcc so ATmega165 works

Thursday, January 19th, 2006

I finally figured out that some issues I was having with building software for my ATmega165’s had to do with my cruddy hack to get avr-gcc to compile for them without warnings. I made it so that instead of using ‘-mmcu=atmega165′ I used ‘-mmcu=avr5 -D__AVR_ATmega165__’ when compiling. It works — up to a point. :) For me that point was reached when I started modularizing my code and trying to turn it into a real project instead of just lame test code.
(more…)

Database driven websites are different!

Tuesday, January 10th, 2006

I am used to building static websites. I am finding it hard to get started with a database driven site. With a static site I can have an idea in my head, sit down to write, and the pages and structure develop from that. I never care to much about the visual look of the site so that sort of development works for me.

Once I have a significant body of material written I will go back and polish the navigation and perhaps spend some time makeing the website look pretty.

That doesn’t work so well with a database driven site. With those you really have to start with the database tables. You can’t create tables without knowing what fields you need in each one, how long the fields should be, and all sorts of other knowledge about the data. In other words, it requires much more study and structure up front.

I am also learning that customers wildly underestimate the difficulty of their applications. They live their business so the rules and procedures seem obvious and trivial. However, when you talk to the people who actually process the forms, you quickly learn things are not that simple. There are lots of shades of grey and ad hoc decisions.

I think the most challanging issue will be breaking the connection between the paper form(s) and the look and feel of the website. The truth is, it’s dumb to make a webpage that looks like a paper form. A webpage is not a piece of paper and has totally different strengths and weaknesses. Properly designed I think a system of web pages can become a much more valuable way of collecting information. To do that will requre lots of effort and understanding.

I have some ideas, which I will discuss in future posts, about how this might be done.

Interakt Dreamweaver Extensions

Tuesday, January 10th, 2006

Interakt is a company founded by a former Macromedia developer to produce Dreamweaver extensions. I had looked at their stuff a year or more ago but couldn’t understand what it would do for me. I have since learned I have to be at the right stage of learning for things to make sense. At the time I first looked at the Interakt products I didn’t know enough about Dreamweaver to appreciate them. I addition, both Dreamweaver and Interakt have improved their offerings. Now they look promising.

My appreciation for what they might be able to do for me was enhanced by reading “Foundation PHP for Dreamweaver 8″ by David Powers. This book is Copyright 2006 and is the first I have seen which includes examples of incorporating Interakt products into database driven sites.

Interakt has a whole series of tutorials from which to learn. They look very good, but were not helpful in providing a good sense of exactly where and how these extensions fit into the big picture of database driven website development. Now that I understand that better I think they will be very useful.

In fact, after following one of the examples in the book I now expect the tutorials to provide a more complete procedure for actually building a functioning site. I think the tutorials will be more complete with error trapping code etc. which is needed for the production environment.

Dreamweaver 8 & Database Driven Sites

Tuesday, January 10th, 2006

I have always built static websites. I understand database design and have done database related work in the past, but have never had the need for a serious database driven site.

That has now changed. I need to build a site which collects information from used car buyers and then submits a completed loan application to lender(s). This sounds simple, but in reality is much more complicated than it seems.

For example, if the applicant has moved in the last couple of years they are required to provide documentation about previous residence. Not hard by itself, but challanging for a web based system.

I am developing in an Apache, PHP, MySQL environment but would rather not become a PHP guru. I can program if I have to, but I would rather spend my time working on the useability of the form(s), the logic of the data collection and understanding what makes an efficient data collection process.

After looking around I have decided to try the Dreamweaver Extensions from Interakt. It looks like they will allow me to rapidly deploy complex data collection forms without having to do heavy coding myself. There is a significant learning curve, but it looks hopefull. I expect to keep a journal of my efforts on this site.