Hi: I would like advice on where to begin. I'm interested in making a data acqusition system (simple simple simple) that can write the collected data to a flash drive. To do this I need to know:
1) How to create a USB interface that a flash drive can be plugged into and my device (yet to be created) can write data files to.
While this is a very straight forward idea, i have some microcontroller, memory, and USB pieces to learn. I'm a EE but never had more than just basic microcontroller's in school. I'm not in a big hurry and I'm talking small scale and as simple as possible.
I am trying to get an H8/3664 to talk to a SPI device - specifically, the Nokia LCD display driven from a PCD8544 chip.
I have done this quite easily with an AVR and now wish to port the code to the H8.
According to the datasheet, the IIC module seems able to provide a suitable signal - 8 bits synchronous serial with no addressing. The serial communications device (SCI3) is also capable for generating synchronous serial data.
However, in use, it seems that both devices use the same TDRE flag to indicate that their respective transmit data buffers are ready to use.
I had wanted to use the IIC device so that I could connect the standard serial port up for a continuous radio link. Now I am getting a bit confused about using these two devices. Does anyone know if it is wise to use both peripherals at once? For instance, if both serial data buffers can make the TDRE flag go high when they are emptied, will it actually only go high if they are both emptied?
I can't really use the SCI for both jobs as I don't want spurious LCD data appearing on the radio link. It would be a shame to have to forego the serial radio data link.
Finally, does anyone have any sample code for configuring the IIC to work like a SPI port? I can't seem to find any examples on the net.
A USB host (such as a PC) and a USB device (such as a flash disk) are quite different beasts. A host is generally complex as it has to be generic, a device generally simpler and specific to a single task. Small microcontrollers that include a USB peripheral will generally be device only, whereas you require a host.
Your options would be (stating the obvious somewhat):
Use a larger processor, possibly running Linux or a commercial RTOS to take advantage of the USB host drivers.
Buy a third party interface that provides a simpler interface to your microcontroller.
Find some sample code provided by your hardware or compiler manufacturer. You don't give many clues to who these might be.
Another option might be to use an SD card in place of a USB flash disk. An SD card provides a convenient serial interface that is simple to interface to a microcontroller, but is likely to be slower than USB. There is plenty of sample hardware and software available - and you can buy an SD card reader for PC's (to access the saved data files) for a few $'s.
They are two seperate modules (peripherals) in the device even have different interupts and register addresses.
The IIC (I2C) does not support SPI, you will need to bit bang it.
No they both have bits in their respective registers that are LABELLED the same as the function of the bit is the same in both modules.
Go read the manuals again as you are expecting the same Bit description to mean that it is the same single bit which is wrong.
SCI is at address 0xFFA8 to 0xFFAD IIC is at address 0xFFC4 to oxFFC7
Sepearte registers at seperate addresses, in no way linked.
There is even on Renesas site example code for IIC module doing IIC (I2C) functions, it is NOT possible to set up for SPI as SPI can in fact be any bit length you want, whereas I2C is always fixed at 8 bits. Also the bit order and clock relationships are not fixed on SPI.
Mind you the I2C module is a bit of a bitch to get going anyway on the H8/3664 in my experience.
You may find my sig useful to note for other resources.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
GNU H8 & mailing list info
For those web sites you hate
I have come to that conclusion today. Shame but, even if the IIC peripheral could have done it, it is probably easier to bit-bang SPI than find out how to set up the registers.
I have just double checked the H8/3664 hardware manual. Discussion of the IIC includes mention of setting the TDRE bit. Scanning the entire thing, the only TDRE bit is the one in the Serial Status Register. Either it is dual purpose or there is some error in the hardware manual. This is in Section 15.3.1 of rev 5.00 of the hardware manual dated
03/04. In either case, it is no wonder the IIC is a bugger to get to work.
Not that I care any more, I will just do the SPI thing manually.
Please quote the section in the manual that states that the IIC internal FLAGS associated with ICDR (IIC Data Register), which cannot be directly set/cleared by software as they are not in a register, have anything to do with the SCI. If there was two or more SCI units on the processor (as other H8s have) which SCI TDRE would it be connected to as each SCI has its own TDRE bit. The IIC has its own TDRE FLAG for its internal use.
These processors use a core and mix of peripheral blocks that are isolated from each other as seperate peripherals, so the same code for one module can be used with minimal changes on another processor across families. None of the H8/H8S/H8SX/H8-Tiny range using IIC controllers share registers or flags with one or more of their SCI ports.
The SCI module(s) are sepearate functions, some of those processors have FIVE SCI ports and sometimes TWO IIC controllers, so how would the TDRE interal flag for one or more IIC be related to an SCI unit?
The SCI and IIC modules use different pins on the chips.
They are seperate modules with the chip.
You are confusing two modules with a single multi-purpose serial unit available in some other makes of processor.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
GNU H8 & mailing list info
For those web sites you hate
This is taken directly from document number REJ09B0142-0600 - the H8/3664 Group Hardware Manual downloaded today (Dec 29th) and dated MAR.24.06 Rev.6.00, page 236
15.3.1 I2C Bus Data Register (ICDR)
ICDR is an 8-bit readable/writable register that is used as a transmit data register when transmitting and a receive data register when receiving. ICDR is divided internally into a shift register (ICDRS), receive buffer (ICDRR), and transmit buffer (ICDRT). Data transfers among the three registers are performed automatically in coordination with changes in the bus state, and affect the status of internal flags such as TDRE and RDRF.
When TDRE is 1 and the transmit buffer is empty, TDRE shows that the next transmit data can be written from the CPU. When RDRF is 1, it shows that the valid receive data is stored in the receive buffer.
If I2C is in transmit mode and the next data is in ICDRT (the TDRE flag is 0) following transmission/reception of one frame of data using ICDRS, data is transferred automatically from ICDRT to ICDRS. If I2C is in receive mode and no previous data remains in ICDRR (the RDRF flag is 0) following transmission/reception of one frame of data using ICDRS, data is transferred automatically from ICDRS to ICDRR.
If the number of bits in a frame, excluding the acknowledge bit, is less than 8, transmit data and receive data are stored differently. Transmit data should be written justified toward the MSB side when MLS = 0, and toward the LSB side when MLS = 1. Receive data bits read from the LSB side should be treated as valid when MLS = 0, and bits read from the MSB side when MLS = 1. ICDR can be written and read only when the ICE bit is set to 1 in ICCR. The value of ICDR is undefined after a reset.
The TDRE and RDRF flags are set and cleared under the conditions shown below. Setting the TDRE and RDRF flags affects the status of the interrupt flags.
TDRE [Setting conditions] ? In transmit mode, when a start condition is detected in the bus line state after a start condition is issued in master mode with the I2C bus format or serial format selected ? When transmit mode (TRS = 1) is set without a format ? When data is transferred from ICDRT to ICDRS ? When a switch is made from receive mode to transmit mode after detection of a start condition
[Clearing condition] ? When transmit data is written in ICDR in transmit mode ? When a stop condition is detected in the bus line state after a stop condition is issued with the I2C bus format or serial format selected ? When a stop condition is detected with the I2C bus
No, I don't think I am. I have had a good look at the manual. If I have misunderstood that (and it is none too clear in places) then please enlighten me.
My curiosity piqued, I looked up one of the devices with multiple SCI channels. The H8S/2239 was the first to catch my eye, with 4 SCI channels. It has a separate Serial Status Register for each channel (SSR_0, SSR_1, SSR_2 and SSR_3), each with its own TDRE. No register other than the SSR in either chip has a bit called TDRE.
Curiously, its section on IIC also refers to TDRE as if there one, and only one. The flow charts describing operation refer to testing the IRIC flag in ICCR to see if data has been transferred (although they again mention TDRE). I guess the IRIC flag is the one to use.
I have set up the bit-banging now. Perhaps later I will write some bits of test code to see what happens to the various flags. Mind you, I can't get the damned IIC set up anyway so that may be much later.
Which I read twice to see where you are making things up from.
NO mention of ICDR == TDR (for any SCI)
Description of various INTERNAL registers not directly software accessible.
Mention of flags TDRE and RDRF which could be name TX buffer empty and RX buffer full.
Lets also refer to these FLAGS as
IIC.TDRE IIC.RDRF
NO mention that these are the same bits/flags in any SCI register
Standard description of ANY register being loaded/read and an associated flag for timing etc., being set to indicate action complete. Remember TX Buffer Empty & RX Buffer Full.
......
The IIC internal flags dependent on actions in registers such ICDR etc that are internal to the IIC controller.
.....
NONE of this makes ANY mention of link to the SCI controller.
You are ASSUMING there is ONLY ONE TDRE bit/flag in the WHOLE device.
I have said it several times there are DIFFERENT TDRE bits/flags for the buffers/registers/shift registers in each module.
The SCI ones are refered to as
SCIn.SSR.TDRE SCIn.SSR.RDRF
Many peripherals have "Ready" flags each refering to its OWN function and no other module.
So the IIC TDRE bit is the same as which SCIn.SSR.TDRE?
All the TDRE bits are DIFFERENT relating to each serial channel.
So how would one IIC internal "Ready" flag be the same as any other "Ready" flag. Let alone four other ones. That is akin to saying in any programme all ints are in fact the same int.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
GNU H8 & mailing list info
For those web sites you hate
It is hardly fair to describe me as 'making things up'. I have been confused. Has that never happened to you?
You are right, I had been. The repeated references to TDRE and its purpose led me to look for that flag. Phrases in the description like "TDRE shows that" indicated to me that I should be able to see and make use of that flag. I am quite happy (now) with the idea that it is a purely internal flag. I seems to me that there was no need for the use of the term in the processor manual. If it is IRIC that is to be tested then the manual really could have simply said so. Why bother to expose to the reader flags which they can not see or use and which do nothing to aid an explanation of how the peripheral works from the programmers point of view? If I can't make use of the information, why even bother to tell me how the flags get set and cleared?
Interpreting processor manuals seems to be as black an art as writing them. Clearly I need more practice.
However, I see now the error of my ways. In the event that I should ever want to use the IIC peripheral on an H8 I shall take greater care. I have my bit-banging SPI working just fine and the need has passed me by.
Well, that was rather my point. While I believed that the manual was referring to a single TDRE flag, this just confused me even more. Now that I see the reference as a red herring, everything is much more clear.
Especially ones that were written in a different language and then translated into English by non-native speakers. I must say that the Hitachi manuals are brilliant compared to some others (Samsumg's are particularly bad). I presume that manuals written in English and translated to other languages by non-native speakers are just as bad.
Sometimes trial-and-error with the actual hardware is the only way to figure out what a paragraph is supposed to mean.
--
Grant Edwards grante Yow! I want EARS! I
at want two ROUND BLACK
visi.com EARS to make me feel warm
'n secure!!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.