Recent content by kenmac

Hippy, Although it does seem possible, there remains too many unknowns, so I'll stick with using the SCN2651 chip feeding a Picaxe. Thanks for your info - it has been informative! Kenmac

Hippy, Is it possible to access the UART in the 28X2 as Buzby suggests? Kenmac

Hippy, Bisync is an old IBM protocol for series synchronous comms. Basically there are two lines , data and clock. The clock is generated by the sender and the receiver reads the data at mid-data bit, triggerred by the clock leading edge, similar to the SPI 00 mode. The reason that I am...

I am currently trying a 28X2 running at 16mHz. From what Hippy says, there will probably be a conflict of Clocks, so that idea fails. So, it is back to "bit banging" I suppose. The bits are 50uS so the programming needs to be pretty fast to stay in sync. I was intending using the Scratchpad for...

Hi folks, I have been working on code to read Bisync messages by "bit banging". However, I notice the command hspiin seems to read the data the same way as Bisync. It can read the data bits at the leading edge of the clock pulses - that is mid data bits (mode 00). So, is it possible to use this...

Hippy, The programming went well - all the data ended up in the FRAM. I passed your Python program on to one of our group who dabbles in that language. He has taken it away for further study - not my area I'm afraid, I tend to stick with Basic and Spin. Thanks again for your response. Ken Mac

Hippy, Thanks, you are correct of course. I went back to the Manual again and found that it requires i2cword! I shall correct that tomorrow and hopefully we can proceed. kenmac

Allycat, It's OK - I only showed the code for the Eeprom. I used the correct address for the RTC. With a new chip, the registers will always hold $FF. The fact that doesn't change when the program runs means the write has failed! kenmac

Aries, I'm using a 24LC256 Eeprom. It will have all memory bytes as $FF when new (never programmed). It should work OK with bytes. kenmac

Hi folks, I am about to load some data into a FRAM chip. so I decided to re-familiarise myself with i2c stuff. So, I made a small program to load a character into an Eeprom at location 00 and then read it back. It is a new Eeprom, so I expected the contents to all be $FF to start with. I ran the...

Hippy, I know nothing about Python, but I can see what you have done here. I'm checking the data against the original, and if OK will proceed with testing the programs. Thanks for your effort on this. Kenmac

Hippy, I have now managed to recover the raw data file we need to be stored in FRAM. The file was generated many years ago by a DOS program. It is attached in .zip format. Your move! Kenmac

Hippy, We have to delay sending the file to you because the USB stick is currently in the possession of one of our group from the museum. As soon as we recover it, we'll send a copy to you. It may be a few days I think. Will a 14M2 or 18M2 do the job?(memory) kenmac

Hippy, Thanks for the offer. The file is 1.644 kB The transfer rate of the serial connection is normally 4800bd. FRAM writes can occur at clock speed (no delay). Can we do a direct "read in to store FRAM" without crashing due to program overheads? In other words, will the "read in" be too fast...

Hippy. Sorry, I misunderstood. The data is in the form of raw binary/bytes, comprising info to display a map on a radar screen. It consists of screen vector info etc. The data message file was constructed using an old DOS program and we have used some very old DOS PC's to capture it. We look...