2010-10-23 00:00 so the idea is that components/INFO describes the components that work in this design, not the reasons or selection criteria that led to this component 2010-10-23 00:01 juan64bits: ok, what about uSD linux module, is it working? 2010-10-23 00:01 wolfspraul: components/* shouldn't be project-specific. i keep it in projects while testing. once things are stable, they can go to, say, kicad-libs 2010-10-23 00:02 including components/INFO ? 2010-10-23 00:02 that would be merged, yes 2010-10-23 00:02 give that components/INFO is totally separate from KiCad I'm not sure it's a good idea to move it to kicad-libs 2010-10-23 00:02 maybe with some editing, depends on how much junk ended up there 2010-10-23 00:02 it will create a barrier for people to edit/update it 2010-10-23 00:02 components/INFO documents the content on components/* 2010-10-23 00:03 yes, the module is the same of ben.... we only change some parameters for the GPIOs 2010-10-23 00:03 where else would you keep this ? in the wiki ? :) 2010-10-23 00:03 hmm 2010-10-23 00:03 I just thought I understood components/INFO :-) 2010-10-23 00:03 you can see the patch in the SIE repository 2010-10-23 00:03 maybe the user fields would actually be better then 2010-10-23 00:04 i don't particularly like those invisible fields 2010-10-23 00:04 gettine error while refalshing the kernel. Can anybody help me 2010-10-23 00:04 in ben-wpan, components/INFO has exactly one actual piece of data - it connects the crystal to a part number 2010-10-23 00:05 then there are some comments above the symbols 2010-10-23 00:05 the symbols are just the ones from the .libs, but need to be manually kept up to date 2010-10-23 00:06 you'll find more detailed INFO files in gta02-core. those in ben-wpan are more or less for my own entertainment, and fairly sloppy :) 2010-10-23 00:06 how is the connection of the generic crystal to a part number not project specific? 2010-10-23 00:07 ok maybe I ignore components/INFO for now, will watch what happens 2010-10-23 00:07 (crystal) it's an example for one possible such crystal. and yes, that's not really clean. the correct approach would be to write a document that defines this class of crystals, with references to real parts 2010-10-23 00:07 I got the BOOKSHELF idea now, I think 2010-10-23 00:08 it's just what it says - a separate 'bookshelf' :-) 2010-10-23 00:08 yup :) 2010-10-23 00:08 and nice script to download and open docs 2010-10-23 00:08 juan64bits: k 2010-10-23 00:08 but not overly, or in fact in any way, linked to symbols or references in the schematics 2010-10-23 00:08 hence also the 'nice' aliases etc. 2010-10-23 00:08 so that one is clear 2010-10-23 00:08 juan64bits: other isolated question, did you have issue with the usb connector in SIE, 2010-10-23 00:08 it also has things like application notes, design guides, etc. 2010-10-23 00:09 wpwrak: where would that document that defines a class of crystals and references it to real parts be? wouldn't that be in boom/.sub files? 2010-10-23 00:09 so it's a place other things may link to but it's not a place that links out (except to the data sheet, of course) 2010-10-23 00:09 juan64bits: like some pin just dont make good contact with the usb cable by then power fails when feeding from usb? 2010-10-23 00:10 (document) no no, that would be a real document. like that guy's kicad missing feature list 2010-10-23 00:10 may be just happened to me, i just want it to mak public :) 2010-10-23 00:10 and sure i can solve it soldering a new usb conector 2010-10-23 00:11 for those few lines it could be just comment lines in a .sub file, no? 2010-10-23 00:11 kristianpaul: juan64bits : what is the sie reposiroty? where is it? what does it cointain? (kernel? bootloader? rootfs?).. sorry if many questions :) 2010-10-23 00:11 mm yes, something similar happened to a student 2010-10-23 00:11 few lines = definition of crystal ? well, depends 2010-10-23 00:11 rafa: SIE repo http://projects.qi-hardware.com/index.php/p/nn-usb-fpga/ 2010-10-23 00:11 rafa: all our answer are in there in the patchs and rootfs ;) 2010-10-23 00:12 yes, that is... 2010-10-23 00:12 .sub shouldn't really be a source anyway. the underlying design and conventions ought to be documented elsewhere 2010-10-23 00:12 kristian, can you solve my prob 2010-10-23 00:12 may be juan64bitsÂ Â can tell more about its particular folder hierarchy :) 2010-10-23 00:12 (sie repo and var stuff?..) 2010-10-23 00:12 nitin_gupta: hello 2010-10-23 00:12 hi whats up 2010-10-23 00:13 just write and oher people can read you too :) 2010-10-23 00:13 also, .sub has no idea what schematics symbols you're using, so it wouldn't really make sense to document them there 2010-10-23 00:13 kristian, iam trying to reflash the kernel of NN but getting error 2010-10-23 00:13 sie repository contains many examples for SIE 2010-10-23 00:13 Error : "cant get kernel image" 2010-10-23 00:14 like logics for the FPGA, comunication CPU-FPGA 2010-10-23 00:14 juan64bits: for example production SIE board were based on kicad ? i just noticed some labels do not correpond in the kicad project in the repo, wich ones?, the one the conector for uart and i2c 2010-10-23 00:14 juan64bits: is it okey for sakc (previous sie boards) as well? is it the official software repository? (I mean, if you use just the software on that repository for your boards without extra software from other places) 2010-10-23 00:15 nitin_gupta: how you the boot process? 2010-10-23 00:15 some binaries, the rootfs (that is merge with the ben in basic configuration) 2010-10-23 00:15 nitin_gupta: what steps you followed? 2010-10-23 00:15 nitin_gupta: are you using regflash script? 2010-10-23 00:15 after flashing the kernel and rootfs, I just remove the usb cable and plug in the battery back and power on. 2010-10-23 00:16 no I am not using reflash script 2010-10-23 00:16 it seems the uImge is not there 2010-10-23 00:16 I tried it but it was not working some how 2010-10-23 00:16 whar instructions you followed? 2010-10-23 00:16 mmm the kicad board are a copy of previous orcad design, and never has been made 2010-10-23 00:16 what* 2010-10-23 00:16 juan64bits: aha !!!! 2010-10-23 00:16 firstly bring NN in usb mode 2010-10-23 00:17 **never has been made** 2010-10-23 00:17 kristianpaul: neither the avt2 nor sie kicad files were used for actual pcb or smt 2010-10-23 00:17 nobody dared to do that yet :-) 2010-10-23 00:17 :/ 2010-10-23 00:17 then usbboot -c "boot", then usbboot -c "nprog 1024 kernel_image 0 0 -n" and last usbboot -c "nprog 2048 rootfs image 0 0 -n" 2010-10-23 00:18 but it looks like we finally will with Xue 2010-10-23 00:18 but we are thinking use this design in the next revision 2010-10-23 00:18 yes, and in SIE v3 2010-10-23 00:18 i hope is not same for xue.. but thats other talk 2010-10-23 00:18 kristianpaul: we are getting there, there were always specific reasons, this and that. 2010-10-23 00:18 nitin_gupta: nerase?.. 2010-10-23 00:18 nope 2010-10-23 00:18 sure 2010-10-23 00:18 time , run run run !! 2010-10-23 00:18 I havent used it 2010-10-23 00:18 nitin_gupta: you need for rootfs 2010-10-23 00:18 wait a min 2010-10-23 00:19 no such cmd is written in the booklet 2010-10-23 00:19 no, xue design began on kicad 2010-10-23 00:19 good 2010-10-23 00:20 nitin_gupta: http://en.qi-hardware.com/wiki/Updating_Ben_with_usbboot 2010-10-23 00:21 nitin_gupta: i always follow that 2010-10-23 00:21 you'll need run nerase 16 512 0 0 2010-10-23 00:21 nefore flash rootfs 2010-10-23 00:21 before* 2010-10-23 00:21 nitin_gupta: i guess you compiled you're own images isnt? 2010-10-23 00:22 wolfspraul: smt and kicad dont go well, i really dont know what data is required in that process besides i know gerber is for making PCBs.. 2010-10-23 00:22 ? 2010-10-23 00:23 yes 2010-10-23 00:23 you can check the Milkymist One runs as a reference, all files that were necessary for SMT are documented there 2010-10-23 00:23 k 2010-10-23 00:23 so guess answer is no 2010-10-23 00:23 :p 2010-10-23 00:23 yes we need to document the entire process from Kicad to PCB making to SMT (pick & place), and how to generate all supporting files 2010-10-23 00:23 the entire workflo 2010-10-23 00:23 workflow 2010-10-23 00:24 I think it's doable, definitely. Just a lot of little pieces and it all needs to be documented well. The various projects are getting us closer there, for sure. 2010-10-23 00:25 maybe we need a few runs until the process and documentation is really good and easily reusable for anybody. 2010-10-23 00:25 yes, for now We tested a card, like arduino, for pcb making 2010-10-23 00:27 But the assembly was done manually :) 2010-10-23 00:27 wolfspraul: remenber the board a guy introduced by andres in cparty gave you, the board name is miulin 2010-10-23 00:27 was made all in kicad 2010-10-23 00:27 sadly no public sources yet :( 2010-10-23 00:27 sure I remember 2010-10-23 00:27 but SMT was done manually if i remenber well, so no complete workflow 2010-10-23 00:27 I think we are ahead of this, the point is to open up all files, the process, etc. 2010-10-23 00:27 but at least the board is prove is posible 2010-10-23 00:28 probe* 2010-10-23 00:28 not dump a zip at the end somewhere 2010-10-23 00:28 sure 2010-10-23 00:28 git/svn is important, KiCad, things like schhist, boom, wiki to document some things 2010-10-23 00:28 agree 2010-10-23 00:29 also those little things I keep pinging Werner about, like BOOKSHELF, how to document component selection criteria, design choices, etc. 2010-10-23 00:30 the problem is that a) it's not enough if one person just declares the perfect process, it has to be thought through and used by multiple people over time and 2010-10-23 00:30 b) it needs to be rested and refined by real manufacturing, be it at home/diy style, or with services/companies 2010-10-23 00:30 needs to be tested 2010-10-23 00:31 maybe Xue can become our masterpiece, he he 2010-10-23 00:31 let's see 2010-10-23 00:31 maybe a lot of things will come together there 2010-10-23 00:32 wpwrak: about the crystal we talked about earlier. the current C1/C3 is 27pF, the crystal on the current board has a load capacitance of 12pF. 2010-10-23 00:32 2*12=24, so a little lower than 27pF but I guess it should work? I mean I saw boards working so it must work... 2010-10-23 00:33 wolfspraul: the chip probably isn't that sensitive to clock inaccuracy. 2010-10-23 00:33 wolfspraul: it gets nastier when you do RF :) 2010-10-23 00:35 if I go to a 18pF crystal I guess I will just increase C1/C3 to 33pF as you suggested 2010-10-23 00:36 yup, that should work nicely. your pins will add a few pF too, so you'll end up more or less exactly with 36 pF 2010-10-23 00:48 wpwrak: in this case, how would you name the 'value' in eeschema? it's 'crystal_smd' right now 2010-10-23 00:49 would you encode the 12mhz and/or load capacitance? 2010-10-23 00:49 if the footprint is in mm (3.2mm x 2.5mm here), any standard format for that? 2010-10-23 00:50 which of those things would you encode in the value, footprint or user defined fields (in eeschema)? 2010-10-23 00:51 (value) good question :) the frequency for sure. the load cap is rarely mentioned, yet it does matter 2010-10-23 00:52 well it seems it does. the crystals I find are between 8 and 18pF, and it sounds like without changing other capacitors, you wouldn't want to just ignore this value. 2010-10-23 00:52 afaik, crystal footprints can have a lot of sizes. 2010-10-23 00:53 digikey for example has the load capacitance in the description field 2010-10-23 00:53 but not the frequency stability and tolerance 2010-10-23 00:53 so the load capacitance does seem to stand out somewhat as something you will want to get right/matching in your design 2010-10-23 00:54 not the tolerance ? i think they do 2010-10-23 00:55 "CRYSTAL 12.000000 MHZ 8PF SMD" 2010-10-23 00:56 aah, description field, right. well, the digi-key description field can be odd at times :) 2010-10-23 00:56 maybe the value should be CRYSTAL_SMD_12MHZ_18PF ? (in our design) 2010-10-23 00:56 or is that too much? 2010-10-23 00:56 just trying to understand what you would move to which place... 2010-10-23 00:57 well, ->I<- would have 12MHz in the value and 18pF in another (visible) field 2010-10-23 00:58 but you can pick a different style :) you need to adapt the .sub then, though 2010-10-23 00:58 which fields are visible? 2010-10-23 00:58 you mean visible in the plotted schematics I guess 2010-10-23 00:58 because my .subs don't know about the param/other_param format 2010-10-23 00:59 you can choose in eeschema whether a field's value is shown in the schematics or not 2010-10-23 00:59 ah OK 2010-10-23 01:02 looks ugly, not enough space for the "18pF" right smack in the middle of the crystal symbol 2010-10-23 01:02 btw, the Value is "12MHz" right now, the Footprint is "CRYSTAL_SMD" 2010-10-23 01:03 should the footprint include an attempt to encode the size in it? 3.2mm x 2.5mm. Or rather not? 2010-10-23 01:04 I think I leave the additional Load_Capacitance field invisible for now, it's too ugly 2010-10-23 01:04 field names can have spaces in eeschema, is that supported (or encouraged) by boom? 2010-10-23 01:05 hmm, boom in general doens't like spaces so much. you can wildcard-jump over them, though 2010-10-23 01:05 no problem, I understand that as 'don't use spaces in eeschema field names' 2010-10-23 01:05 (in the middle) you can move fields around in eeschema 2010-10-23 01:05 kristian NN doesnt wake up after that 2010-10-23 01:06 i have reflashed uboot, kernel and rootfs and all get done successfully 2010-10-23 01:07 the footprint should identify the physical size somehow. this can be a standard package name (DIP-10, SSOP-20, etc.), an explicit size, or whatever else works. 2010-10-23 01:07 now, crystals are one kind of components where i'm not sure if there are any standard sizes or not 2010-10-23 01:08 yes I think there are, but a lot, maybe 20 or so 2010-10-23 01:09 "the nice thing about standards is that there are so many to choose from" ;-) 2010-10-23 01:09 the ones I've seen (digikey only) can be either in diameter, or xy 2010-10-23 01:09 ok so I will encode 3.2mm x 2.5mm in the footprint 2010-10-23 01:10 thanks for the hint about moving fields, I moved the new Load_Capacitance down and it looks good now 2010-10-23 01:12 great :) 2010-10-23 01:15 kristaian u there ? 2010-10-23 01:16 still 2010-10-23 01:18 NN is not booting up ? 2010-10-23 01:20 i heard that before ;) 2010-10-23 01:22 nitin_gupta: if you tell us we can give more focused responses 2010-10-23 01:22 ok 2010-10-23 01:23 now tell me what to do in order to get NN up ? 2010-10-23 01:23 i'mm off 2010-10-23 01:23 chao ! 2010-10-23 01:33 wpwrak: it seems the first letter in a KiCad schematic reference is standardized somewaht 2010-10-23 01:33 C = capacitors, R = resistors 2010-10-23 01:33 U = ICs? 2010-10-23 01:33 X = crystals 2010-10-23 01:33 where is this documented? 2010-10-23 01:35 wolfspraul: are you sure it's documented somewhere ? ;-) 2010-10-23 01:39 [commit] Wolfgang Spraul: changed to cheaper 18pF crystal (was 12pF before), clarified X1 fields, changed C1/C3 to 33pF to match the crystal http://qi-hw.com/p/mmone-jtag-serial-cable/7f56822 2010-10-23 01:40 wolfspraul can u help me 2010-10-23 01:43 I just commited the crystal stuff we talked about. if you have a minute you can check whether you see a style problem. 2010-10-23 01:43 boomification is coming closer... 2010-10-23 01:46 nitin_gupta: I doubt it. 2010-10-23 01:46 what ? 2010-10-23 01:46 I doubt that I can help you. 2010-10-23 01:47 nitin_gupta: http://en.qi-hardware.com/wiki/Unbrick 2010-10-23 01:54 wolfspraul: looks good. now, filter parameters and led color (or, in both cases, just the part name, if you have something specific in mind) :) 2010-10-23 01:56 ah good point 2010-10-23 01:57 another comment (should be to KiCad though not you) - the silent creation of -cache.lib is really nasty 2010-10-23 01:57 I think what that means is that it's safer to just make the -cache.lib file part of what is being committed/tracked in the vcs 2010-10-23 01:58 I have also seen components only end up in that file (93c46), so I guess it is somehow possible in the KiCad GUI to have original components end up there. 2010-10-23 01:58 another serious bug 2010-10-23 01:58 so until KiCad fixes those serious bugs in how it creates, links to, and allows original data to creep into the -cache.lib file, we are better off always committing it 2010-10-23 01:58 what do you think? 2010-10-23 01:58 i tried http://en.qi-hardware.com/wiki/Updating_Ben_with_usbboot 2010-10-23 01:58 and after it only NN is not booting up 2010-10-23 01:59 now when i am issuing lsusb command then its vendor id is not coming up 2010-10-23 02:01 wolfspraul: dunno. i don't have such a file. maybe you want to find out what caused yours to get created ? 2010-10-23 02:02 wpwrak: for the filters, they are beads and current rating should be >= 500mA. Should I make a new field 'Type' and say "bead 1A"? 2010-10-23 02:03 well if you think we don't need to commit -cache.lib it's OK for me, I can manually delete it before commits. 2010-10-23 02:03 I'm just worried about the general usability of our tools. Yet another fairly specific thing to watch out for. 2010-10-23 02:05 in general, my understanding is we should leave all parameters that are not really hard requirement unspecified, to not overly restrict the part matching process later, in other words - all unspecified parameters can be chosen simply on price of component. 2010-10-23 02:05 maybe there are some borderline cases, say the color of the leds. could be different on each run :-) (theoretically) 2010-10-23 02:06 maybe also other values that _should_ be higher or lower for whatever reason, but don't totally have to 2010-10-23 02:06 so it's up to the design to make those decisions, which will then trickle into boom 2010-10-23 02:06 or to not make them, which means lower costs beats everything else 2010-10-23 02:06 correct me if I misunderstood something 2010-10-23 02:07 do you think KiCad schematics fields should always be upper-case? "BEAD 1A"? 2010-10-23 02:12 kristian I am not abel to get any hint for this case 2010-10-23 03:47 hi xiangfu 2010-10-23 03:47 i tried http://en.qi-hardware.com/wiki/Updating_Ben_with_usbboot to reflash NN but now it is not booting also 2010-10-23 04:22 wpwrak: in ben-wpan/bom/Makefile, do you want to take out the dk/ references and targets (and delete the entire ben-wpan/bom/dk folder maybe?). My understanding is that it has moved to eda-tools/boom/dist/dk and I get duplicate errors in ben-wpan unless I remove those references. 2010-10-23 04:23 I think boom-config is now taking care of it, again if I get this all right... 2010-10-23 04:31 do you have any future plans for ben-wpan/bom/lib/{captol.inc,e12.inc}? 2010-10-23 05:08 wpwrak: in ben-wpan/bom/Makefile, line 24 and line 29, I think there is an unneeded -r recursive flag in rm -rf 2010-10-23 06:07 no one can solve my prob ? 2010-10-23 06:40 wolfspraul: i don't have all the parts atusd needs in eda-tools/boom/ 2010-10-23 06:42 (yet) 2010-10-23 06:57 wpwrak: did you see the other two -r I found? I think they are not needed. Seems you have a trigger finger, when in doubt, rm -rf :-) Or are they needed there? 2010-10-23 06:57 ben-wpan/bom/Makefile, line 24 and 29 2010-10-23 07:00 ah, another question. the parameters for bom2part and part2order, equ/inv/chr files, do they have to be in a particular order? or are you always looking at the first line anyway? 2010-10-23 07:39 (params) you mean the file names ? different kinds of files can be in any order. files of the same kind may have an (undocumented :-) order dependency 2010-10-23 07:41 [commit] Werner Almesberger: More rm -rf to rm -f changes. http://qi-hw.com/p/ben-wpan/850e9fc 2010-10-23 07:41 (rm -rf) thanks ! 2010-10-23 07:42 plans for ben-wpan/bom/lib/: yes, deletion :) 2010-10-23 07:45 but please heed the warning in boom/UNDER-CONSTRUCTION :) all the stuff is unfinished and, particularly where it spans projects, full of design inconsistencies. what you can do is set up things so that boom will make a nice shopping list for you, but whatever you do, it won't be "right" for long, since things will change. 2010-10-23 07:46 (change) also simply by considering more user input. but again, it's not quite ready for throwing it at everyone in qi-hw 2010-10-23 07:54 (duplicates in ben-wpan) hmm, i don't get any. did you git pull everything to the latest version ? ben-wpan used to have things that conflicted, but i removed them several days ago. 2010-10-23 07:54 (migrated them over to eda-tools/boom) 2010-10-23 08:01 wpwrak: maybe I got the duplicates because I ran the queries against digikey later than you? 2010-10-23 08:01 I am fully aware of the state of boom. 2010-10-23 08:01 I thought that is precisely why I dive in now: 2010-10-23 08:01 a) to give you feedback (which I am doing already) 2010-10-23 08:01 b) to learn about the system myself, early on, so that I can use it for some small test projects, and later will be in a good position to hook it up for 'demo' use on the server too 2010-10-23 08:02 so far everything is great, I'm totally excited about it! 2010-10-23 08:02 if you find my feedback too unnerving, I slow down until you tell me it's ready. But I try to give feedback mostly on small details that are bugs or inconsistencies today, and will likely be carried over. 2010-10-23 08:03 or to confirm some design decisions with you, and maybe encourage you to document them somewhere because (at least to me) they were non-obvious at the beginning 2010-10-23 08:03 and you only get these types of impressions once, after a while the whole system looks naturally to you, even though it isn't from the outside... 2010-10-23 08:04 I think it works amzingly well already. I am generating my parts list now :-) 2010-10-23 08:07 (see things only once) this is unfortunately very true ... 2010-10-23 08:08 (parts list now) wow ! did you also modify the .sub for the value/value fields ? 2010-10-23 08:11 (feedback) yup, feedback is good. it's just that you're quickly entering known bug territory when you look for things now strictly part of what boom touches. e.g., the connection via INFO files. that's something that's never been exercised. all the INFOs do for now is provide a place to put comments and references in a semi-formal way. until there's a script somewhere that actually checks for referential integrity or - even better - ac 2010-10-23 08:11 tually does something with the data, they're completely unreliable. 2010-10-23 08:11 [commit] Wolfgang Spraul: added very first boom support files http://qi-hw.com/p/mmone-jtag-serial-cable/a05bb84 2010-10-23 08:11 wpwrak: I'm slow, just beginning with .sub now 2010-10-23 08:11 you'll find more problems e.g., in module naming. anything that's not in kicad-libs is to be treated with a great deal of suspicion 2010-10-23 08:11 .sub is where the fun lies :-) 2010-10-23 08:11 ah yes, no worries. I won't bug you further on BOOKSHELF and components/INFO. It's all clear to me now. 2010-10-23 08:11 yes of course 2010-10-23 08:12 I will probably start with BOOKSHELF first. 2010-10-23 08:12 a BOOKSHELF is a nice thing to have around :) 2010-10-23 08:13 btw, dsv can work with a hierarchy. so you could have things for project/ and more specific things for project/subproject/ 2010-10-23 08:13 I'm in no way worried about this deep-linking nonsense. If someone really comes forward with this, we will gladly remove deep-linking to their sites, and all their component characteristics and databases right with it. No problem. 2010-10-23 08:14 e.g., if your project has two different mcus, you could have an alias "mcu" in project/foo/ and another one in project/bar/ 2010-10-23 08:14 not sure if it's really useful, but at least it's there :) 2010-10-23 08:14 I don't need that right now. 2010-10-23 08:14 my needs are very modest 2010-10-23 08:14 :-) 2010-10-23 08:14 yeah, i think the deep-linking thing is excessive 2010-10-23 08:14 in fact I may even hard-wire many things, and bring in the logic later 2010-10-23 08:14 I just want to exercise the system, understand where it's going, etc. 2010-10-23 08:14 not run into all sorts of weird bugs now when it's not fully stable yet. 2010-10-23 08:15 btw I ran the queries against digikey, it took a few hours but it all worked. have over 11,000 parts locally now :-) 2010-10-23 08:15 it may also have troubles in court, if it should come to that. most of the rulings that went very far in favour of the side being linked to are old, from times when judges didn't quite understand that internet thing yet 2010-10-23 08:16 and then there are deep linking decisions in cases where there was clearly an abuse. such as pretending the data belonged to the linker. but we don't even remotely do such things 2010-10-23 08:17 (digi-key queries) kewl :) when things have matured a bit more, it would make sense to provide database snapshots for easy download. if you bzip2 the database, is shrinks to only about 10% 2010-10-23 08:18 you can see a very very early version of that idea in the "tar" target of eda-tools/boom/Makefile. but the file name doesn't make much sense yet, of course 2010-10-23 08:19 ah, and to fully bring up boom, you also need toÂ Â cd manu; for n in *; do make -C $n; done 2010-10-23 08:19 another one of these construction sites :) 2010-10-23 08:25 wpwrak: yes sure over time we should include multiple distributors, multiple manufacturers. and make it downloadable, definitely. 2010-10-23 08:26 one by one 2010-10-23 08:26 no need to get stuck on this now and let it bloat. using it for real projects is the best growth medicine. 2010-10-23 08:27 yup. something you don't use has a very high risk of being wrong anyway :) 2010-10-23 08:33 wpwrak: ahh, did you see my older questions when you were asleep? 2010-10-23 08:33 about the fields for filters, whether I should say "BEAD 1A" 2010-10-23 08:34 and for the LED, similar, which fields you would use to record the color, or the Vf Typ (if at all) 2010-10-23 08:38 oh, there were more :) checking ... 2010-10-23 08:38 tuxbrain: I have news for you 2010-10-23 08:38 tuxbrain: tuxbrain tuxbrain tuxbrain 2010-10-23 08:40 (fields) the field name isn't exported to the .lst file, so boom doesn't care what you put there :) (and yes, i'd rather wish this was different) 2010-10-23 08:41 [field name] oh good point, I didn't think about that. So I can just use spaces then. 2010-10-23 08:42 (led color) there's indeed a tricky issue here. what do you do with parts that change after the schematics ? you could have a per-production run .sub or .equ file, of course. not sure on which side of the fine line between relative sanity and raving madness this lies, though 2010-10-23 08:43 in my mind the design files, including .sub/.equ, express the full idea of the designer, including priorities 2010-10-23 08:43 so if people favor stability/quality, it will be expressed there 2010-10-23 08:43 and if they favor price, same 2010-10-23 08:43 (specify as little as possible in general) yes, letting the price decide is usually a good idea :) if you over-specify, you may lead boom to exotic parts, either because they're at the end of the range of available values or just because the combination of values is rare 2010-10-23 08:44 what would you put in for the beads, specifically? (and the leds) 2010-10-23 08:44 (-cache.lib) for some reason, i don't get this at all (in recent designs - i've seen it before, though). maybe i'm just lucky ;-) 2010-10-23 08:46 (bead current) it's not the type of the bead. it's its maximum current :) i'd associate "type" more with the materials and physical structure of the bead. 2010-10-23 08:46 rafa: what hapens!! 2010-10-23 08:46 sorry I was little out 2010-10-23 08:46 I see you have some in ben-wpan, I will just follow what you did there. 2010-10-23 08:46 the maximum current could be called something like I or Imax 2010-10-23 08:47 yes just saw it 2010-10-23 08:47 I will follow ben-wpan 2010-10-23 08:47 tuxbrain: can you test something and tell me if you are a bit happier? 2010-10-23 08:47 tuxbrain: (on nn) 2010-10-23 08:47 uff not until Wensday 2010-10-23 08:47 tuxbrain: okey.. I will try to record a video 2010-10-23 08:47 the ones in ben-wpan probably don't help much. there it's just size and inductance. they're inductors, not beads. (but don't ask me what exactly the difference is ;-) 2010-10-23 08:47 tuxbrain:Â Â I need your opinion/suggestions to continue 2010-10-23 08:48 ok 2010-10-23 08:48 tuxbrain: it is theora video ;) 2010-10-23 08:48 take for sure I will get it to it ASAP but I must end somthing with a dead line 2010-10-23 08:49 tuxbrain: no problem.. but I think that these are good news.. so I will try to record something 2010-10-23 08:49 tuxbrain: so you can check 2010-10-23 08:49 btw I love you rafa :**** 2010-10-23 08:50 ssshhh.. no our love here 2010-10-23 08:50 it is logged, public, the whole world will know 2010-10-23 08:52 rafa: are you playing theora in ben mplayer with no slowness?? 2010-10-23 08:53 kristianpaul: yes.. but i did not do much.. it is almost working out of the box.. just that we are lazy and blind 2010-10-23 08:53 rafa: how is posible?? 2010-10-23 08:53 (blind) indeed 2010-10-23 08:54 you finded better use for SIMD instructioons? 2010-10-23 08:54 you changed the way to encode ogg? 2010-10-23 08:55 wpwrak: are you sure? in atrf.sub, I have a D* TYPE=FILTER M=BEAD 2010-10-23 08:55 "BEAD" means inductor? 2010-10-23 08:56 kristianpaul: yes, I was playing with mencoder and ffmpeg encode options 2010-10-23 08:57 kristianpaul: and trying the theora player example which comes with libtheora 2010-10-23 08:57 kristianpaul: but I realized that mplayer also is okey, or better than example 2010-10-23 08:59 wolfspraul: ah .. right. i have something there. that's still untouched from gta02-core. as i said, i'm not entirely sure how to classify beads. my understanding is that they're basically inductors, but they're not specified in terms of inductance. 2010-10-23 08:59 wolfspraul: rather, they're specified in terms of their filtering properties. so this would need someone with a bit more EE background than me to figure out. 2010-10-23 09:00 wolfspraul: the current stuff is very pragmatic - i just map it in terms of use, even if this may not be "correct". 2010-10-23 09:03 wpwrak: k got it. 2010-10-23 09:05 so beads are not included in the current dist or manu databases yet 2010-10-23 09:06 no, only smt ceramic caps and smt resistors 2010-10-23 09:06 no inductors, no beads, no semiconductors, no non-ceramic caps, no though-hole, no connectors, etc. 2010-10-23 09:07 that's why you still need those project-specific dk/ :) 2010-10-23 09:21 wpwrak: how does bom2part determine the namespace if the characteristics matching failed? 2010-10-23 09:21 for example in ben-wpan, there is ATRF meander 2010-10-23 09:21 in the .sub file, it only says FP=meander -> VAL=meander 2010-10-23 09:22 then there is an .inv file that gives virtual inventory for ATRF meander 999999 ... 2010-10-23 09:22 but how does it go from the VAL=meander to ATRF meander? 2010-10-23 09:22 before characteristics mathcing, it tries value matching. if there's a part with part number == value, it takes that one 2010-10-23 09:22 (irrespective of name space) 2010-10-23 09:22 oh 2010-10-23 09:22 (see also my reply to adam ;-) 2010-10-23 09:23 I read that one, but it must have slipped my attention. 2010-10-23 09:23 I don't think this is mentioned in README. 2010-10-23 09:23 (.inv) yup, that's what it usses 2010-10-23 09:23 sure I just didn't know where the translation from VAL=meander to namespace + part-number was made 2010-10-23 09:23 so if the VAL matches a part-number, no matter in which namespace, that always trumps everything else 2010-10-23 09:23 yes 2010-10-23 09:24 got it 2010-10-23 09:24 I think this is not mentioned in README. Or under-represented. 2010-10-23 09:26 README is very incomplete ... 2010-10-23 09:27 I think it's pretty good, I can recommend it to anyone else, definitely. 2010-10-23 09:27 like I said, I would only change the order of the sections. 2010-10-23 09:27 and this little missing 'jump' I found now, from value to part-number. 2010-10-23 09:27 i'm also not sure if i really like this matching algorithm. it works well for small databases, but it may cause problems (i.e., false matches) if the database grows. 2010-10-23 09:28 you mean the one using characteristics? 2010-10-23 09:28 perhaps boom should complain if there's more than one part number hit, and have some means for also specifying a name space 2010-10-23 09:28 or the one that turns a value into a part-number? 2010-10-23 09:28 the latter 2010-10-23 09:28 ah yes 2010-10-23 09:28 it's a little risky :-) 2010-10-23 09:28 i hope characteristics matching is relatively safe :) 2010-10-23 09:29 to make characteristics matching even better, there should be a means to interactively query the database, like the parametric search in digi-key 2010-10-23 09:29 maybe a specific 'catch' in a characteristics file would be better? 2010-10-23 09:30 well sure, one by one. there are many ways to query and work with this data. 2010-10-23 09:30 how would the catch work ? 2010-10-23 09:30 the catch catches a specific value, and maps it to namespace/part-number 2010-10-23 09:30 (interactive) that way, one could poke around before committing to a set of parameters. e.g., if a part is under-specified, one would probably notice. likewise, if it's over-specified. 2010-10-23 09:31 actually I was looking for a atrf.chr file to do just that, because I didn't know how the VAL=meander would make it directly to the .inv file 2010-10-23 09:31 ah, that's not a role for .chr files 2010-10-23 09:31 well yeah, so you just have an invisible direct bypass instead :-) 2010-10-23 09:32 but you have the project-specific .equ and you can also do mappings in .sub (gta02-core has a lot of the latter. i don't like them so much anymore, though) 2010-10-23 09:32 yes but in the .sub you always stay 'behind' the characteristics barrier 2010-10-23 09:32 you are setting fields, but you cannot specify a namespace/part-number, or can you? 2010-10-23 09:32 the sequence is: VAL -> PN match. if unsuccessful, do the substitutions, then 2010-10-23 09:33 try VAL -> PN again. (.sub may substitute VAL). if you still don't have a hit, 2010-10-23 09:33 do the characteristics search 2010-10-23 09:33 .sub currently can't specify a name space. it can mess with the value, though 2010-10-23 09:34 yes I saw that already 2010-10-23 09:34 I see it like a .chr bypass 2010-10-23 09:34 set the val to a known part-number and you bypass the .chr 2010-10-23 09:35 in a way, yes. there are basically two kinds of parts - the ones you identify by characteristics and the ones you identify by part number 2010-10-23 09:36 e.g., there's little reason to try to select the Jz4720 by characteristics, for there are way too many that have to be exactly right (and they're heavily redundant, too) 2010-10-23 09:36 but for things like reistors and the like, this works well. so characteristics are mainly for "simple" parts 2010-10-23 09:37 for more complex ones, you'll always want just the part number 2010-10-23 09:38 note that you can have a 1:n mapping by introducing your own PNs. e.g., you can have an equivalence QIHW BEN-CPU INGENIC JZ4720 2010-10-23 09:38 if the make a JZ4721 some day that differs in some details but is sufficiently compatible, you could add an equivalence QIHW BEN-CPU INGENIC JZ4721. then boom could pick either. 2010-10-23 09:39 yes sure 2010-10-23 09:40