Skip to main content

Topics

This section allows you to view all Topics made by this member. Note that you can only see Topics made in areas you currently have access to.

Topics - udif

1
Open 7400 Competition / [Entry]A CPLD based 8x8 game-of-life
Sorry for the terse post, but my time is running out (deadline in a few hours).

My entry to the 7400 competition is a CPLD based 8x8 game of life.
Yes, I saw there was another 8x8 game of life posted in the competition forum, but when I saw it in the forum it was too late for me to change mine, and anyhow the designs are entirely different.

Please be sure to check the REAMDME.txt file in the attached ZIP with  all the details.

Pictures:
https://picasaweb.google.com/udi.finkel ... _Suo6my7wE

Video:
http://youtu.be/2Ykv4kL7CUk

Here is a short quote from the README file:
Quote
Algorithm:
A 64 bit cyclic shift register is shifted to the right on every cycle. cell 0 is always the center cell, and a 6 bit row/column counter tracks the logical position of this cell. The neighbouring cells are collected, taking into account the playing field edges (we dont wrap around), and the resulting nine bits are summed. The sum output and current cell value are used to calculate the new cell value. The output value is then pushed into a shift register so that the new value won't affect the remaining calculation for this generation. The shift register replaces the old value at the point where it can no longer affect current gen calculations.
New starting patters can be entered by a joystick that moves up/down/left/right and a center button that toggles the current cell value.
The next gen is calculated by pressing a switch.

Implementation:
The project was coded in Verilog, using many small modules. The reason for that was that I wanted to be able to easily fit it into multiple XC9572XL boards I had. The naive approach would have been to put the large data shift register in one device, and the rest of the logic in a 2nd device, but this turned out to be impossible due to lack of I/O's in the other device. I ended up parametrically splitting the data array between the two devices so I can easily balance a few macorcells here or there in each device, if the need arises. I also made sure the design fits in an XC2C128 device I had.
The design itself is fully parameterized, and changing the X,Y parameter at the top level will infer the correct logic for any size chosen. Two extra redundant parameters, LOG2X and LOG2Y were added because Icarus Verilog does not support constant functions yet (which would have enabled us to calculate the LOG2 value within each block).
A test bench was prepared that generated a test pattern, and watched the LED output signals to reconstruct the display on each generation. The output was then displayed.

A third device was added for side tasks such as debouncing the input switches, dividing the original clock, and leaving room for a future capacitive touch input.

The following diagram helps understanding the core logic that calculates the game:

All the project files are attached in the zip file.
The only thing missing is a true schematics, but I ran out of time. The schematics can be easily inferred from the 3 CPLD UCF I/O pin lists (all pins with identical names should be connected together).
clk_in driven by a 23MHz oscillator
row<n> drives a ULN2803A, which sinks the low side of a 8x8 LED array
col<n> drives a 74LS245 , which drives the high side of a 8x8 LED array through 1.1K resistors.
key_XXX are hooked up to a mini 40way digital thumb joystick.
One I/O button on the CPLD breakout boards is used for reset
Another I/O button on the cap_touch CPLD is used as key_next (advance game state).
2
Pirate PIC programmer / Strange ICSP PIC programming problem
Hi,

I'm back to my PIC experiments...
I'm trying to bring up my PIC board after doing some other stuff for the last few weeks.
The board is a partially-populated "RGB color changer" and has a PIC 18F2553, a 8MHz xtal + 2x33pf caps (not sure it's the right value), two 0.1uF caps for VUSB, connectors for ICSP, USB and serial. MCLR is pulled high by a diode and a resistor, as in all DP's PIC circuits.
I hook it though a BP v3a with the PIC programming adapter. PGC,PGD, GND and MCLR are connected. V+ on the PIC programming adapter is disconnected.
When I hook up the board's VDD to 3.3V, I can successfully read the PIC using piratePICprog. When VDD is 5V, my 18F2553 is not recognized??!!

This is very consistent - the board is fed with VCC from a bench lab power supply. At 3.3V, reading is fine. at approx 4.5V, the device starts acting flaky, and is no longer recognized.

Any ideas?
3
Pirate PIC programmer / PIC programming adapter problem
Hi,

I have a PIC programming adapter for a long time (yes, this is where all those were going :-)), and now I wanted to add support for 18F2553 (I assume it is very close, but may have a different ID than the 18F2550?)

Anyhow, I started a few hardware tests (set the power supply on, and the aux pin on), and verified I can see +12.5V on the MCLR pin in the adapter using a voltmeter.

I also ran HVPselftest.exe but I get the following message when I try:

 Press Esc to exit, any other key to start the self-test


Code: [Select]
 Starting test!
 Opening Bus Pirate on com7 at 115200bps...
 Configuring Bus Pirate HVP Adapter...
 Going into Binary Bitbang mode.. Entering binary mode...
ok
 configuring pins as output...
 sending 01000000... ERROR: BusPirate replied with 0x40 instead of 0x01
OK
 Sending Command to power on : 11000000.... ERROR: BusPirate replied with 0xffffffc0 instead of 0x01
OK
 Voltage Probe measurement...,sending 00010100
 ADC Reading:  0 Volts
 Voltage Measurement: !!!!FAIL!!!!
 powering off.....
 ERROR: BusPirate replied with 0xffffff80 instead of 0x01
 Press any key to continue...

Anyone has any idea why is the self test failing?
Is this test supposed to test anything above what I already tested with my DVM?
If the HW is indeed OK, should I bother trying to fix this problem?

I'm running on Windows 7/64 bit, and I'm able to communicate with my BPv3a over COM7 at 115200 baud.
Here is the version info of my BP:

