crossfade.py was used to check how the crossfade method performed on two test sine waves. scale.py generates the values to transpose the data according to the musical scale.
being inspired by ch00ftech's QR clock [1] I made my own variation of this nice idea: A PIC32 decodes the time signal from a DCF77 [2] receiver, calculates a QR code containing this time information, and displays it animated at 30 FPS on a ST7735R LCD. Without a radio signal the QR code is being displayed in b/w. A nice plasma effect is added when it locks to the DCF77 signal.
I see. Maybe you could have opted for the non-USB version PIC32MX130 to have more IO pins and use the USB connector only for charging. Although then the firmware could only be updated with a PICkit 3.
BTW, the HID bootloader takes quite some amount of flash, so you might have little left for your firmware. Maybe the PIC32MX250 is better suited.
Anyways, very cool project. Looking forward to updates from you :)
I would really prefer to have some kind of ICSP pins/holes/pads on the PCB: 1) programming the bootloader before soldering the PIC32 is cumbersome. 2) Development of the firmware without debugging capability is really a pain.
If PCB real estate is a concern: I used some small custom 50 mil spaced pin headers, which work fine and don't take much space on the PCB.
I like your idea of a plug-and-play XTAL solution for breadboarding. I had to use some XTAL to get USB communication working with a PIC32. (It won't enumerate using the built-in RC oscillator.) Until I saw your post, I had a fearsome XTAL and SMD-capatcitor air-wire construction on my breadboard.
I had a DP protoboard [1] lying around, which contains an SMD XTAL footprint together with two capacitors. [attachment=2] Soldering was done using solder paste and my new (really cheap 16 €) hot air gun [2]. [attachment=1] The result looks ok and works fine. [attachment=0] Cheers, Markus
@Bertho: My question was not about crystals, but about ceramic resonators. They have the load capacitors already built-in. My question was why are there different models of the same ceramic resonator available only differing in the value of the built-in load capacitors. Depending on what should one choose one with 15 pF in contrast to one with 30 pF built-in load capacitance.
[quote author="matseng"]It's an golden opportunity to do some torture testing and add a lot of extra capacitance to it. If it can start with say 56pF caps added a pair of 18pF or 12pF should be fine.[/quote] @matseng: Not directly related to your project, but I have the feeling you could know the answer: I use a ceramic resonator for my project and wonder which model I should choose, depending on the value of the built-in load capacitance.
I understand that the external load capacitors of XTALs should match the values specified in the XTAL datasheet, but what makes it necessary for ceramic resonators to be available with different built-in load capacitances.
I tried to find an answer using Google, but without any success.
I am currently in the process of designing a variant of the Logic Shrimp v2b. This one has 8 channels, uses a PIC32, and fits onto a 3cm x 3cm board. Here is a first rendering:
[attachment=0] I made some performance tests with the CDC example on a PIC32 clocked at 80 MHz, and they showed that the 256 kSamples can be sent to the PC in about 0.5 seconds. Promising.
I also plan to overclock the serial RAM chips to achieve more than 20 MSamples/s. Has anyone tried this already?
Or, alternatively, the .cfg files could contain a new entry which specifies the sample-count multiplier, and which defaults to 4 when it is missing. This way the protocol would also be backwards compatible and could continue to use two byte values for the sample read and delay count.
I too got my free PCB on Friday (thanks a lot!) and built it over the weekend.
[attachment=3] I made a quick proto board containing the MSP430G2553 to free up my LaunchPad for other things.
[attachment=2] [attachment=1] Further, I added a connection from the FTDI board's VCC pin to power the circuit.
[attachment=0] From reading the serial RAM datasheet I was a bit concerned that the 50 mA which the FTDI chip can provide might not be enough (since the maximum read current at 20 MHz is specified to be 10 mA per RAM chip), but it turns out the whole circuit consumes just about 15 mA.
@hlipka: The baud rate definition in main.c was already mentioned earlier in this thread :)
Currently I am waiting for the 5 cm x 5 cm Sick of Beige cases to appear at Seeed Studios store, and for a new version of the OLS which hopefully will fix the serial buffer overflow issue at higher baud rates.
[quote author="oPossum"]I prefer to have something that can be used with the whole Launchpad family - MSP430, C2000 & Stellaris.[/quote] Although it might be desirable to have the board reroutet for other LaunchPad members anyway, to better match the port-to-pin mapping. For example I had a quick look at the Stellaris LaunchPad and the P2.0-P2.5 data lines from the Logic Boost are placed quite randomly between the ports of the Stellaris chip.
@oPossum: Do you plan to write a firmware for the Stellaris Launchpad which interfaces with your Logic Boost?
[quote author="matseng"]Putting a small blob of solder on the bottom pad will make the connection between the pcb and the battery more reliable[/quote] Have you seen this? http://www.thingamafob.com/pcb-design-k ... connected/
Here, the solder mask around the battery is removed to improve the contact.