As it turned out, the issue I had in my last post was power related. The ground path for the charge pump capacitors on the transceiver I was using was too long. I corrected this and my skew issues went away, interestingly. With this came clean data at 115.2 Kbps--the maximum I could do over traditional serial.
I took that opportunity to start playing with flash memory, but I'll talk more about that later. The real thing I want to get on the record is that I later used a USB UART transceiver instead of an RS-232 one. I've been playing with it for a while now, and it seems to have an issue where the connection will seize until power is cycled on the transceiver IC itself. Resetting via the reset pin doesn't fix it.
From what I can tell, it's a glitch in the MCP2200 UART IC when blink mode is enabled for the RX/TX LED output pins. If the pins are disabled or set to toggle instead, this doesn't happen. The real curious part that makes troubleshooting it difficult is that the problem only manifests at high bitrates. It's likely to work with blink mode enabled at 1200 bps or even 9600 bps.
Monday, April 18, 2011
Wednesday, April 6, 2011
Bit Skew, Oh How I Dislike Thee
Things have gotten pretty interesting ever since I finished up the basic instruction set of the ORG M1 CPU. I still enjoy watching the indicator lights on the memory interface that merrily twiddle away when crunching through memory instructions (LOAD and SAVE).
Now that everything is working and I've done programs as large as 13 instructions by setting bitlines in the CPU itself that emulate reading a program out of memory, it's time to load larger programs into the system's non-volatile storage. To facilitate this, I chose to add an RS-232 serial port to the system and load programs straight from my PC. That's where I'm currently getting hung up.
It seems that I'm registering bits improperly no matter what I do. I can't seem to figure this one out (yet). I've managed to get the system to clock in data correctly at about 300 baud, but there's no reason why 115.2 Kbps shouldn't work too. The UART I'm using (Sipex SP3232ECP) is capable of a quarter megabit per second when using one channel, and the card in my PC is supposedly good for 1 Mbps or better.
I've done many sorts of diagnostics counting bit transitions and such but to no avail. In that past I've used this same transceiver to send data at 115.2 Kbps just fine. I'm as yet unsure why RX is being such a bitch.
Now that everything is working and I've done programs as large as 13 instructions by setting bitlines in the CPU itself that emulate reading a program out of memory, it's time to load larger programs into the system's non-volatile storage. To facilitate this, I chose to add an RS-232 serial port to the system and load programs straight from my PC. That's where I'm currently getting hung up.
It seems that I'm registering bits improperly no matter what I do. I can't seem to figure this one out (yet). I've managed to get the system to clock in data correctly at about 300 baud, but there's no reason why 115.2 Kbps shouldn't work too. The UART I'm using (Sipex SP3232ECP) is capable of a quarter megabit per second when using one channel, and the card in my PC is supposedly good for 1 Mbps or better.
I've done many sorts of diagnostics counting bit transitions and such but to no avail. In that past I've used this same transceiver to send data at 115.2 Kbps just fine. I'm as yet unsure why RX is being such a bitch.
Sunday, April 3, 2011
ORG M1's First Program
Now that's quite an exciting turn of events. This weekend I was able to get the "ORG M1" CPU to the point where it was able to run its first two programs!
The first "program" is only really sort of a program. What was executed was entirely hardwired into the CPU itself, but it was able to perform the following automatically:
Further excitement came with today's developments: The first program executed using opcodes. The storage holding the program was again registers in the CPU itself, but this was only because the first program's function was itself to write data into memory containing an actual program. :)
After some frustrating events where the CPU repeatedly refused to do anything other than enter an exception state and angrily cause the UI to blink rapidly at me, I was finally able to get the program to execute automatically and finally complete.
There's still more work to be done as only a couple of opcodes are implemented, but once the LOAD and STORE opcodes are finished I can move the code into non-volatile F-RAM instead of relying on hard-coded bit lines in the CPU itself.
The first "program" is only really sort of a program. What was executed was entirely hardwired into the CPU itself, but it was able to perform the following automatically:
- Power on
- Wait 250 million cycles (2.5 seconds)
- Load the A register of an 8-bit adder with the value stored in page 0 of the attached F-RAM (loaded earlier by hand using switches)
- Load the B register of the same adder with the byte in page 1
- Display the Y register of aforementioned adder on the UI panel (LEDs)
- Stop
Further excitement came with today's developments: The first program executed using opcodes. The storage holding the program was again registers in the CPU itself, but this was only because the first program's function was itself to write data into memory containing an actual program. :)
After some frustrating events where the CPU repeatedly refused to do anything other than enter an exception state and angrily cause the UI to blink rapidly at me, I was finally able to get the program to execute automatically and finally complete.
There's still more work to be done as only a couple of opcodes are implemented, but once the LOAD and STORE opcodes are finished I can move the code into non-volatile F-RAM instead of relying on hard-coded bit lines in the CPU itself.
Subscribe to:
Posts (Atom)