another newbie question.
I have a piece of code that I am porting from PICC. In PICC, you can make reference to specific pins ("#define sclk GPIO5" for example), and in your code, you can write to sclk to change the pin output on GPOI5. This makes porting code or changing pin layout so much easier as you can simple redefine sclk to a different pin to make the code work.
ARM seems to prefer to change its pin output through IOSET / IOCLR.
To make the existing PICC code work, I would prefer to be able to define certain pins logically, and change their states by referencing their logic names.
how do you do that in ARM? Thanks in advance.
Earlier in this thread you were referring to Cortex-M3 bit-banding. Not being familiar with PIC, I assume this would be the closest mechanism (in ARM world) to what you are looking for.
However, bit-banding is not quite the right thing if you have to change several bits simultaneously. And by that I mean exactly at the same time. Don't know how PIC addresses that.
To implement your example on a Cortex-M3 controller, you'd have to determine the bit address of a port in some data output register (you'll find examples all over the place). By defining a variable at that address, you can easily implement your sclk thing.
infocenter.arm.com/.../Behcjiic.html
Best regards Marcus http://www.doulos.com/arm/
Marcus, thank you so much.
so GPIO A in LM3S628, per the datasheet, is at 0x4000.4000 - 0x4000.4FFF (24 bits for an 8-bit port? for compatibility reasons?). so its 0th pin / bit (0x4000.4000) should be a word at 0x4200.0000+0x4000 << 7 + 0x00<<2?
if I want to set the 0th pin to 1, do I just set that word to anything other than 0?
yeah, this is hugely helpful. I hope the mapping is consistent at least within the Cortex-M3 family?
thanks a lot.
"Don't know how PIC addresses that."
in PIC, you can assign a value to the port to change the bits at the same time.
so GPIO=0b10101010 will set some bits and clear others at the same time.
GPIO1=1 will just set the 1st bit, and GPIO0=0 will clear the 0th bit, sequentially of course.
"I think that's the case. the reasons given earlier about latency, gpio off bus, or the business model, etc. are really not fundamental."
They are very fundamental - when a manufacturer buys a core and adds peripherial functions around the core, they are limited by what the core allows. load/modify/store is affected by latencies, so such updates must be close to the core, which is the reason why the chip manufacturers has looked for alternatives that removes the need for the "load" part.
The other alternative would have been to have the GPIO latches inside the core to allow single-clock access. Or replacing some registers with GPIO latches, allowing the modify instructions to directly modify the port pins.
From the fact that C does not have bit variables, it should be quite obvious that bit addressable memory is not a generic feature available in all processors. It is also a feature not available in "normal" memory, but something that requires a special memory interface - either that the bit addressable memory is part of the core (8051 or PIC) or that the bit addressable memory is connected to a memory controller with built-in support for either addressing single bits, or for loading a word and set/clear a bit and writing back the word.
I have written multiple times that the ARM is a load/store architecture and that modifying a single bit in a larger word requires the core to wait for the load operation. That means a problem with latencies, which you decided to follow up by wondering why the chip manufacturers haven't changed the core.
I did also write the following: The ARM core doesn't have bit-manipulating instructions, so unless a specific manufacturer has spent one byte for each bit, you can't update a single bit in a port without either: - use a chip that have a mask register to write-protect some bits. - do a read/modify/write cycle, and let the processor stall for whatever number of cycles it takes to fetch the read data.
The bit-banding in the Cortex-M3 chip is the only way you can get the ARM instruction set to access individual bits without requiring the core to also have to read the neighbour bits, i.e. having the core suffering from read latencies.
Because of the large address space of the ARM, and instructions that are comfortable addressing the full address space, it is possible to waste a part of the address space for this method, allowing support without any C extensions. The only problem for the compiler is that it will not know about aliasing between the multiple addresses that maps to the same port, but it is enough to declare the addresses as volatile to make sure that the compiler doesn't try to cache the latch data.
"The bit-banding in the Cortex-M3 chip is the only way you can get the ARM instruction set to access individual bits without requiring the core to also have to read the neighbour bits, i.e. having the core suffering from read latencies."
correct, except that the Cortex chip is an ARM core doesn't run the ARM instruction set.
> if I want to set the 0th pin to 1, do I just set that > word to anything other than 0?
The LSB determines the value. But do keep in mind that this will actually result in a R-M-W access on the bus. If that is an issue in your application you should get used to using set/clear registers that are quasi-standard on ARM MCU. If you are considering a switch from PIC to ARM, that might be a good idea anyway.
It is not that hard to search/replace 'sclk = 0' with a suitable macro definition.
> I hope the mapping is consistent at least within the > Cortex-M3 family?
The concept is consistent, but register addresses are not.
Regards Marcus http://www.doulos.com/arm/
The Thumb2 instruction set is not a new instruction set. It is basically a subset of the full ARM instruction set, which is also why some cores can directly jump between ARM and Thumb mode. Being a subset just allows the Thumb instructions to have a 16-bit base size instead of 32-bit.
Switching to the Thumb2 instruction set will not modify the behaviour of the core. The core is still a load/store design, where you operate on registers, and not on memory.
This means that any limitations you see with the ARM instructions should most probably be seen with the Thumb2 instructions too.
I think that, I don't really understand this thread. But I had tried to.
I found something:
infocenter.arm.com/.../index.jsp
Cortex-M3 Technical Reference Manual
12.10. Bit-band accesses
The System bus interface contains logic that controls bit-band accesses as follows:
* It remaps bit-band alias addresses to the bit-band region.
* For reads, it extracts the requested bit from the read byte, and returns this in the Least Significant Bit (LSB) of the read data returned to the core.
* For writes, it converts the write to an 'atomic' read-modify-write operation.
My take on it is that for the Cortex-M3, it will be similar to a normal write for the processor - the write operation gets into the store cache so the processor can continue with the next operation unless the processor gets stalled because of too many outstanding writes.
In this general case, where you have a huge memory block with bit-band access, the mapping between bits and words must be part of the memory controller logic.
For a classic ARM chip, a manufacturer will have the ability to do simething similar - either for a large memory region or for specific registers. In the case someone decides to do it for a large region, they will have to implement it in the memory controller logic. For specific registers (such as a GPIO latch) it would be possible to add the set/clear logic directly into the port logic and remove the need for a load/modify/store.
The advantages with Coretex-M3, is that it reduces the gap between the high-end and low-end implementations.
"It looks like you CAN indeed directly reference GPIO ports / bits in a way similar to that used by PIC for some ARM chips and possibly all of them.
For example, LED=~LED where LED is defined as GPIO_PORTA_DATA_R for LM3S628 will flip all bits on PORTA. ARM chips from ADI and ST do allow GPIO direct referrencing - the header files have clear reference to GPIO data bits, control bits, etc."
Did you read my post from 17-Jun-2009 00:14 GMT?
In that post, I already mentioned that a number of ARM processors has a GPIO register that is readable and writeable and where each bit in the register represents one GPIO pin. This allows |=, &= etc to be used on a 8, 16 or 32 bit wide register just as if it was a memory cell.
You will have to load that memory cell into a register, then use any of a large number of possible instructions to update the register, and finally write back the result.
In one post, I also noted that the ARM core does not have instructions to set or clear a bit in a memory cell. Memory writes can only be done on native data types, and the smallest dative data type is a byte, not a bit. But I noted that creating a virtual memory array with one byte/GPIO bit, it is possible to design a chip where it is possible to define a pointer that will update just a single bit. The bit-banding in the Cortex-M3 chips is such a technique.
"now, it does seem that certain manufacturers prefer certain ways to "access" their chips: NXP wants to go through the IO control registers and ADI/ST/Luminary and possibly others want to go through the ports directly, and provide header files to help in the implementation of such approaches, respectively."
Manufacturers mostly tend to prefer access methods that works well with the available instruction set and architecture of the processor core. The instruction set and architecture of the ARM core is different than the PIC core, in which case the manufacturers have looked at other solutions to control GPIO than Microchip has. And I have already mentioned that NXP has chips that allows you to access the port pins directly as if accessing a memory cell.
"Did you read my post from 17-Jun-2009 00:14 GMT?"
so are you going to disagree with your earlier arguments that direct GPIO referencing isn't a) possible / efficient in ARM because the GPIOs hang off a bus; b) possible because ARM's business model doesn't allow that; c) possible because ARM's instruction sets cannot be altered.
or some combination of the above?
no answer required, :).
I did more digging.
looks like TI uses the NXP approach of set and clear to change ports, and Toshiba the PIC approach (through a struct).
the fact that vendors seem to be split on this issue suggests to me that the advantages of setting / clearing are about the same as their disadvantages. or we would have seen a more one-sided outcome.
I know. No answer required, because wheatever I write, you will not be interested in understanding. Probably incapable too.
1) Access to a 8-bit, 16-bit or 32-bit wide PIN register is possible, and was one of the first things I did mention in this thread. Most ARM chips avoids it or suffers significantly because of the big latency involved by the read-modify-write cycles. Especially since older ARM chips had the GPIO one or more bus bridges away. The set and clear registers allows use of the ARM store cache, allowing the core to continue at full speed, as long as the write cache don't gets filled. Hence, quite a number of ARM implementations (different manufactuers have to solve the same problems) have set/clear registers. But I have already mentioned that some ARM chips - including NXP - can have more than just the set/clear registers. And with a direct PIN register together with a mask register, it is possible to avoid the read+modify step and just go for the write step. Already mentioned, but one of the many things you have decided to ignore.
2) The PIC don't just allow byte-wide access to pins, but also allows single-bit access. Possible because the GPIO is memory-mapped into the SFR region inside the core and the PIC has instructions to perform bit operations on that memory - similar to the 8051. So until the Coretex-M3, the ARM chips did not have a way of match the PIC way of direct accessing individual pins. But I did mention that a chip manufacturer could decide themselves if they wanted to use 32 separate memory addresses to allow single-bit writes even if the ARM instruction set and bus can't do bit writes. Just one of the things you decided to ignore.
3) It was you who wondered why the chip manufacturers didn't just modify the core then, in which case I explained that ARM has the license for the instruction set. And ARM sells complete macro cells with the core. So a manufactuer will just have to implement their I/O similar to how you implement peripherial functions around a PC processor. You may integrate in the chipset. Or you may place the peripherial function on a PCI board. Same thing with the ARM. You may connect the GPIO in parallel with AHB bridges. Or after AHB bridges. Or after APB bridges already located after AHB bridges. There is no option but to have the GPIO outside the core. It is then up to design choices and used processes to decide how many steps away from the core the GPIO will be located. With some ARM chips, we may talk about 15 or more wait cycles/access. With some, we may be down to 1 or 2 wait cycles. With full register writes the core can directly overlap the next instruction. But all pins will be affected, unless the processor has a mask register to write-protect some pins. The ARM just happens to be a different architecture than the PIC. Win some. Lose some.
4) You have now multiple times compared chips and specifically mentioned NXP as _not_ allowing pin access, even if I have multiple times mentioned that NXP do have chips supporting it. Yet one more example of your problem reading and picking up facts. Or deciding beforehand what the facts are.
"possible because ARM's business model doesn't allow that" Don't you mean _impossible_? Or is this one of the examples where you are trying to claim I have said something I haven't - possibly something you did say?
"possible because ARM's instruction sets cannot be altered." Same as above.
Per,
Have you considered writing a book? Your posts are often priceless!