I’ve been looking into Texas Instrument CC2541 for a long time but the problem with it is that TI does not offer any free IDE, and while they support IAR mainly, I believe, that is a professional IDE with professional price tag.
So what’s the best alternative? Well, I don’t know, but Cypress offers this very nice looking device and also a free IDE!
They even offer it as a module http://www.cypress.com/documentation/development-kitsboards/cy8ckit-142-psoc-4-ble-module for $10. It is a bit large so I might want to look into rolling out my own PCB BLE antenna, as they kindly also give all the necessary design files for it.
Price in single quantity is little under $3.50 so they are throwing away these devices practically for free.
For me, and I believe for quite a many non-professional developer, the price of IDE can very easily be the thing that dictates the manufacturer.
So while for power electronics I like Linear Technology and Texas Instruments, I believe for microcontrollers I now like Atmel and Cypress. Texas Instruments has some beautiful devices but the lack of IDE is sort of force majeure.
PSoC 41XX/42XX BLE
Pretty nice device. Deep sleep 20nA. Includes two op-amps and nice bunch of peripherals. No USB which would have been nice bonus but no much use because Windows wouldn’t have included drivers anyways. Wide voltage range from 1.8V to 5V so no external regulators needed either. All this saves a lot of energy and component cost and complexity and enables tiny devices.
With TPS5000 I can get 50nA sleep current which is less than self-discharge of lithium ion battery.001-92738_0B_V
Related to earlier SD card post, here is some information about SPI bus, which at first seems simple but has more to it than that.
SPI is a totem-pole driven system unlike I2C. There is usually a SCK (Clock) sourced by the SPI master, a MOSI (Master Out Slave In) driven by the master, and a MISO (Master In Slave Out) driven by the slave. There is also usually a CS* (chip select) also driven by the master to select the slave. The MISO is tri-stated by the slave until it’s CS* is driven low by the master – this allows multiple SPI devices to be wire-or’d to MISO given that only one CS* is active at a time.
So, a relatively high value pull-up or pull-down value, say 10k, should be placed on the MISO at least. It also makes sense to pull the other master generated signals into a default state when the master outputs are tri-stated, such as when the uC master is in reset.
Now to add a level of complication, there are four different modes of SPI, two of which have SCK defaulted high and two default low. These modes also define which edge of the clock things get clocked on. So, if you are using mode 3 for example, with SCK defaulted high, you should use a pull-up of say 10k to VDD. MOSI can be pulled either way. CS* is usually active low, so should be pulled high.
So for instance one of my datasheets (SRAM) says:
Instructions, addresses or data present on the SI pin are latched on the rising edge of the clock input.
Which I take as meaning that the MOSI should default to logic low (pull-down) and driven high by master.
Then the other document on SD cards says this:
Thus the SPI mode 0 (CPHA=0, CPOL=0) is the proper setting to control MMC/SDC, but mode 3 (CPHA=1, CPOL=1) also works as well in most case. A pull-up on the DO-pin cannot be omited, or some cards will fail to initialize.
So same mode should work for both and DO (MISO) should be pulled high. How the SRAM behaves when MISO is pulled high I am not enterily sure. It only says that the MISO is updated after the falling edge of the clock input, but nothing about the line state. But the commentator above said So, a relatively high value pull-up or pull-down value, say 10k, should be placed on the MISO at least. So it should work exactly like that.
Then, to complicate things, I have voltage divider to shift the logic level. But I believe that should not influence this, as it is simply in series with what ever there is before it. But because the line is pulled high “before” the voltage divider, there is voltage divider of 14K7Ω by 10KΩ and at 5V it gives 2V, which is low but it should be logical high for 3V3 in any system, SD cards included.
OK going back a little, because AVR has all this internally in the hardware SPI driver and the mode can be configured on the fly:doc2585
So there seem to be no need for the external pull-ups or pull-downs.
That text actually points out quite important fact:
it does not have a acknowledgement mechanism to confirm receipt of data and does not offer any flow control.
So one may not blindly trust that data truly is written. One would have to actually read and verify the data.
AVR SPI ICSP
Here is also document about this topic, which may be of interest, as it too uses SPIdoc0943
Logic level shifting for SD card
Using NTS0104 from NXP to shift between 5V and 3V3. It senses the direction so it can be dropped in place. At $0.81 it’s a bit expensive but it is an elegant solution. Especially considering that the MCU used costs about the same in bulk.NTS0104
Also while we’re on basic protocols, http://www.i2c-bus.org/i2c-bus/ is a great site and clear description into I2C protocol.doc2564
And the official I2C specification from NXP:UM10204
Designing communications bus around I2C and here are some documents which came across while doing so.i2cspi-2
It’s a slow speed bus so it will only be used to transmit metadata such as addresses and commands et cetera.
When it comes to Arduino, Wire library must be modified to enable I2C General Call (broadcast) messages:
Note that in the Wire library, the
TWGCEbit is not set. This means that the Arduino will not respond to the I2C General Call address (address 0x00, which is basically an I2C broadcast).
That was one idea but better way to establish node-to-node communication is to have interrupt signals sent from nodes to controller and when controller receives one it knows which node to ask information from, and then that information contains the information about where the controller should send that information (to which node).
This way we don’t need multi-master setup but all control and logic information is relayed always through controller. Controller can this way even to more advanced processing and work as the brains of the system having all control.
I would have wanted direct node-to-node bus but it’s difficult and (unnecessarily) complicated to do it that way, and this will be much simpler setup. This will not be as effective and as fast because all the control data must go over I2C and through the controller, versus common shared bus.
Theoretically something like CAN would work perfectly for this. But neither that would have the capability to work as single, all-powerful controlling entity, because the nodes themselves would have to work as a common entity.
But the system is supposed to have shared SRAM and all the payload would then go through that. So only small number of bits or bytes would ever go over the control bus. Only messages such as “read this information of this length from this bank of memory beginning at this position”, which could be said in less than a byte, would go over the bus. But still, it will add little latency in exchange to simpler topology and in exchange to centralized control.
Texas Instruments has some good devices but they do not provide development IDE for free but their IDE costs quite a lot. But luckily there are free alternatives such as GNU ARM Eclipse project available here.
But one good word for Texas Instruments, despite, comes from providing free RTOS. And that RTOS can be developed with GCC, so it would also be compatible with the GNU ARM Eclipse. They call it TI-RTOS and it is an old system so it has good history and is also actively developed.
Also Freescale provides some interesting looking devices with very powerful capabilities, but those are Power architecture and neither do they provide development IDE for free.
Some manufacturers do provide tools for free. Atmel is one of those. But they do not manufacture the type of devices needed.
Because Atmel Studio is professional level software based on Visual Studio it is going to be better in every possible sense.
Plus you can use Atmel Studio to do any other Atmel development.UsingArduinoBoardsInAtmelStudio
But of course the document is wrong and unless you follow this document here, you may initially, before right results, get timeouts:
The correct arguments line for me ended up like this:
-C "C:\Program Files (x86)\avrdude\avrdude.conf" -p atmega328p -c arduino -P COM3 -b 57600 -U flash:w:"$(ProjectDir)Debug\$(TargetName).hex":i
But these things vary so play around.
So many things to take into account.Atmel-2521-AVR-Hardware-Design-Considerations_ApplicationNote_AVR042
Also looking into consolidating some functionality and removing unnecessary connections:doc2565
Where the plan would be to use ATtiny85 as a co-processor and have I2C communication between that and the main processor. Lots of interesting design ideas.
Looking into this cheap alternative for FTDI, and figuring out how to wire it to talk with AVR.
If you can call it that.CH340DS1
Seeedstudio sells this converter board and along with it comes schematic;USB_To_Uart_5V_3V3_v1
Does not seem to require practically any components. Oddly enough requires external crystal. And apparently they cannot use language English very good:
connects of VCC to input outside power while 3.3V, connects of 0.01uF decoupling capacitance outside while 5V
Make no sense. Connect VCC to input outside power while 3.3V? Could probably mean nothing or something. Cannot trust these at all.
Copied from http://binglongx.com/2011/10/26/arduino-serial-port-communication/ :
The fact that the UART in ATmega328 uses only 2 pins means no hardware flow control based on RTS/CTS or DSR/DTR is available. The USART0 in ATmega48/88/168/328 has a 2-character FIFO receive buffer and a Receive Shift Register, effectively providing a 3-char FIFO buffer.
And ready wiring seem to be available at: http://fobit.blogspot.fi/2014/11/ch340g-in-eagle.html
And the Seeedstudio board:
Also because it is theoretically possible that this chip need to be used (in my design) while power is not delivered via USB (e.g. when we want to use host-mode), we need to have capability to switch the IC power between USB and battery power so this circuit will be used:
Enhancement-mode MOSFETs are the common switching elements in most MOS. These devices are off at zero gate–source voltage, and can be turned on by pulling the gate voltage either higher than the source voltage, for NMOS, or lower than the source voltage, for PMOS. In most circuits, this means pulling an enhancement-mode MOSFET’s gate voltage towards its drain voltage turns it ON.
So when battery is connected to source and the main supply to the gate, the device turns on when the main supply goes off and the resistors pulls the device lower than the source (battery).
Mixed voltages problems
While the CH340 is now capable of powering from USB, battery and also from the tertiary power supply, the problem became that the chip uses different configuration when operating from 5V, than what it does when using 3.3V. So the problem is that while USB is 5V the battery is 3.3V. Also problems do not end there because the battery is not guaranteed 3.3V but the system is specified to work as low as 3.0V, which is 300mV less than what CH340 requires.
Ideally now I would like to find small low current IC where everything is integrated and with one resistor I can set the desired output voltage.
All this will of course extend the functionality of that board but it will also increase the complexity because all these devices need to have the capability to be turned off.
Examining the Li-ion discharge once more
I already have done this but to find out if I can change the specification and consider the battery dead at 3.45V (3.3V + LDO voltage drop) I need to check more graphs.
Curve 3 is the odd ball but everything else seem to drop off the cliff right around and after 3.3V or thereabouts. And more importantly than the voltage drop is the charge used. So if the regulator would have small 150mV drop then the CH340 would only stop operating after about when there would only be about 20% charge left. And with 20% charge left, the original idea was, that at that point everything would turn off to protect the battery.
Looking at following device (XC6210B332MR-G) from Torex Semiconductor with excellent specs and with competitive price ($0.60):XC6210
I had now these devices can come with enable pin. This will make the design job a lot simpler and help me keep within the specification.
My device will operate well below 100mA so the dropout will be negligible.
Too many power sources
I am having problems with power losses because I have three separate possible sources of power and the diode drops are quite large.
One possible solution would be to use specialized devices such as LTC4117 with three power sources:
But the price is beyond belief and $6 is way too high.
Solution was found and I will wr
While arranging components it came to my mind that in which order should I place the capacitors. After several failed Google attempts, one site was following me in results, and it clearly gives answers to this very question:
Read the whole article here: http://blog.optimumdesign.com/how-to-place-a-pcb-bypass-capacitor-6-tips
Also prior to this some capacitors were already changed to tantalums, and were used to replace all the other electrolytics, but since this power board is now taking more general look, those larger, less expensive electrolytics will be added as a main storage site right next to power pins.
The original design was made for 400µA average current and peak of about 20mA but as this is more general, that 20mA may not be adequte for all applications.