Code: [Select]
1-WIRE>i
Bus Pirate v3a
Firmware v5.10 (r559)  Bootloader v4.3
DEVID:0x0447 REVID:0x3003 (24FJ64GA002 A3)
http://dangerousprototypes.com
CFG1:0xF9DF CFG2:0x3F7F
*----------*
Pinstates:
1.(BR)  2.(RD)  3.(OR)  4.(YW)  5.(GN)  6.(BL)  7.(PU)  8.(GR)  9.(WT)  0.(Blk)
GND    3.3V    5.0V    ADC    VPU    AUX    -      OWD    -      -
P      P      P      I      I      O      I      I      I      I
GND    3.31V  4.77V  4.28V  2.67V  H      H      H      L      H
Power supplies ON, Pull-up resistors ON, Open drain outputs (H=Hi-Z, L=GND)
MSB set: MOST sig bit first, Number of bits read/write: 8
a/A/@ controls AUX pin

*----------*
1-WIRE>

thanks,
Udi
4
Open 7400 Competition / [Entry]TTL based range finder
[Update: added a picture, and updated schematics due to missing VCC connection on the 7-Seg].

This is my 7400 contest entry. It is an ultrasonic range finder implemented using TTL components and an ultrasonic sensor.

Due to the little time I had to work on this, everything is implemented on 3 messy breadboards.

How the circuit works:

IC1A (74LS123, a dual retriggerable one-shot) is used to generate a ~80ms time base to set the time between measurements. The exact value is not too important, but it should be above 60ms to allow some window of time where we are sure no measurement is taking place (max measurement time is ~25ms).
The output from IC1A is driving IC2 (74LS121, one shot with clear and complementary output) which is generating a 10us pulse every 80ms. This 10us pulse is driving the ultrasound sensor (HC-SR04), as required by its specification.
The echo pulse returning from the HC-SR04 sensor is an active high pulse whose width is proportional to the distance measured.
The echo pulse is used for 2 purposes:

1. Gating another clock generator (IC1B, 74LS123) - when there is no pulse, there is no clock. This clock is counting the duration of the echo pulse, and is calibrated in such a way that each clock pulse represents 1cm of the distance measured.
In order to be reasonably accurate, the circuit uses one fixed resistor to get the RC network in range, and a small trimmer in series, so we could calibrate the distance measurement.

2.Blanking the display while the echo pulse is active, so that only stable data is displayed. Since the blanking signal needs to be low, the echo pulse is inverted using a 74LS14 (IC10A).

ICs 6,7,8 are BCD counters counting from 0 to 999. They are cleared by the trig pulse to the sensor, and incremented by the pulse from IC1B. The 3 counters are cascaded using a 74LS08 "AND" gates (IC9), so that the next counter increments only when all previous counters are at the value of "9". We can check only QA & QD == 1 (and ignore checking for zeros at QB,QC) since 1001 is the lowest value among all 1xx1 combinations, and is reached first by the counters.

The BCD counters are driving three 7447 BCD-to-7Seg chips (IC3,4,5). Which in turn, drive 3 common-anode displays (TIL312).


Some notes:
  • The construction seems a bit messy because I didn't have much time to work on this.
  • The schematics were done as an afterthought, and the circuit was working before I began drawing, so while I think its 100% accurate, I might have missed a small detail in the schematics.
  • All the TTLs used here are all from my personal stock, which is 30+ to 35 years old. The only new components are the sensor and 2 of the breadboards, which were bought independently for a different robotic project). The available components dictated the project.
  • The use of RC components for delays was also because most of the timing here wasn't critical, and even the most demanding counter, generating the actual measurement, could easily sustain 0.2% drifts, which is attainable when using a trimmer as part of the RC network. It is also much easier using RC components for low frequencies like these (well below 1MHz)
  • The counter's most-significant-digit, used for counting meters (IC8) is in fact the pin-compatible 74LS93 (binary counter), not 74LS90 (BCD counter), since this is what I had in stock. However, since its the highest counter (counting meters), and the sensor range is limited to ~3 meters, it would never advance beyond 3 or 4, therefore either a BCD or binary counter is suitable (I only had 2 BCD counters in my stock).
  • Being an ASIC designer on my day job, I would have done this much cleaner using a CPLD which is allowed by the contest rules (which I would have known had I bothered reading the contest forum before today :-( )

You will find here attached a link to a video showing the board, and a PDF schematics.

YouTube video:
http://www.youtube.com/watch?v=umTaJH-2pLM
6
Bus Pirate Development / More I/O pins?
Before I start looking at the JTAG automatic pinout detection code, I realized that in order for this to be useful, I need as many generic I/Os as I can get.
I believe the code tries different combinations of pinout assignments for TDI,TDO,TCK,TMS therefore each pin needs to be dynamically modified to be either an input or output.
The usual scenario probably has much more than 4 unidentified pins, therefore the more pins available, the easier it is to detect JTAG (as long as you don't blow up the board by connecting it carelessly to some high voltage source).

Can all the usual I/O pins be programmed either a input or output? (MISO, MOSI, CLK, CS, AUX) Any HW limitation that constraints any of these to input only or output only?
It also seems that maybe if I turn off VREGEN I might be able to reuse SWV33 (probably not due to the LEDs) and SWV50 .
What is the behavior of the MIC5205 when it is not enabled? is the output in high impedance?
What about PGC, PGD? can I reuse those for generic I/O?

Where can I find TP0,1,2 that I see on the v3 board schematics? Ideally I would rather use only existing pins on the BP, but soldering additional wires to test points is possible.
From what I can judge they are not connected to any pads other than the IC1 pads themselves (pins 6,7,9).