Month: September 2014
There is a program that allegedly does this called uart_example. It’s really very simple, but I just can’t get it to work because these dongles are old, and incompatible with the software. I have to see if there is a workaround.
Reduced to groping around the Nordic Developer zone I found this useful little contribution.
I just got stung by this too.
Turns out I have an earlier version of the PCA10000 board. Check your board to see if you have V1.0 like I do. If so, this fix is easy… once you know anyway.
Go to Includes/boards/pca10000.h. There is an #if /#else construct for selecting between board versions. Change to #if 0 for V1.0 and away you go.
So I made a new version of pca10000.h changing the one critical character from a ‘1’ to a ‘0’!
Success!!
I have to start somewhere writing code. There is a stock piece of code from Nordic that claims to use a BLE library, plus a dongle to emit advertising packets from a PC.
The code is pretty simple, and the library is a DLL. I have to arrange that the DLL ends up in the same directory as the executable before the program runs, but every time I clean the code it get’s deleted. Then the program is simply silent. It took a while to figure that bit out.
So far I seem to have managed to compile the code and get it to start the DLL. It runs but doesn’t do anything.
If I run the code from a command line I get a bit more information than the zero I get from within Eclipse.
The dongle is actually on COM7. Small code change. Seems a bit better, but now what?
I think the Nordic dongle has to be programmed with some alternative code. I have not found instructions to that effect yet. Need to poke around. Also, presumably the dongle needs to have the right sort of soft machine installed.
I have not found any help yet, but I notice that there are three hex files packaged with the C code.
bad news, it still doesn’t work.
Now what?
I started seeing if I could get these Nordic eval boards to talk to my BLE phone. Not yet is the answer.
The funny thing is that I’m having no trouble at all getting those little StickNFind things to show up on the phone. I can even tell the phone to make them beep, or flash.
Now to be fair I don’t know what I’m actually doing. I have downloaded some Nordic example coad, compiled it without error, and tried to run it. There are actually seven different example BLE programs that I can compile and load, but none of them produces a thing. Even the “beacon” code which is supposed to be about the same as a stickNfind doesn’t work.
So I reckon the next step is to see if I can get some radio sniffer program to report in.
…
So there seems to be a rather good packet sniffer program called Wireshark. It seems to pick up packets from the FitBit on my wrist, and and and all of the StickNFinds. But I’m not getting any data out of the Nordic board. I think it is a fair guess that the software is not emitting anything.
I’ve tried both boards and neither produces any radio traffic that the sniffer can see. This has to be something fundamental.
Started to try and debug the example code. Two weird things: 1) the code seems very reluctant to load – the previous program resumes; I can’t get the debugger to work. This has to be something even more fundamental. Retiring to read a bunch of stuff.
It is fundamental indeed
Dah, There it is on page 2/35: “program the S110 Softdevice onto the chip using the….”. The softdevice (the standard stuff that implements the BLE stack) has to be loaded spearately from my program. There was I expecting it to be bundled with my program code, but of course you don’t want to have to load it every time, do you? It resides in the top part of memory.
To program the softdevice into the 51822 you have to first install their special program called nRFgo Studio. So… yet another download, and installation.
Then you have to get permission to download the Softdevice itself. This requires credentials. There are multiple softdevices. S110 seems to be a stack for the “Peripheral” role, while s120 is the stack for the “central” role. You can’t both initiate connections, and accept them from others!
So I install the S110 softdevice and notice that it consumes 88K, leaving only 168K for all the application code, and in our case, for the code we need to drive the DW stack.
nRFgo Studio: Downloading the S110 softdevice |
Ah… that makes quite a difference. I follow instructions and download the heart rate monitor simulator program. It woiks. PROGRESS!
Nordic Heart Rate Monitor Simulator |
After playing around with this system for a while I have to say it doesn’t seem very robust!
From: David Carkeek <dcarkeek@gmail.com>
Date: Tue, Sep 16, 2014 at 10:26 AM
Subject: Marketplace
To: Mik Lamming <mik@lamming.com>
- while (true) // never-ending outer loop
- {
- for (b=’A’; b<=’Z’; b++) // set ‘b’ to each of the asci characters in the range A-Z
- {
- nrf_gpio_pin_write(ERROR_PIN, 1); // turn on the LED as a scope trigger
- simple_uart_put(b); // emit the selected character in variable ‘b’
- // simple_uart_put(((b * 0x0802LU & 0x22110LU) | (b * 0x8020LU & 0x88440LU)) * 0x10101LU >> 16);
- // to reverse bits I uncomment the line above, and comment out the one above it
- nrf_gpio_pin_write(ERROR_PIN, 0); // turn off the LED/trigger
- nrf_delay_us(1000*100); // a delay to make characters come out at 10Hz
- }
- }
The diagram and the text are not explicit about the bit order. By that I mean, is the chracter in the above example 0x51 = ‘Q’, or reading in the opposite direction 0x8a = Š (Latin capital letter S with caron). The latter seemed an unlikely choice for this example, which implies MSB-first is more likely.
The serial port has many pins. We will discuss the transmit and receive pin first. Electrically speaking, whenever the serial port sends a logical one (1) a negative voltage is effected on the transmit pin. Whenever the serial port sends a logical zero (0) a positive voltage is effected. When no data is being sent, the serial port’s transmit pin’s voltage is negative (1) and is said to be in aMARK state. Note that the serial port can also be forced to keep the transmit pin at a positive voltage (0) and is said to be the SPACE or BREAK state. (The terms MARK and SPACE are also used to simply denote a negative voltage (1) or a positive voltage(0) at the transmit pin respectively).When transmitting a byte, the UART (serial port) first sends a START BIT which is a positive voltage (0), followed by the data (general 8 bits, but could be 5, 6, 7, or 8 bits) followed by one or two STOP BITs which is a negative(1) voltage. The sequence is repeated for each byte sent.
Assume we want to send the letter ‘A’ over the serial port. The binary representation of the letter ‘A’ is 01000001. Remembering that bits are transmitted from least significant bit (LSB) to most significant bit (MSB), the bit stream transmitted would be as follows for the line characteristics 8 bits, no parity, 1 stop bit, 9600 baud.
LSB (0 1 0 0 0 0 0 1 0 1) MSB
Here for comparison is my scope image of ‘A’ allegedly with even parity.
Character ‘A’ |
Character ‘C’ |
I started to persuade the ARM chip to emit characters out its UART. I connected the output of the ARM UART to the UART on my PC and after some fiddling around… didn’t get a thing.
Connections to laptop and scope |
First issue, there isn’t a serial port on my new laptop. Had to dig out my old USB->Serial cable. Then of course none of the drivers work.
Still nothing, but then I discovered I was monitoring the wrong pin. OK.. progress! There is stuff coming out. But it’s garbage.
Here’s what it says in the documentation for the Nordic UART example program.
The UART Example demonstrates basic UART usage for communicating with a PC terminal. It transmits and receives data through the configured pins as a serial device. The configure pins needs to be redirected to a COM port (terminal programs like putty can listen to this COM port through a terminal session). When the program starts it will transmit “START: ” through this serial device usingsimple_uart_putstring and this should be visible on the terminal. All typed characters on this terminal will be transmitted to the program through simple_uart_get and when an exit character ‘q’ or ‘Q’ is typed the program will end into an infinite loop after transmitting “EXIT!” on a new line of the terminal.
Tried all the usual things, baud rate, stop bits, parity… still garbage.
Now I dragged out the ‘scope. Used one of the LED pins as a trigger. I made a program that outputs all characters from 0..127 at 100ms intervals.
simple_uart_config(RTS_PIN_NUMBER, TX_PIN_NUMBER, CTS_PIN_NUMBER, RX_PIN_NUMBER, HWFC); // hardware flow-control = false
nrf_gpio_cfg_output(ERROR_PIN);
while (true)
{ for (b=0; b<127; b++)
{
nrf_gpio_pin_write(ERROR_PIN, 1); // trigger for scope
simple_uart_put(b);
nrf_gpio_pin_write(ERROR_PIN, 0);
nrf_delay_us(1000*100); // a respectable pause
}
}
The scope showed the bits coming out like this. i.e. a byte value of 0x01 actually appears on the scope like this.
Character code 0x01 (no parity bit) |
Character code 0x80 (no parity bit) |
Now the PC has decided that it won’t listen to the USB->UART COM any more.
So what could it be?
Hello World in embedded space is something that just blinks a LED. My version is called MikBlinky. To compile and run this code on a Nordic PCA10001 eval board you need to do the following:
- Download this code from our shared directory at Google.
-
Unpack it to this place.** If you don’t have this place already set up then you probably didn’t manage to install the Nordic SDK nrf51_sdk_v6_1_0_b2ec2e6.msi and you should have another look at this blurb. You need to have all the Nordic libraries and stuff set up in the right place or the compile won’t find them.
- So, assuming you have it in the right place now, de-compress it.
-
Now drill down into the mikBlinky directory and find the file blinky.uvprojx. Note the “x” on the end which signifies it is a uVision5 project.
-
Double-click on blinky.uvprojx to open the uVision IDE and load the program into the workspace. You should see the main loop of my program.
-
Compile it by clicking on the Build Target menu. You can also press F7.
-
Now plug the PCA10001 board into the USB socket of you computer. It ought to be discovered.
-
Now you can send the program to the PCA10001 to be flashed and started by clicking on the Download menu item.
-
Now you can fiddle about with the code (change some of the delays for example);
F7 to save changes and compile them, Download to flash and watch the changes.
David and I met after my long summer “vacation” in England. I guess I started work on TS06 yesterday Sept, 8th. Today, of course, we can expect semen to be all over the sidewalks of SF because Apple announce their iWatch today. How has this company managed to get such blatant world-wide free advertising?
Objective
Basically we are trying to make a smaller version of TS05b with the following improvements:
- Better ranging using the DW chip
- Better power utilization, maybe incorporating some on-board generation capabilities
- Smaller – with a view to a wrist worn device
There are a bunch of other little changes, but these are the fundamental ones.
Target Processor issues
So the first job was to figure out the plan of attack. The DW EVK uses an STM32F105 ARM chip, a Cortex-M3 core, as the processor. It has 256K flash, and 64K RAM and a maximum CPU speed of 72 MHz.
We are going to use a seriously more constrained processor – the Nordic nRF51822 BLE chip – because it has BLE. It is only a 32-bit ARM Cortex M0 processor with 256kB flash, and only 16kB RAM. The BLE stack consumes a lot of space and we have only about 180K left for our code. The CPU speed is 16 MHz. Let’s hope it can handle the interrupts.
So my major worry is that the DW stack soaks up a lot of RAM for buffers and so forth and we run out. So the first goal is to answer this question, and until we have an answer it makes developing anything more than minimal hardware a potential big waste of time.
Setting up Keil IDE – Day #2
I’ve spent a lot of time trying to set up Eclipse for the Nordic and it has been quite a struggle. I suceeded but I’m not feeling confident that it is stable – or that I could do it again, but maybe I’ll have to.
Unfortunately the propreitary system from Keil system costs $9K, but it looks like it has some decent libraries and a RTOS which could be useful. It would be good to evaluate the Keil system and decide if all those apparent advantages are real. Yet again David has worked some kind of magic that was way beyond my capabilities and located a system we can evaluate for an extended period. Our problem now is downloading it and trying it out. It consumes 5GB, takes 2 hours to download, and has totally maxed out the laptop I was going to use to evaluate it.
Installation
- Install mdk511a.exe When it finishes the Pack Installer will start up and you’ll notice that there are no Nordic devices. Quit the Pack Installer for now.
- Install Legacy support mdkcm510.exe
- Install nrf51_sdk_v6_1_0_b2ec2e6.msi from here.
making sure to include the nRF51822 examples,
Make sure to include nRF51822 examples and make sure that the nRF Device Family Pack is going to be included
- and at the end accept the CDC OB CDC Driver package,
and accept the terms of the nRF_device Family Pack
- Start uVision and select Project/Manage/Pack Installer and make sure that the appropriate Nordic parts, and the STMF105 (DecaWave) are installed. If not install them.
- Now you have to make a valid license. To do that right-click run-as-administrator the new Keil iVision5 system you have just created.
-
Click File/License Management
-
Copy the number out of the CID field
-
Disable Virus Checking, start the KeyGen, paste in the CID, and click generate.
- Copy the key that gets generated in the bottom field of the KeyGen into the New License ID Code field of the License Manager, and press Add Lic
- A license key will be generated and you can verify the expiry date.
Not that there are no Nordic devices |