since my roots are in the software world I have used team collaboration tools for many of my projects.
I know there are many tools which are perfectly fitted for software engineering by having tools such as repository browsers, code review, ticket (issue) systems and so on.
In my opinion many of these techniques are also usable for electronic engineering. I wanted to ask the community and the engineers: What do you think?
What are the tools needed for good team collaboration for electronic engineers?
What do you expect from a good team collaboration software?
What I though of: The classic ones: Ticket/Issue system Tasks and Milestones Messages/Blog/Forum/etc. "Design review" where you can add a comment to anything inside a library, schematic or PCB design. This could be displayed in a graphical way so you have "post-its" on your design. This would be the really tricky thing.
I'm thinking about creating an open source, web-based team collaboration platform. Since there are many for software engineers I though of one for electronic engineering.
I just found out (I don't know if this exists for a long time or if this is new or if this was posted here already) that ITeadStudio can produce 4 layer PCBs :).
on Thursday I visited the Frankfurter Buchmesse (a book fair in Frankfurt, Germany). There was an extra building by the car manufacturer Audi which had lot of Audi stuff inside and a room for some antique things.
In the main room of this building there were a few cars standing around and an art installation.
The art installation is the mainly interesting thing:
For rows of 34 thermal printers each. All 136 thermal printers were printing - guess what - twitter messages.
It was impressive - an impressive waste of paper :)
The file IMG_20111013_142304.jpg shows the waste of paper on the second day - I don't know if they already removed some of the paper or not.
Just wanted to share those photos with you (sadly I only had my smartphone for photos and not much time).
it's been a long time but I just wanted to give an update.
I had the PCB for my forked BusBlaster laying around for some months now - I just didn't have to time, money and motivation to buy the needed parts and solder it together - my Signalyzer Lite worked well for me.
But now I have done it :)
It works very well, all pins are available on pin headers and all pins of the FT2232H are available on the CPLD. I wrote two BufferLogics in Verilog: KT-Link and JTAGkey - both work very well.
The KT-Link logic has support for the SWO channel of SWD. Since you already have a Verilog version of JTAGKey I just appended the Verilog version of the KT-Link.
I had some errors on the PCB: Two power pins of the CPLD are not connected to the corresponding net since KiCad doesn't connect the power symbol with a net if you just drop it onto the net line -.-. These are things I learned with my other projects so I would have done this in an other way ^^
Also I wouldn't route the PCB with the freerouting autorouter now. It results in ugly traces and you won't see errors like the above.
One other failure: I connected all **BUS pins of the FT2232H to the CPLD. The CPLD uses the BDBUS1 pin for SWO when programmed with the KT-Link firmware. Sadly the same pin is the JTAG TDI pin when programming the CPLD via the second FT2232H port (there's a buffer which enables the JTAG signals for the CPLD). So if you program the CPLD with the KT-Link firmware JTAG will not work for the CPLD.
I fixed this by connecting a free IO pin of the CPLD with the "JTAG enable" jumper and modifying the KT-Link firmware so it sets the CPLD pin connected to BDBUS1 to 1'bz. This fixes the problem.
Don't ask how long it did take for me to find that problem oO. I thought it would be a defect buffer or something and even replaced it one time oO.
I attached a picture of the PCB (yes, I didn't clean it ;) ). I like it because it is a breakout board for both of the two chips and also a JTAG debugger...
[quote author="brian"]After reading the first line I was going to say: Atmel. Then I read you don't like them. Hummm well I have to say my experience has been a *lot* better with Atmel then ST. Atmel's manuals were sane. ST for the STM32 I had to use 3 or 4 PDFs to get all the info I wanted.[/quote]
Well, there's no real reason why I don't like Atmels. It's more a thing of 'I like to be different' ;) Here in Germany the hobbyists seem to not use any other thing than Atmel - if there's any question the answer is "there is something from Atmel...". Nothing against Atmels products :).
[quote author="brian"] If you want to program the FPGA directly yeah I guess I would put on a FT2232 if not I would just use an external JTAG... I never integrate anything I can avoid unless it is a massive convenience, just raises the cost of the board and increases the complexity of the PCB.[/quote]
Thats a good point - I think I will not integrate it. It was more a question of "do people like something like JTAG integrated?".
[quote author="brian"] Maybe you should consider the Freescale Kinetis parts. M4 > M3 and they have HS USB. I'm sure the STM32 is fine also it is a more mature chip line to work with at this point.[/quote]
I will have a look at them, thanks for the hint. I personally never had a problem with the STM32 line but I didn't have very big projects... I have heard a lot good things about it and a lot bad things - as I have about many other product from other manufacturers :).
I think if I don't find something other which fits I will stay with the STM32.
My choice fell to the STM32 mainly because of the High-Speed USB capability. Sadly I didn't find any other ARM with HS USB that doesn't come in a BGA package. There is one from Atmel but I have to say that I don't want to use an Atmel :) I don't like Atmel very much.
The USB High-Speed is something I truly wanna have on this board.
Regarding the IDE: Because I mainly do this for myself this is no criteria for me. I'm a happy user of a cross-compile GNU GCC toolchain under Linux and using Eclipse.
I like the Cortex-M3 mikrocontrollers very much so I would like to use a Cortex-M3. But any other ARM is also OK. The new STM32 has also more power than others due to it's 120 MHz core clock. That is nothing I need truly but if I can have it - why not? :)
Nils
PS: One other thing, what do you think? Onboard FT2232H? One channel JTAG (USB -> FT2232H -> Cortex-M3 -> FPGA -> FT2232H -> USB) and one channel direct communication with the FPGA? Or just a FT232H for communication with the FPGA over USB or just one for JTAG? Or none at all?
my new project is to develop a development board containing an ARM microcontroller and a FPGA (much like the LeafLabs oak it seems).
My choice for the micro is the new STM32F207 (ZE I think).
I'm struggling with the FPGA.
I would like to use something I never worked with and that would be an Altera FPGA. My "problem" is that the Xilinx Spartan 3E FPGAs come in a PQFP208 package even for the XC3S250E which, I think, has plenty of space (if not it can be changed against the 500k version). The XC3S250E comes with a price of ~20€ @ 1 here in Germany.
Since I don't want just 144 pins I searched for an Altera Cyclone with > 144 pins and found the EP3C16Q240C8N which comes in a PQFP240 package (240 pins? wtf? who needs BGA :D).
The downsite of this is that the chip would cost ~32€ @ 1. But compared to the Xilinx (compared with the compare table on the Altera website at http://http://www.altera.com/cgi-bin/device_compare.pl) it is much bigger than the Xilinx XC3S250E and even has more space than the XC3S500E (the Altera chip would roughly be like an XC3S750E if it would exist :) ). The XC3S500E would be at 27€ @ 1. So the Altera solution is much cheaper for what you get than the Xilinx solution but more expensive when ~5000 LC/LE would be enough...
So my question: What is your opinion? Which one should I choose? Also statet the possibility that there could be a small manufacturing run if people are interested in this? (that's an unrealistic thought I think but who knows...)
The other chips aren't very cheap, too. The STM32 comes at ~10€ @ 1 via Digikey and there should be a SDRAM and eventually a SRAM which are about 10€ each, too.
I've just designed my own CNC control (driven by EMC on a linux PC via parallel port).
The logic behind that is extremly simple since all the work is done by EMC.
In the long run I want to have a controller which gets GCode via USB and executes that so I don't have to have a dedicated PC for that. This will be really hard work since one would have to write a complete GCode interpreter and with just the simple thing of "I know how to move" there is no fun... It also needs stuff like automatically measuring tool length offsets when changing the tool and such stuff.
Anyway, my stepper drivers are also designed by me. I'm using the Allegro A3986. It's basically a dual H-Bridge driver. Implements up to 1/16 step, slow, fast and mixed decay, synchronous rectification. All it needs is a step/dir input, an analog voltage (0.8V to 2V) for setting the current maximum and two H-Bridges.
I used the IRLR024Z mosfets for the H-Bridge. For these I paid 0,381 EUR @ 32. Plus ~5 EUR for the Allegro chip plus some small stuff. At the end one the the drivers (I built for) did cost me ~30EUR and iI can drive steppers with up to 4A per coil. If I had used a smaller sense resistor (currently 0.05 Ohms) orsome rated higher than 1W I could drive steppers with up to 10A per coil...
I love these chips - now I can finally drive my CNC steppers @4A/coil and 48V :)
I installed Xilinx ISE 13.1 (WebPack) on my Ubuntu 10.10 and just did my first work with Verilog and uploaded it successfully via the ols-loader utility onto my OLS abusing it as a development board :).
No problems here, just did the Xilinx install (installed into ~/ISE_DS as it suggested) and it worked...
Nils
PS: 1 or 2 years ago I had the 10.x version running on ArchLinux because of the university (FPU coprocessor for a MIPS core, wtf... ^^). It was a little bit tricky to install but once it worked I had no problems.
Yah I know I. I'm just lazy :D. I think I will take a closer look at the PICs and then decide if I will use them :).
The idea of a remote control is nice. Did you think of a "true" remote control for TVs with IR-code learning or did you thought of a simpler application?
That's a good hint, thank you a lot. My only concerns about the PIC's are the fact that I would have to use two different toolchains (STM32 = Eclipse + GCC, PIC = proprietary software). Also I've never done anything with the PIC's and I don't know if interfacing capacitive touch buttons is the right thing to start with.
On the other side: The PIC18F45K22 seems to support up to 28 analog channels and with mTouch that means up to 28 capacitive touch buttons... and it's only about 4€ @ 1. That's very nice :).
I have some other parts in the project where a SPI -> UART conversion is needed. This is on expansion boards so every board holds it's own controller. Maybe I could also use a PIC there instead of an atmel (cheap) or STM32F100 (also cheap ;) ).
Anyone has a reason why I should use a PIC for this and not a STM32?
for my current project I will have to design a PCB which will hold a controller (maybe I will use some ATtiny oder ATmega's, they are cheap... But the STM32F100 series is also cheap :) ) which is interfaced by a SPI interface and some capacitive touch buttons (using http://http://www.atmel.com/dyn/products/devices.asp?category_id=170&family_id=702&subfamily_id=2259: Atmels QTouch). I also would use a PIC but I've never done anything with it... :).
The plan is to have some simple buttons (maybe with LED in the middle) and one slider. I would like to have a wheel slider (e.g. for menus) but I don't know if this will fit the project.
Maybe this is a thing in which other people are interested? Maybe this could be something for DP?
I chose QTouch at this point because it's damn simple and only consists of one resistor, capacitor and electrode for one touch field. And it can be implemented with a few lines of code on every microcontroller which supports putting it's pins to a floating state.
Any suggestions? Any things you would like to see?
I think I like the possibility to have two different versions.
A JTAG programmer, which should be buyable on good terms, should work for the most people. Having them to pay maybe $6 more because of a feature they don't ever use is maybe not so great.
But having the possibility to give a SWV supporting programmer to the ones who really needs it is a nice thing. And I think they will be willing to pay the $6 more to have the possibility. Maybe there could also be the option to populate some break out pin headers in the new version so one could be doing more with it than plain JTAG/SWD/SWV. Then one has even more for the higher price than only the SWV functionality.
I also think you could take the advantage of having the software support out there if you wait for it - the v2 is there as a JTAG programmer so the v3 can wait. And having the possibility to test it could be very nice ^^
One more thing: The only thing you can't implement at the moment is the plain UART style SWV - but maybe there will be an other mode you can implement? Maybe the plain UART style will be not-so-supported in for example OpenOCD. I don't know ^^. So it could be good to wait for the real software support...
I just got up so I'm still a little bit confused ;).
I just read the "CPLD resources" thread and stumbled upon your entry:
[quote author="ian"] Bus Blaster v2 has a CPLD instead of the 5 buffer chips. It is $5 cheaper @ 100. Instead of strugging finding the right combination of logic (like we did for over 6 months designing v1), we just drew this schematic and synthesized it for the CPLD: [/quote]
I you start now with combining the CPLD with logic chips you have the same problem you were solving with the CPLD...
Another possibility is however to discard the KT-Link SWV support thing and concentrate on the plain JTAG functionality. SWD without SWV would still be supported because the only thing that needs the BBUS is the UART style SWV which isn't mandatory.
