Hi Joep, 2011/12/30 Joep Suijs <[email protected]>
> > What I see is that there are 594 samples for 158 different chips (not > counting the basic blink samples). However, there are 74 samples that > only run on one device. I guess it is not so obvious to find such a > sample when it is not available for your chip and you are not aware of > the existence of that sample. > When considering library as the starting point, you can use jalapi where samples using library are listed at the end. Ex: which samples are using glcd_ks0108 library ? http://jallib.googlecode.com/svn/trunk/doc/html/glcd_ks0108.html Well I must admit the following restriction: - jalapi isn't updated on a regular basis - information is quite buried... A dynamic web page would be better... > In other words: I guess our samples are quite inaccessible. Maybe we > should consider to change this, e.g. by: > - reducing the number of samples (only one sample per library) and > abandon the generation > - create a directory which contains one copy of each sample, next to > all samples we now supply. > - create an index > It's still nice to find a sample matching your chip, and it's even nice if this sample match your hardware. Rare... I guess this is about board files. There are some board files definition here, maybe we could work some more on specififying them in details, then build a webapp to select a board, select a sample template, and generate code. User could upload it's own board file definition. I see this webapp as an extra, keeping our samples as they are. >From what I can experiment with Jaluino: "include jaluino_bee" (or the like) is enough for me to get started and actually write the sample. When I want to release a Jaluino sample on jallib, I need "unknit" my aliases and code setup so final code strictly matches jallib's code & API. I thought about writing a program to do this: jaluino sample => jallib sample. It involves separating board and "generic" sample code. I guess this is why I don't use sample generation (though I coded this in jallib.py :)): because I need to have a compilable code at first level (eg. board + sample in the same file, ready to tinker with), and get lazy when I need to split board/sample code at the end, remember the command line to re-generate sample, and get annoyed/crazy when back and forward between these two steps (debugging/improving sample code). This could also be dealt with at IDE level: when building project, it assembles everything, so user doesn't see the difference. Just some thoughts... Cheers, Seb -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
