My experience (albeit with KiCad) has been that the board dimensions are defined by the center of the polygon outline. This is not a copper trace, but just a rectangle (or more complex polygon) drawn on the board dimension layer (or whatever your board house uses).
So if I draw a 50x50mm rectangle on the board dimension layer, it doesn't matter how "wide" the line is; the center of the polygon outline defines the board dimensions.
Hope this helps; please correct me if I am mistaken! :-)
[quote author="CJlano"]As I said before, my panelization is made of a single 2x10mm slot (I think it is what you consider as milling) + 5-hole series for mouse bites. The slot is actually an "oval hole". So everything is included in the drill file.[/quote] How did you specify the slot in KiCad? Make a component with an oval hole the desired size, no copper pad?
Not sure about the AOYUE 968. I have the AOYUE Int 2900, which is a digital-readout, temperature-controlled pencil iron. I got it from SparkFun Electronics a year or two ago.
It's decent, or at least it was until I started having trouble with the handle losing connection with the tip. Often when I use the iron, the base will start beeping at me, and the tip will stop heating up. After about 10 seconds or so, the base re-acquires a temperature reading and starts heating up the tip again. Very annoying!
[quote author="matseng"]At every zero crossing the ADC value will serially be sent as two bytes via the optocoupler to the main board.[/quote] Watch out for byte alignment issues! If the main board starts receiving (on powerup perhaps) in the middle of the 2-byte transmission, the main board will think that Byte 2 is really Byte 1 of a two-byte packet.
Instead, could you send a three-byte packet with a fixed-value header? That way you can detect the start-of-packet even if the main board gets out of sync with the sending board. If the receiver sees an initial byte that is not the start-of-packet value, it can wait until it does see the expected value.
If you want to get REALLY fancy, then add a fourth byte for a checksum! :-)
Yeah, I think I'll steer clear. While I'd certainly be up for buying a $60 Android tablet if it's hackable (and if it works at all), it's not worth the risk in this case. :-)
[quote author="Flavor"]Should it be pretty straightforward with the Xilinx USB cable?[/quote] Probably? I don't know what readback features the XC9536XL supports. iMPACT with the Xilinx USB cable should be your best bet, though. Plug in the cable, fire up iMPACT, choose Initialize JTAG Chain, then right-click the XC9536XL and see what options you get!
Looks like the FPGA still isn't being detected correctly.
I'm pretty sure there is a way to convert a .MCS file to a .SVF file. In iMPACT there should be an option to write a .SVF file instead of programming through a JTAG cable. Select that, then program the FPGA with a bitstream (or the Platform Flash with a .MCS file), then finish the .SVF file output (should be the same menu path as starting it).
Sorry, I don't have iMPACT handy to check the details. It's been a while since I tried this. :-)
iMPACT can read and program Xilinx CPLDs and FPGAs, but I don't know if the XC9536XL supports reading back the configuration bitstream. I'm pretty sure the FPGAs I use do not support readback (at least through iMPACT).
Open Source Hardware