c-conversion

I'm back on this today. I have to say that using the MC14562 as the capture and storage device is working on first test. I have wired the original data in to the data in on the 14562. The original clock is wired to the clock in of the 14562 through a diode mixer. The original ChipSelect is connected to a 12F1840. The 12F1840 waits for the ChipSelect input to go high, indicating end of transmission from the host. At that point, following a delay, the 12F1840 lowers a pin which is wired to the display...

I looked at it, but could make no sense of how I could achieve it in any way. If I had the time, I'd try to digest the datasheet, but as I'm counting down the days to retiring, I'm not particularly well motivated to give myself a headache and figure it out. The whole "project" was something I initially thought I could wrap up well before I left, but with only 40+ days before I finish, and quite a lot of general work filling my days I wouldn't have the capacity to sit down and concentrate as I would...

I looked at it, but could make no sense of how I could acheive it in any way. If I had the time, I'd try to digest the datasheet, but as I'm counting down the days to retiring, I'm not particularly well motivated to give myself a headache and figure it out. The whole "project" was something I initially thought I could wrap up well before I left, but with only 40+ days before I finish, and quite a lot of general work filling my days I wouldn't have the capacity to sit down and concentrate as I would...

Oh dear! (For a second time). If it does not work, we have only bought a couple of the MC14526 so it won't be any great loss. As I say, I was trying to improve things but if I can't, I can't and we'll just have to manage as we (or "they" once I've left) are.

Oh dear! Sorry. I had expected the program to wait in the main Do...Loop routine for CSelect to go high, enter the CaptureClock routine where it waited for CSelect to go low which enabled the interrupts, the interrupt was hoped to count the clock pulses while the CaptureClock routine waited for CSelect to go high which then disabled interrupts and displayed the results. I did write a version with no interrupts, just a tight loop but that had no more success so I hoped the interrupt version would...

That's what I thought. Not knowing how many data bits there were, I thought I'd count the clock cycles first. But couldn't get anywhere close to the right answer. Here's what I tried to count and then display the clocks: 'Configuration #Chip 18F15Q40, 64 #Option Explicit #Include <SoftSerial.h> #Define SER1_BAUD 38400 '#Define SER1_BAUD 9600 ' baudrate must be defined '#Define SER1_DATABITS 7 ' databits optional (default = 8) '#Define SER1_STOPBITS 2 ' stopbits optional (default = 1) '#Define SER1_INVERT...

It is quite possible that the CLC could be configured using the CLC interrupt but looking at the datasheet has left me totally baffled by how I could do that and how I could use it to my advantage! I have some MC14526 on order. I think I can make that work by allowing it to capture the 128 bits from the host. I can monitor the host Chip Select line and following that returning to its rest state I can clock the 128 bits back out of the MC14526 more leisurely while filling the 14526 with 'zeros' ready...

We have a machine that is imported from China that uses a number of LED seven segment displays each element having a shift register to 'decode' the display elements. The final display in the chain often flickers and flashes. Looking at the timings from the host I'm surprised things work at all, the clock, data and chip select times all vary by some quite large percentages. I thought I could 'capture' the clock and data streams in a PIC and then re-transmit them slightly slower but with more stable...