Summary: I am trying to use both I2C buses on the Atmel 328PB chip, but have not found a Atmel library that supports both busses. I see several routes forward, but wanted to get feedback from more knowledgeable people first.
Findings to date:
1) The Atmel 328PB has two I2C lines, with separate registers for at least some of the underlying functionality. Several of the other Atmel chips have multiple I2C lines.
2) I've found two applications notes with sample code to implement a master or slave I2C routine. The register values in these notes and the accompanying sample code only covers the case of a single I2C bus
3) There's a hint of successful implementations of dual I2C lines on the arduino platform and forum posts, but from looking at the referenced libraries I can't see how this is being accomplished.
4) I'm not seeing library support for this in the Atmel Studio.
Possible next actions:
0) ask here
1) I can map the new registers to the existing sample code for the interrupt service routine. I can see that this should get me to an equivalent ISR that can take care of both lines.
Before I undertake this, I have a sneaking suspicion that I am making this much harder than it needs to be - what have I missed here in search terms or terminology? Failing that, is the correct response to write my own ISR to get what I need out of the chip?
Let me know if additional details are necessary to answer.
Many thanks,
Mike T.
Related
i want to run a MCU and be able to change values in the code while its running just to give an example i have a position sensor with a homing pulse the mcu is programed to only send a trigger pulse out 10 pulses before the homing pulse but i want to be able to adjust that (on the fly) so to speak so as the machine is running adjust it till its perfect so almost like an offset i thought of using a dual bank memory MCU and i just also want to find out if anybody has any experience with dual bank memory MCUs and are there maybe any MCUs that support such a function as live code adjustment or if there is just a simpler way im not seeing here
i am very new here and i dont have a lot of experience with this sort of stuff
any help would be really great thanks
These are quite a lot questions in one and not all is fully clear to me.
Regarding the MCU:
I'm using ESP32 primarily, which is cheap and supports bluetooth and wifi.
Regarding the question of "on-the-fly" adjustment, I see at least three different options with increasing complexity and knowledge required:
Use an I/O port that can implement an A/D converter. With a potentiometer you can than fine tune the clocking.
Implementing a web server with wifi on the MCU: this way you can use your phone's web-browser to send configuration information.
Use OTA (Over The Air) to flash the controller with new data and possibly new instruction set.
You can find many good tutorials using the ESP32 or Arduino-family on youtube.
I am currently learning about microcontrollers and processors, and I have a couple questions about some distinctions between the two. As I understand, the MCU contains a processor that implements a processor architecture. For example, I am using a SAML22 Microcontroller that has a ARM Cortex M0 for its processor. So it would have the following:
Architecture - ARM
Processor - ARM Cortex M0
MCU - SAML22
Are the registers that I gather from the SAML22 data sheet related to the ARM Cortex M0? If so, how?
No, the microcontroller datasheet describes peripherals which are not part of the ARM core.
The SAML22 has a Cortex-M0+ core, which is described in ARM documents "Technical Reference Manual" (TRM, DDI0484) and the less detailed "Device Generic User Guide" (DGUG, DUI0662).
You are trying to overcomplicate this. an mcu has a processor. A processor has a processor. there have been processors that you can find on both an MCU and an SOC that is linux capable (not just rtos or uclinux). Its like having a few horsepower motor on your lawnmower and also having the same or similar on your golf cart. Or like having a school made of bricks or a house made of the same style/brand of bricks. Dont get hung up on that. Particularly with the rest of your question which has nothing to do with the processor used in the chip at all.
Atmel wants to make an MCU, so the either create, reuse or buy a processor, they have at least one if not more processors that are their IP but they choose to buy someone elses IP. Now they want to wrap some logic around it they can use some of their own ip or buy some. Each major block is a new discussion. Do they make their own uart from scratch, do they take a uart they created years ago and re-use that, or do they buy a uart. Do they make an ADC from scratch, do they take an ADC they made years ago and use that, do they purchase an ADC design from someone and use that. Repeat for every major or minor block in the design. Just like Honda making a car, which parts are they going to make themselves and which parts are they going to buy, and does that have any relevance to a design they made years ago, or a truck sized vehicle vs a compact car, they both have four wheels, an engine and some seats, in some cases may share some components and others completely incompatible components. but its the same story, do we make a seat, use one we already have, buy one. do we make a rear view mirror, use one we already have from a prior design, or buy them from someone else. the rear view mirror decision likely has nothing to do with the seat decision.
Registers its just a term a thing you write/store some information in. A uart has registers to make it work. A processor usually has registers to make it work. An ADC usually has registers to make it work. Consider each of these blocks as separable.
A processor core is a logic blob that is programmable in the sense that it has a set of rules and its primary interface is a memory bus where it is the master, it expects to find when fetched instructions per its design that tell it what to do, up to the chip vendor to wire that up to something that will feed it instructions. It may have some interrupt lines and a few other things but its primary interface is that memory bus. The "registers" inside are part of the design accessed by the processor internals and not generally memory mapped.
A uart is a logic blob that that is programmable, it has some sort of a memory/interface bus where it is typically a slave. It also has some other signals that go off chip, RX, TX, RTS, CTS, DTR...The registers inside the uart are addressable through the interface bus and are used to make the uart operate. It is up to the chip vendor to connect this bus in a way that it fits into the address space of a bus master that directly or indirectly can write/read the registers in the uart to make it operate. It is programmable in the sense that programming the registers per its spec makes it operate.
An ADC is a logic blob that is sometimes found to be programmable, sometimes not. The converter itself isnt usually. But when used in a chip that does more than just ADConversions there will be an additional logic blob wrapped around the ADC to make it programmable and that logic blob will have some sort of an interface bus where it is a slave. It is up to the chip vendor to connect this bus to a bus master that in some way is capable of programming the ADC to do something.
This isnt limited to ARM based microcontrollers. You look inside an intel x86 processor there is third party IP in there not invented nor created by intel, a lot of it may be but not all. Same goes for pretty much everyone else.
Processor based chips are just cars with seats and an engine and wheels that were per that design sourced from somewhere and then interfaced to each other using more IP from someone be it in house or not.
For any of these chips each IP blob has documentation uart documentation, adc documentation, processor core documentation. Sometimes the license agreement prevents the chip vendor from publishing the documentation and you have to get a driver from them in some sort of board support package or SDK in some form, countless examples of this with chip vendors you have heard of from atmel to intel to zilog. Likewise there are license agreements or common practices that guide what parts the chip vendor is going to document and how and what parts not. So generally but not always when you have specifically an ARM or MIPS core as part of a design. The processor documentation as you should generally do always, is from the processor vendor so ARM, MIPS, etc. The uart, the ADC, and some others be they in house or purchased IP are generally in the chip vendors documentation. The chip vendor ideally created the address space within the rules of the various ip, so the chip vendor often documents where in the processors address space each logic blob lives, then you go to the documentation for that logic blob to see what the individual control interfaces do, registers or memory mapped memory. Not always true though esp with uarts, you sometimes find this is a 16550 compatible and you have to go find a 16550 document from someone else and connect the dots on your own. The raspberry pi includes for example other peripherals where they basically say this is just an arm purchased blob go to arm for this, or there is a blob here and we wont show you how it works (but we publish the linux driver for it and if eager you can reverse engineer from that).
With an Atmel now Microchip ARM based product you (generally) go to arm to get info on the processor core, its general purpose registers as well as the very few internal to the core peripherals like the systick timer if present. The uart, the gpio, the address space, spi, i2c, etc are going to be in one or more Atmel documents for that part, they cover the register specs for those peripherals.
As far as how many documents it takes from the chip vendor that is very much chip vendor and over time family or product line specific. Some chip vendors as with some customers like the board design specific stuff in one document usually called a datasheet. Pinouts, electrical stuff, etc. And the other documents cover the uart register specs and such. Some designs are such that they reuse the same core components. if you have a uart then here is the register spec all of our uarts are the same. so there will be a manual for all of the chips peripherals and maybe the processor or maybe the processor core itself is in a separate manual. In some cases with that design solution, the peripherals if present are always at the same address or they are not. The one I am thinking of you find the board design stuff in the datasheet along with the address map, but the rest of the information for programmers is in the family reference manual, so you need at least those two documents.
And there are of course vendors that either make bad documents with holes as sad habit, or some that intentionally do not provide documentation without an NDA, for fear that a competitor will make a clone perhaps, or just a habit for that company that goes way back. Sometimes those closed book companies do very well sometimes that causes them pain. Broadcom and allwinner seem to do okay, allwinner docs tend to get left about by chip vendors and I guess they dont get punished, but other companies you will get called out for that possibly with a financial or other punishment. Its all in the legal agreement.
There are a few perpherals where there is only one or two designs and everyone just buys it, and despite being undocumented looking at linux/unix drivers can see that everyone uses the same IP.
Way more than you asked for but could tell from your question you were off on the wrong path.
Generally the ARM stuff is not in the chip vendor stuff, so no you wouldnt find it there. Sometimes (rare) the chip vendor will re-publish an arm document in whole or in part. Better to get it from arm directly. In the case of a cortex-m the arm peripherals on core are at fixed/well known addresses. For the cortex-a, and older arm11, arm10, arm9...The chip vendor straps a peripheral base address in the address space they have designed for that product and the internal arm peripherals if any are based off of that. so you can find two products likely from different vendors with the same core but the memory mapped peripherals inside are at different addresses for this reason. (in the technical reference manuals for the various arm cores).
I am currently working on a system (home projects - finally got the time yay!) and i am wondering whether it would be possible to program an arduino from a pic32? the system currently has both and given the pic32 proc has an SD card attached, i figured i could use the platform potentially to program all the other systems if there was new firmware deployed onto the SD card..
just wondered if it was possible? there doesnt seem to be anything online but maybe im googling the wrong thing? i suppose the pic32 would be acting as an ISP?
Thanks in advance..
Chris
sure, why not, it is just spi. I think just out of convenience (of something with spi on it or trivial to bit bang) I use another microcontroller to program my avr (an msp430 or mbed which program easily over usb). avrs docs are pretty good on the protocol. you can use the serial bootloader as well, but that gets into a larger number of combinations of which arduino, what speed the uart is, exactly how and you have to tickle the dtr (reset), seemed like when I was still messing with that each arduino board type was different. Where with the isp interface excluding xmega, there are chip to chip differences as far as the identification number, etc but easier come up with something more generic. And the nice thing about that spi interface is the processor is in reset so you are not relying on there being a bootloader, what version of the bootloader, or a chip with a flash that is for some reason causing a hang, etc. you should generally get the same programming experience independent as to what was programmed before.
I have a project which the information from the microcontroller (drop rate changes of dextrose like sending notification "nearly empty" or "Sudden change of drop rate. Drop rate of 15 automatically return to 14") would display in an application in a computer. I am thinking of using ZigBee and it would be responsible for transferring the information but I am new with the technology.
Does anyone could help me how to program the ZigBee module? I have seen some articles saying that it could be programmed in eclipse CDT. I am bit confused how to get start.
Any help would be appreciated. Thanks!
Use USB Explorer device (or similar) to enter a serial terminal session on the receiving XBee.
Type ATMY to get the receiving XBee's address. Write it down.
Put the sender in the USB Explorer and type ATDL plus the receiver's address, like "ATDL798A728"
Type ATWR to save this setting.
Attach sender XBee's UART (TX and RX pins) to microcontroller.
Plug receiving XBee into USB Explorer attached to computer.
Run Processing sketch or similar to read from the serial port.
The two XBees will run by default in 'transparent mode,' which pipes data coming into one UART out of the other UART, exactly like a wire. So when your microcontroller writes data into the sender XBee, it will come out of the receiving XBee and be read (and displayed or whatever you need) by your software.
It really depends on how much configuration your installation can handle. Is this a one off installation, or a "system" of products you want to make that have to be able to work together in whatever configuration they're bought?
As already explained, xbee modules that have the whole radio + stack already setup and working for serial data are simple to use for the trivial case of you sending out a few pre-paired setups form the lab, or even site installation by an expert.
If your embedded devices have to find each other automatically, then you'd need a way to get the embedded microcontroller to get the modules discover each other, make a connection, and then have the application code in the embedded microcontrollers talk to each other and identify what they need to do with each other.
In this case, you probably would be better off with the (upfront much more complex and likely expensive) design where the zigbee stack is inside the embedded controller, so your application code can use it properly to control connectivity.
The TI zigbee pro evaluation kit is very comprehensive, and seems great to me so far. It sounds like you're at the point where you need to spend some money and get some experience with real modules, just to get a feel for the technology. Though be warned, you may need IAR embedded workbench to work with these long term, and that's pretty expensive software!
Alternatively, Atmel have a pretty interesting looking zigbee implementation with their "bitcloud" software platform (free zigbee pro stack!! woo! and they have a free ARM toolchain!) but I've found the getting started info around the bitcloud stuff is really lacking, and while I can get the code setup and compiling, I'm not confident to buy enough of their evaluation gear for a zigbee pro mesh network to test it in real life yet.
PS: if you're getting started with short range wireless, i can't recommend this book highly enough. http://www.amazon.com/Essentials-Short-Range-Wireless-Cambridge-Series/dp/0521760690/ref=sr_1_2?ie=UTF8&qid=1336091059&sr=8-2
It contains very good introduction to the different technologies available, and the strengths and weaknesses of all of them (and wireless in general) Plus it will leave you in a good position to start understanding the features you really need for the system you're designing.
some of the zigbee/xbee modules simply behave as wireless serial, no programming required just turn them on. Others require programming. It depends on what your needs really are. the ones that behave like wireless serial have an AT command set if I remember right so you can adjust some things, like for example if you want more than two (more than one wireless point to point connection) you can specify which two talk to each other...
What is the difference between a Relay Controller and a Microcontroller?
I'm looking into Arduino boards and am just getting into electronics, so I wanted to know the difference.
I know this is not a programming question, but I am developing in PHP and would like to know what the difference is before I start to code to make sure I'm going down the right path.
Those two devices are very different. Depending on exactly what you're trying to do, you may be able to use either, however. You'll have to tell more about your goal.
If you're switching high-current or high-voltage loads on and off, you'll need some sort of relay (or perhaps a large FET). If your current and voltage requirements are sufficiently low (5V, 40ma), you may be able to drive your load directly with the Arduino's output pins.
The Arduino is a microcontroller. That means it's an entire computer, just simplified. It has RAM, registers, an ALU, etc. Microcontrollers are generally specialized such that instead of interfacing to peripherals using some kind of bus like in a desktop computer processor, they have I/O capabilities built in, often simply in the form of outputs that can be set high (the input voltage, usually 5V) or low (0V) programmatically. The Arduino probably uses its own programming langauge, although there may be more than one language available for it (I've never used one). I doubt PHP is one of those langauges.
The relay controller is exactly what the name implies -- a simple circuit that controls some relays. Relays are electrically actuated switches. There's no intelligence in the relay controller. It can't be programmed; it must be controlled externally via USB. If you're attempting to interface with it from PHP on a desktop/server computer, this is probably your best choice. You're right that it's expensive. You could probably build your own for a fraction of the cost, especially if you're willing to use the parallel port on your computer (googling for how should give simple instructions). It's worth noting that that relay controller, and presumably most others, likely contain some kind of microcontroller with the I/O pins connected to circuitry that increases the current and/or voltage to the point where it can drive the relay, which in turn switches the load.
Hmm... only very vaguely programming related :) I think we may need another StackOverflow for electronics. Maybe SparkOverflow?