2016-02-02 21:57 UTC
I'm happy to admit that while progress has been slow, the transceiver project is not forgotten. As always, many things are competing for their share of my spare time. It will be finished. Eventually. In part one I presented the basic concept, first prototype and the main analog parts for the receiver (some of which will be used for transmit as well). While I have the basic analog concept working, my transceiver will not be of much use in the shack without a pretty box and a good way of controlling it. This part of the build is about the microcontroller, LCD and buttons. The first thing I did was to locate a suitable enclosure. The loose-boards-all-over-the-desk-design was getting difficult to manage even for a prototype build. Ideally a metal enclosure would be better but I went for plastic simply because it's easier to work with and I'm counting on not getting everything right the first time anyway. One basic requirement I had with this design was that I wanted the ability to control all of the transceiver functions remotely from an external computer. That includes various analog gains and volumes. It would need some extra work but in the end I think it will be worth it. The first prototype used a 4x20 character LCD but I've now changed it to 2x40 character LCD to make better use of front panel surface area. To keep it simple I also wanted to base the logic around the Atmega 328 since it's a very common microcontroller today. It may be a bit under powered for what I want to do but with some efficient code I think I can pull it off. I'm not a huge fan of the Arduino so software will be written in C directly for the Atmega using avr-gcc that hopefully also saves me some program space. Not entirely knowing yet how I want the user interface to work I just mounted a set of eight buttons. There is still room for more if there is a need for it. All buttons are momentary. Also on the front are two stereo jacks for headphones and microphone with PTT button. The inside is divided into two stacks of half size euroboards. The left stack above contains three boards for the RF parts (top board currently empty) and the right side will be a stack of two boards for the digital and audio parts (only the digital board is in the picture). In the space between the stacks I will squeeze in a vertical board for the crystal filters (not sure how many I will be able to fit in there but hopefully at least two). On the rear panel I have mounted three BNC connectors. Not yet sure how they will be used but hopefully switchable antennas and IF in/out. Also on the back is a DB9 for RS-232 that will be connected to the Atmega 328 UART for remote control. Of course there is also a DC-jack. As mentioned in part one of the project I have chosen the Si5351 frequency generator for VFO and BFO. Controlled by I²C it's a good match for the Atmega 328. Adafruit has a nice little board for this chip that contains a pretty decent reference oscillator, I²C level converters and it's own 3.3V regulator. The Si5351 has three outputs but there are actually only two PLLs inside meaning that I can only get two totally independent frequencies out of this chip but it will be enough. My plan is also to glue a suitable I²C thermometer to the board and isolate it in it's own little enclosure. That way I can compensate for temperature related frequency variations in software. Above is my current draft schematic for the digital controller board. I tried to make decent use of the Atmega 328 I/O pins. Front panel buttons are connected to a '174 encoder that gives me a total of nine buttons on only four I/O pins. Pretty efficient with the downside that only one button can be pressed at a single time. User interface will have to be designed around this limitation but I don't think it's a big issue. The encoder knob is connected to the INT0/INT1 pins that have flexible interrupts. Decoding in software really needs to be interrupt driven not to mis a step. On the I²C bus I have the Si5351 board, a DAC/ADC (PCF8591) and an EEPROM. My plan is to use the DAC/ADC for reading incoming signal level, RF power etc and for software based AGC. Still need to work out how to do this in detail. EEPROM will be used for settings and calibration data. Another suitable multichannel volume control chip will also be connected to the I²C bus for the audio routing and levels. The four '164 shift registers provides a total of 32 outputs for controlling various functions. The PTT and CW key have their own pins so that they are not interfered by other key presses. I have written rudimentary code to test and verify all parts but it's not release-ready. From the image above you can get the basic idea of what the interface looks like right now. That's about it for now! Hopefully the next update will not be that very far away this time.
2015-12-03 12:05 UTC
I've gotten quite a few questions now about my assembler and workflow for the MC3. I've used the same old 6800/01/04/05/09/11 assembler for years. I think it's made by E J Rupp originally. It's very basic and does not handle macros and such but it's clean and I do have the source code and have made a few modifications over the years. Mainly adding a version (as1h) that supports the very useful XGDX opcode for 6301/6303. The output is Motorola S-record (S19) that is directly compatible with most monitors and PROM programmers. Below is an archive of the assembler with both source and Linux binaries. Download assembler source and binaries I have included a build script (build.sh) for compiling under GCC. Assemble and generate s19-file
$ as1h program.asmAssemble and generate listing + s19
$ as1h program.asm -L > program.lstAs for assembler editor I use Emacs all the way. It handles 68xx assembly nicely.
2015-12-03 05:48 UTC
This is a minor bug-fix release of the 1.4 monitor improving stability of the the single step function and improves stack handling and coherency in printout. This is the correct single step code. Silly me forgot to clear the interrupt mask on stack before RTI.
*************** * DO SINGLE STEP SSTEP JSR PCRLF STEP LDS SP RESTORE PROGRAM STACK POINTER TSX LDAA ,X LOAD CC ANDA #$EF CLEAR INTERUPT MASK BIT STAA ,X SAVE CC LDAB #$1F STPWAI DECB WAIT FOR EVENTUAL SCI XFER CMPB #$00 BEFORE TIMER INIT BNE STPWAI LDX #STOP SET INTERRUPT VECTOR STX TMOFVEC+1 LDX #$FFED RESET COUNTER VALUE STX COUNTHI LDX TIMECON CLEAR INTERRUPT BIT IN TIMER CTRL REG LDAA #$04 ENABLE TIMER OVERFLOW INTERRUPT STAA TIMECON RTI *************** * SINGLE STEP INTERRUPT ENTRY STOP STS SP SAVE PROGRAM STACK POINTER LDX #INTSEQ RESTORE INTERRUPT VECTOR STX TMOFVEC+1 LDX TIMECON CLEARS INTERRUPT BIT IN TIMER CTRL REG LDAA #$00 DISABLE TIMER INTERRUPT STAA TIMECON LDX SP EXTRACT PROGRAM STOP ADDRESS LDAB #6 ABX LDX ,X CPX #$C000 BHI STEP NO STOP IN ROM STX XTEMP LDAB XTEMP CMPB #$7F BEQ STEP NO STOP IN PAGE $7F LDX #STOPTX JSR PDATA JMP PRTREG PRINT REGS AND GO TO PROMPTMonitor 1.4.1 ($C000-$C7E8) - source - listing - s19
2015-06-29 13:28 UTC
I²C is a fun protocol. It's great for interfacing to real time clocks, sensors, displays etc. My personal favorite right now is the Si5351 frequency generator chip. In a world of ever increasing number of I²C compatible micro-controllers, I though that my MC3 should learn to speak I²C as well. I have chosen a chip from Philips that is a self-contained I²C interface. It's much faster than bit-banging an I/O port. The chip, PCF8584, can still be obtained from various suppliers but I don't think it's being manufactured anymore. Therefore I have taken extra care to protect it. The interface schematic can be seen below. The tricky part about buffering I²C signals is that they are bi-directional (the PCF8584 can work as both master and slave). A buffer that is both bi-directional and has open collector input/outputs needs some extra thinking. It is not possible to just put to buffers back to back and expect it to work. As soon as one of the buffers trigger the opposite buffer will also trigger and the circuit will enter a locked state. To solve this I have designed the buffer stages using two comparators (LM339) with open collector outputs. By using comparators it is possible to carefully adjust the trigger levels so that one buffer does not affect the buffer in opposite direction. A reference voltage of 0.65V is used for the comparators, but the output from the comparators facing the PCF8584 has a series resistor that together with the pull-up resistor creates a voltage divider. When the comparator tries to pull the line low the divider will limit the voltage to around 1.2V, enough for the PCF8584 to register a 'low' level but not enough to trigger the opposite comparator. This is the finished MC3 I/O board. I added an 8-pin socket (not in the schematic) for connecting EEPROMs directly on the board. As always, don't forget to add 100nF decoupling capacitors across the supply on all chips. Sample program for testing the interface This program interfaces to a DS1307 RTC chip but I have made the I²C driver routines generic so they can be used for accessing any other I²C device as well. - source - listing - s19
2015-05-04 04:15 UTC
Even though the MC3 is in its core a Motorola 68xx design it can use 65xx parts. The bus and timings are the same. I initially planed on building an I/O board around the 6321 PIA but ended up trying out the feature packed 6522 VIA instead. The 6522 is actually still being manufactured by WDC! The 6522 is familiar to anyone working with the 6502 or MOS/Commodore machines. In general it's a souped up 6821 with two timers and a shift register. The 6522 consumes more address space than the 6821 but each register can be directly addressed, thus making it faster for certain tasks. It requires four address pins instead of only two but for me that's a perfect match since my I/O boards each have 4 address lines making it a 1:1 match. Connecting the 6522 to the MC3 20-pin I/O expansion bus require no extra circuitry. It's only a matter of connecting the corresponding pins together. Since there is no IRQ line on the I/O bus I will have to settle for polling the 6522. Thank you Douglas Beattie for sharing your Eagle 65xx library. The 40-pin chip is a tight fit on the small 20-pin I/O board but it worked. For now there are no connectors for the 6522 ports. Not much space left but I should be able to mount a suitable connector at the top of the board. I really like how the 6522 engineers have separated the bus pins and the I/O pins to different sides of the chip.[show older articles]