Thanks to the FreePCB drawer, I got my hands on a LogicBoost board. I got it build up last weekend, and after discovering that I need to swap RX and TX on my launchpad it worked without problems (it's a 1.3 version which doesn't work with the hardware UART ouf-of-the-box). I have written up a blog post about it, with more detail of the build and some pictures. Here just the one from the build:
Next step will be building a USB-to-UART cable, to have it connect faster than 9600 baud. My main gripe is that the FTDI header doesn't use the Vcc pin, so I cannot power the board via USB in an easy way (an additional connector to the power pins is needed...).
Btw: the baud rate definition in main.c has a small error - the value is defined as int, not as long, so the compiler mangles this when setting a larger value like 115200...
Thanks for this design, it is a neat little board and will be quite useful in my toolbox.
I think it won't fit into 64 cells, but should work with 128. What you basically need is a 32bit shift register (serial in, parallel out) followed by a 32bit latch (so state won't change when receiving data). This needs 64 cells. Then you would need a 5bit-counter (for frame sync) and maybe some glue logic. So you end up with about 70-something cells, I think.
As an example what you can do with 64 cells, look at http://http://blog.hendriklipka.de/archives/2012/07/freqcounter_cpld2.html. This is an example for a frequency counter which has constant precision (so it measures even 1Hz signals with about 1ppm resolution). This is something which needs about 16 or 17 discrete 74xx chips, maybe even more.
I had a similiar thought a while ago. I had designed a breakout board for the Simple Switcher series from TI/National (LMZ1200x). It is small enough to fit 4 of them on a single 5x5cm board. So the smallest order I can get from Seed or ITead would be 40 boards, which is way more than I need. But it might be a nice board for the drawer...
[quote author="arakis"]It also states PGEC PGED, MCLR on those pins that are ICSP, and we know those are multiplexed port pins...[/quote] You are looking at the socket, right? I was referring to the chip on the right hand side of the schematic. There the ICSP-pins are marked as IO-Ports, but the oscillator pins are not. What I missed: the USB-pins are usable as IO-Pins (RB10/11), so this makes 17 (but only when not using USB :(
I'm not sure you get more pins - in the MicroStick schematic there two pins are labeled HPOSC/HPOSCEN, without any port naming on them.So you stay with 15 pins there :(
I also used a ceramic cap, and it seems that this causes no problems. The problem here is the footprint - nearly all LDOs compatible to the LD1117 don't like ceramic caps. And the LDOs which can use them typical have another pin order (for most it is in/gnd/out, which I found more sensible anyways). But a 1206 footprint makes it easier to source the caps.
It's listed as "future product", meaning nobody knows when it will be available :( But USB without external crystal is great for even smaller breakout boards...
So today I finished my free PCB build too. I did not populate the large header yet, because I have not decided how to use it - will it be more for breadboard use, or shall it go to a permanent project (I'm working on a more accurate frequency meter project)? [attachment=0] As you can see I have populated the oscillator, which was rather difficult with just solder iron. But the cap near it was even more difficult, because it is located so near to the oscillator. This is also true for most of the other components - many of them a way too close of each other. The most *1117 regulators want to have tantalum capacitors, which are in larger packages than 0603 (I'm surprised that Schazamp got one in 0805 - most are 1206 or even larger). Soldering the TQFP100 package was way easier than I thought. It lined up properly with the second try, and the last side was a nearly perfect drag soldering example (but I needed some cleanup on the other sides). I bridged Vio, since I don't intend to use it with other voltages than 3.3V. But it worked without hiccups from the beginning, so I should not complain too much :) My test project was just a frequency divider, which divides the 48MHz from the oscillator by 2^24, which gives nice 2.3Hz on the green LED (connector to P73). One can see it lit up in the back...
I think your problem arises from the fact that the software doesn't know the external clock frequency :) And since it is only 1/4th of the normal time base, it sees your test signal at 4 times of what it really is.
[quote author="octal"] Most of the XC32 new header files (and ALL processors related ones) starts with:
Quote
--snipped--
[/quote]
This is a standard BSD / MIT licence. According to the GPL FAQ it is not compatible with the GPL (because of the advertising clause). Actually this license is rather permissive (since you are not required to re-distribute the sources), but for your purposes it might get difficult. But you should read the GPL FAQ, since the GPL applies only when you are really creating a 'derivative' work. Just delivering the GCC assembler and linker doesn't put the header files under the same license. And GCC itself doesn't provide any headers which are included with your code.
Ah, you beat me to it :( My order with the CPLD arrived only today... My plans include to solder the oscillator too, since I want to build a frequency counter out of it (or maybe something else, but at least it will need the oscillator). Without a hot air station this will be my greatest challenge.
A multimeter might easily take half a volt of burden voltage, maybe even more. So its not easy to distinguish it from a diode. A small resistor (like to uCurrent) or a hall-based sensor (the one from Honeywell or the ACS712) might be better.
Short answer: yes and maybe. Long answer: It's no problem to directly route signals through the CPLD without any latches. There will be buffers, since the CPLD somehow needs to drive the lines (the resistance of the internal interconnects can easily be 1k or so, so it's not like a direct wire). But I2C will be a little bit of work. Most (if not any) CPLDs I know of don't have open drain outputs, so you need to simulate them. To do that, you connect (physically on your board) an output and an input together (to simulate a bi-directional connection). The output needs to be driven to 0 if a 0 needs to be send and is disabled (driven to High-Z) when a 1 needs to be send (look at http://http://www.xilinx.com/support/answers/6717.htm for an example).
