SimpleIDE board.cfg editor
jac_goudsmit
Posts: 418
(Starting a new thread about this instead of hijacking the other one)
A board.cfg editor would be a great feature. I don't really think much in terms of user interface but more in terms of data model but I think it's worth doing this at some point. But if you want to associate libraries with projects or hardware, you'll get a full n-to-n relationship which will be a lot of work (read: impossible) to maintain.
I haven't worked with the simple libraries (yet) but I wonder if we can simply let them export properties such as number of pins required, pins need to be adjacent y/n, default pin assignments, can pins be moved y/n, what hardware is needed on the pins etc.
For example a TV library (without audio) can tell SimpleIDE that it needs 3 adjacent pins, the default pin is 8, alternate starting pins are 0, 4, 8, 12, 16, 20, 24. The hardware on those pins should be "TV resistor network" (with possibly a picture of the schematic).
Then, when you want to start a project such as Oldbitcollector's Pocket Mini Computer (just a random interesting example that needs a lot of hardware), you can load the libraries for TV, VGA, PS/2 keyboard, by dragging and dropping or by choosing from a well-organized list that's probably linked to a website. SimpleIDE can help you make sure that the pins of various libraries don't conflict, by reassigning starting pins if necessary. If it also keeps track of what hardware is available on the various supported boards (or user-supplied boards), it can automatically configure libraries (for example, Propeddle has TV pins but they start at pin 16, not 8), and they can tell you when you have to add your own hardware ("The %s board doesn't have TV-out hardware, you will have to build your own and add it, okay?").
It would also be nice to have a graphic editor where you can drag the pins that are needed for a library onto a picture of the board or a picture of the Propeller and drag them to the locations where you plan to hook them up. Or if the program already knows what hardware the board has, it can automatically drag the pins in place.
Finally, SimpleIDE can generate a .h header file and a main.c file: the .h file can contain an enum that lists the functions of all pins and the main file can #include the necessary headers for each library, and can have a main( ) function to initialize all the libraries that are needed. In a few recent projects I worked on, I've done this in Spin, too: I simply created a module called "hardware.spin" or something, and put a CON section with an enum definition of all the pins (and a dummy PUB routine otherwise it won't compiel). In other modules, I just put an OBJ reference to the hardware module and when I use a pin number somewhere I simply use hw#pin_WHATEVER. That way if I ever get the idea of moving pins around in the hardware, I'll only have to change one spin module to let the software know about it.
I know, this all sounds very ambitious. Many of these ideas can be implemented one-by-one if you're careful about the sofftware architecture. Some ideas can probably work way better in different ways and some things are probably impossible to maintain in the long term. I'm just sprouting ideas.
===Jac
Jac,
I've talked with Ken about doing something similar to this for over a year now. While this is not a usage *exactly* like you mention, it is with a very similar spirit. The idea is to drag/drop devices from a "library panel" to a "project panel" ... the existing board.cfg mechanism can support that. I.e. a board.cfg editor .... What do you think?
A board.cfg editor would be a great feature. I don't really think much in terms of user interface but more in terms of data model but I think it's worth doing this at some point. But if you want to associate libraries with projects or hardware, you'll get a full n-to-n relationship which will be a lot of work (read: impossible) to maintain.
I haven't worked with the simple libraries (yet) but I wonder if we can simply let them export properties such as number of pins required, pins need to be adjacent y/n, default pin assignments, can pins be moved y/n, what hardware is needed on the pins etc.
For example a TV library (without audio) can tell SimpleIDE that it needs 3 adjacent pins, the default pin is 8, alternate starting pins are 0, 4, 8, 12, 16, 20, 24. The hardware on those pins should be "TV resistor network" (with possibly a picture of the schematic).
Then, when you want to start a project such as Oldbitcollector's Pocket Mini Computer (just a random interesting example that needs a lot of hardware), you can load the libraries for TV, VGA, PS/2 keyboard, by dragging and dropping or by choosing from a well-organized list that's probably linked to a website. SimpleIDE can help you make sure that the pins of various libraries don't conflict, by reassigning starting pins if necessary. If it also keeps track of what hardware is available on the various supported boards (or user-supplied boards), it can automatically configure libraries (for example, Propeddle has TV pins but they start at pin 16, not 8), and they can tell you when you have to add your own hardware ("The %s board doesn't have TV-out hardware, you will have to build your own and add it, okay?").
It would also be nice to have a graphic editor where you can drag the pins that are needed for a library onto a picture of the board or a picture of the Propeller and drag them to the locations where you plan to hook them up. Or if the program already knows what hardware the board has, it can automatically drag the pins in place.
Finally, SimpleIDE can generate a .h header file and a main.c file: the .h file can contain an enum that lists the functions of all pins and the main file can #include the necessary headers for each library, and can have a main( ) function to initialize all the libraries that are needed. In a few recent projects I worked on, I've done this in Spin, too: I simply created a module called "hardware.spin" or something, and put a CON section with an enum definition of all the pins (and a dummy PUB routine otherwise it won't compiel). In other modules, I just put an OBJ reference to the hardware module and when I use a pin number somewhere I simply use hw#pin_WHATEVER. That way if I ever get the idea of moving pins around in the hardware, I'll only have to change one spin module to let the software know about it.
I know, this all sounds very ambitious. Many of these ideas can be implemented one-by-one if you're careful about the sofftware architecture. Some ideas can probably work way better in different ways and some things are probably impossible to maintain in the long term. I'm just sprouting ideas.
===Jac
Comments
Keeping things as general as possible is the key to success.
I was thinking a stand-alone application (based on Qt and MinGW, internationalized, multi-platform) would be a good start. That would provide an easy way to allow any user type to take advantage of the feature (command line, vim lover, eclipse, simpleide, etc...).
Here's the ICONS thread started last year for supporting the effort. There are many great ideas there.
As mentioned, one of the outputs should be a C (or header) file. It would make all the pin variables visible to the user. A #ifndef blah, protected header could fill this role instead of a .c/.cpp source file. A generic file-name like "board.h" or "boardinfo.h", etc... could be used in any program. The loader stuffs the variables into the program after compile using the board-type .cfg information.