Author: crackingcontraptions_3voi0v
The instructions require an STLINK/V2 ($21 and less off the web) which I don’t have of course.
So can I use the JLink EDU. First challenge is getting the connector right. Which is pin #1?
Let’s hope I have this right…
I’ve written the canonical LED flasher program, but now I’m trying to figure out what port.pin the LEDs are on. Back to the Schematic…
timer_start(); blink_led_init();
// Infinite loop while (1) { blink_led_on(); timer_sleep(BLINK_ON_TICKS); blink_led_off(); timer_sleep(BLINK_OFF_TICKS); }
Looks like there’s one on Port C, pin6. Can it be that easy?
OK, it looks like I can talk to the EVB1000 because I seem to have nixed the program that was in it, so clearly something got flashed. But the program isn’t starting…
This CodeSorcery compiler looks like it needs a different set of startup files. I wonder if I can get it to work under the gcc compiler instead.
Recompile, and change a few settings…
Poked around a bit more and managed to find out how to get the semi-hosting to work too.
There are a couple of additional compile-time constants that have to be set:
STM32F10X_CLTRACEOS_USE_TRACE_SEMIHOSTING_DEBUGUSE_STDPERIPH_DRIVERHSE_VALUE=8000000
Found this useful comment buried in some library code.
// Note: Applications built with semihosting output active cannot be
// executed without the debugger connected and active, since they use
// BKPT to communicate with the host. Attempts to run them standalone or
// without semihosting enabled will usually be terminated with hardware faults.
BTW. I’m still keen to try and get everything to fit on the Nordic, because it’s just such a neat solution. I think it’s worth the struggle.
//Mik
On Sun, Nov 16, 2014 at 10:34 AM, Mik Lamming <mik@lamming.com> wrote:
See my previous. If I could just compile the current code then I’d have an idea how much RAM it consumes. Maybe it will fit easily. I’m working on the assumption that we may be able to dump a bunch of functionality from the DW library because we only really need the ranging. On the other hand, it looks like the ranging builds upon the basic packet handling, so there may be a limit to how much it can be chopped.
//MikOn Sat, Nov 15, 2014 at 10:04 PM, David Carkeek <dcarkeek@gmail.com> wrote:64k RAM seems to equate with large package. I can’t find a small physical size part with 64k RAM.Cypress
Atmel 48k RAMAtmel 96k 1M FlashWhat do you think the chances are of fitting the Decawave code into 32k RAM? I think moving away from the nRF51822 will make things a lot bigger. But there might be some new/other products I haven’t found out about yet.
I’m getting increasingly queezy that the Nordic chip won’t have the guts to do the job. DW have configured the ARM m3 to use 64K of RAM. We may have more difficult challenges than just voltage levels!
//Mik
On Sat, Nov 15, 2014 at 10:04 PM, David Carkeek <dcarkeek@gmail.com> wrote:
64k RAM seems to equate with large package. I can’t find a small physical size part with 64k RAM.Cypress
Atmel 48k RAMAtmel 96k 1M FlashWhat do you think the chances are of fitting the Decawave code into 32k RAM? I think moving away from the nRF51822 will make things a lot bigger. But there might be some new/other products I haven’t found out about yet.
——————-
On Sat, Nov 15, 2014 at 6:58 PM, David Carkeek <dcarkeek@gmail.com> wrote:
On Sat, Nov 15, 2014 at 6:58 PM, David Carkeek <dcarkeek@gmail.com> wrote:
https://devzone.nordicsemi.com/question/16825/new- version-of-nrf51822-silicon/ The answer from the Nordic guy sure makes it sound like there will be a version that has more RAM.This was written 16 days ago:https://community.spark.io/t/
sparkle-a-bluetooth-le- powered-spark-core-clone/6108/ 54 So, after all the hard work getting SparkLE working with a “handshake MCU”, there has been an interesting development. I found out a few weeks ago (and Nordic Semiconductor just announced this week) that there will be a new version of the nrf51 chipset with 32K RAM. That means no more need for a second MCU on-board!
Here’s the announcement:
So we have to get some samples of the new 32k nRF51822 and mount it on the Ray-Tac modules. I’ll also email Ray-Tac to see if they will be building 32k versions.But is 32k enough?If it’s not we can change directions now and make a board with an M3 and separate BLE radio. That might be best anyway.
Mik responds:
If I could just compile the current code then I’d have an idea how much RAM it consumes. Maybe it will fit easily. I’m working on the assumption that we may be able to dump a bunch of functionality from the DW library because we only really need the ranging. On the other hand, it looks like the ranging builds upon the basic packet handling, so there may be a limit to how much it can be chopped.
//Mik
On Sat, Nov 15, 2014 at 12:05 PM, David Carkeek <dcarkeek@gmail.com> wrote:
I thought the DW1000 I/O supply could be run at 1.8V, but it can’t. It’s 2.8V – 3.6V. There are separate 1.8V-optional supply pins for digital and analog circuits (to save power) but they can run at 3.3V. So for the time being, since the nRF51822 can run at 3.3V, the whole board will be 3.3V so all the I/O’s will be 3.3V. Later we will have to determine if running the nRF51822 at 1.8V for power saving is needed, then level shifting the signals connected to the DWM1000.I assume the Segger adjusts to the proper I/O voltage by means of its Vref pin.
—————–
I’m not sure how the SEGGER knows how to adjust, but I found this bit in the SEGGER documentation.
—————-
David:
| Jtag: SWD:
Wire for SWD, correct?
Can you look on your board to see what pins I used on the module for SWO and RESET? Or maybe just take a picture and send it to me.
|
David (understating the laborious nature of this process):
There will be hardware soon. It takes longer than one might imagine to strip back 70 wires, wrap each one around a header pin, and solder them in place. I am not stripping the wires; instead I melt the insulation away with a soldering iron, because stripping would pull on them too hard, assuming I could get the tool close enough to the board, and then the wire would get nicked and break off, leaving it too short to strip again. When I worked at Siemens we had a thermal wire stripper that burned the insulation down to the wire instead of cutting it. We were breathing those fumes all day. If I thought I would doing a lot more of it I would buy one but I am pretty sure we won’t be mass producing these boards.
Notice the skip from workday #29 to #33. For the past three work-days and more I have been proceeding on plan B. Sadly this has not resulted in any code because I’m still trying to install a bloody tool-chain! (Tool chain, tool-chain, or tool-chain?) I’m frustrated and tired, and taking a break to write down what I have learned in the hope it sticks in my brain and comes in handy one day.
For porting code, what you need is an environment where you can have both sets of code to hand to test, and can keep close track on the differences. That means that you have to have two development systems running side-by-side. Ideally you want exactly the same code, and to be able to click on a button to compile for target A, or click on another button and compile for target B. Setting that up turns out to be a mind-boggling exercise, because it requires Eclipse or a similarly powerful IDE.
After thrashing around in the haystack reading a whole load of out-of-date, and misleading documents, documents that don’t actually tell me what I need to know, I decided that I would have to figure it out, step-by-step. The challenge is understanding the Eclipse plugin architecture, and where tool-chains have to be located, and referenced. Once upon a time I wrote this:
“One thing that amazes me is how nobody ever thinks to provide a conceptual model. There are lots of recipes, all of which become rapidly out of date. Nobody seems to understand that even a simple description of the objects, how they fit together, and what commands they implement, would so vastly simplify the process of understanding complex systems, as to enable people to figure out solutions for themselves, and eliminate most of the need for lengthy recipes.”
Turns out the Eclipse model is very flexible, and there are few general rules. Correction! There are general rules, but there are few general rules to which people universally adhere. Each tool-chain implementer has taken their own set of liberties with the intended architecture, and made certain assumptions, or put in extra configuration steps, to minimize the amount of adaptation work they have had to do.
To learn how it all fits together I had to start with an “empty” Eclipse. I started adding various components until I could compile a C program on Windows, for Windows. This sounds like a pretty easy thing to set up, and it almost is if you just install the pre-baked Eclipse for Windows C developers. But if you want to understand what all the parts are, then you have to install the plugins, the compiler/linker, and all the utilities like “make”, one part at a time. And then you have to figure out what environment variables eclipse considers, and get them set up just right, and then add all the extra variables that are needed.
It took two days for me to figure it all out so I could do it over, and over and get it to work every time. Notice that the only reliable way to check that it is done right is to delete everything: eclipse, tool-chain, plugins, utilities, then nix all the special Windows environment variables, then reboot, and start the installation (Many GB-sized downloads over the network) from scratch.
But the good news is that not only have I figured that bit out, but I am writing it down as I go!
Of course, compiling C on Windows for Windows is not what I need. I had to discover how to install a tool-chain to cross-compile for some embedded system. i.e. C on Windows for an ARM processor. It seemed like all you had to do is install a new tool-chain and point a few environment variables to new places. In principal that’s right, but in practice it’s much more messy. The Windows->Windows C tool-chain has all sorts of built-in support behind the scenes that you don’t see. For cross compilation you have to install that extra support.
What do I mean? Eclipse (and many of the contributed tool chains) were developed under Unix/Linux and to achieve portability and modularity, they lean heavily on standard Unix utilities. Many of which are just not there in Windows. Even the simplest Unix utilities don’t work on Windows – consider “rm” in Unix – it is called “del” in windows. It has different semantics, and takes different parameters. So Unix clones of these commands and utilities have to be installed.
Then of course there are different compiler chains, even for the same hardware. I already know that there are Gnu, Code-Sorcery, and Keil compilers that target ARM processors. Atmel has ARM tools too. Then there are all the plugins that know about details of a processor – like the Nordic chips with integrated BLE. So there are choices with benefits, and penalties.
So if you have go this far without dropping off to sleep you can see that it has (continues to be) a tussle. I tried all the shortcut installs, and read a bunch of stuff, but in retrospect I can now see that this tedious learning process was inevitable because I can’t get by with a single pre-packaged tool-chain. Once you need two tool-chains, you have to figure out how they can fit together without interfering with each other.
Anyway, I have learned a lot that will stand me in good stead for future stuff, and I feel a little more potent today than I did yesterday.
——————
David responds:
Far from dropping off to sleep it was very interesting. But exhausting to imagine going through it. At least you have the knowledge and background to figure it out. I wouldn’t be able to – not even to start down the path.. What a huge effort. What is everybody else in the world doing to use these tools?
——————
David responds:
Far from dropping off to sleep it was very interesting. But exhausting to imagine going through it. At least you have the knowledge and background to figure it out. I wouldn’t be able to – not even to start down the path.. What a huge effort. What is everybody else in the world doing to use these tools?
Have you considered writing a book or pamphlet? But you said you would never write a book again. If you are writing it down is it something I would be able to follow and get to work on my end?
There will be hardware soon. It takes longer than one might imagine to strip back 70 wires, wrap each one around a header pin, and solder them in place. I am not stripping the wires; instead I melt the insulation away with a soldering iron, because stripping would pull on them too hard, assuming I could get the tool close enough to the board, and then the wire would get nicked and break off, leaving it too short to strip again. When I worked at Siemens we had a thermal wire stripper that burned the insulation down to the wire instead of cutting it. We were breathing those fumes all day. If I thought I would doing a lot more of it I would buy one but I am pretty sure we won’t be mass producing these boards.
———————
Mik responds:
Yes, it’s all pretty tedious. But it’s just a matter of being relentless, which I can be. It’s the thinking part that slows me down.
I’d be very pleased if you’d try to follow my installation instructions so that I can debug them. I was half-thinking that it would be good to write them clearly enough that you could use them to setup a debug environment. But I have to be honest, my main motivation is that after a few months all the details go out of my head. So I’m trying to be meticulous, but express the process in a general sort of way so that even I can understand it in a year, and reconstruct the Eclipse system when everything stops working for some weird reason.
My plan is to write down all the gory details, and then, boil it all down to a cheat-sheet in some sort of appendix, so I can romp through it, and only need to read this dross again if it doesn’t work.
As soon as I get to the part where you can compile “Hello_C_TS06a” I will send you all the setup instructions. You could plod through and make annotations in places where things don’t work, or need clarifying. Or maybe we should get together and go through the the setup on your laptop, and I can fix the holes in the process and the documentation in real-time.
I’m very excited (and kind of worried) to hear that there will be hardware soon. You have really made a lot of progress. I had no idea there were so many tiny wires, but if I had stopped to think for a while, I guess I’d have realized the awful truth. You must be going crazy. Clearly we should invest in thermal-wire stripper. I can’t imagine that we won’t want to lash on bits of stuff, and make changes.
Maybe you could send me a photograph or two for the Blog? I’d like to record the process you are using to put it all together.
I remember the Xerox Dorado was all done with an automated wire-wrap robot, and later a stitch-weld robot. Presumably you could use a hand wire-wrap tool? I know they are fiendishly expensive. Here’s a picture I had. I actually had a Dorado stich-weld board until I gave it to the Cambridge Computer Museum last visit.
I think it will be fun in our dotage (next week?) to look back at this stuff, when all the technology has moved on. “Oh yes, we had to solder lots of little wires… none of this home-robot assembly”
Oh well, back to bashing on with the installation process…
I just got to peruse the new DW docs. I’m encouraged by the depth and detail of the documentation, but I’m also really daunted by the task ahead. If I’m not going to get overwhelmed I need to make a plan, and then stop focusing on what has to be done, but just check off the tiny steps forward.
Here’s my plan:
Revise the DW demo code to make the port to TS06 as easy as possible
- Install Eclipse (in the manner prescribed by DW) and try to compile a minimal hello.c (“hello world”) program for the ST32F407 “Discovery” board I have in the cupboard. This will show that I can configure eclipse for an STM ARM chip. I was able to do that some months ago, so it ought to be reasonably easy.
- Reconfigure eclipse for the DW eval kit (EVK) and compile hello.c for the DW eval kit (EVK). Alas the EVK uses an ST32F105. There are substantial processor differences obviously, and I will have to figure out how to load and debug code on the DW platform. I’m hoping the move is simply a matter of specifying the different processor, and using a different in-circuit programmer/debugger (e.g. SEGGER).
- Compile DW’s demo program and see if I can get it to load and run on the EVK. In theory this ought to be easy because DW tell you how to do it, but I have not had an easy time with the eclipse setup documentation, so who knows how hard this will be in practice.
- Strip down the DW demo code to some form that could run on the M0. This means stripping out all the code that uses the LCD, switches and so forth. I will need a simple test program that can indicate that ranging is working OK. This will give me a test program that provably works with functional ranging hardware.
I have no idea how long those four trivial steps could take. So far it has taken many weeks, to do a lot less.
Create a minimal Hardware Abstraction Layer (HAL) for the TS06
The TS06 hardware is an ARM M0 with an attached DW module – i.e. this translation is not chalk-to-cheese, but it is Brie-to-Velveta.
- The first step is to configure eclipse to target a Nordic M0. Earlier this year I found this to be a real challenge.
- Create a new TS06 HAL that will allow the same hello.c program to run on the TS06, EVK and Discovery boards. It should be possible to have exactly the same program run on all three.
- Extend the TS06 HAL to talk to the DW module.
- Get the minimal DW demo code to run on the TS06
Do everything else
Today I started trying to install the eclipse IDE so I could compile and load the DW sample code on the evaluation system.
The document ECLIPSE IDE SETUP GUIDE that I have downloaded is out of date and the instructions simple do not work. They rely on Sourcery CodeBench Lite for ARM EABI. When you go to the sire you get this.
Sourcery CodeBench Lite releases for ARM EABI, ARM GNU/Linux, ARM AARCH64-Linux, IA32/IA64 GNU/Linux and ELF are no longer available.
I tried to download it from elsewhere and the virus checker claimed it was full of viruses.
On Fri, Oct 31, 2014 at 8:20 AM, Mik Lamming <mik@lamming.com> wrote:
Nordic announce support of some near-field charging standard.
I don’t understand what Nordic have done.
——————–
On Fri, Oct 31, 2014 at 8:56 AM, David Carkeek <dcarkeek@gmail.com> wrote:
There are a bunch of new things in this press release so I don’t understand it either. They say “magnetic resonance” and “spatial freedom” but then talk about pads and surfaces as though the device has to be resting on the surface. It s says “Out of Band” which I don’t understand and “up to eight devices”. Why couldn’t it be nine devices? Why do you need an SDK to make a charging system?
What I kind of think is that there a pad which is a kind of transmitting antenna that emits a signal to which a device resonantly couples over a distance that is not zero for the purpose of transferring energy for battery charging. Each device needs a channel (up to 8 are possible). That would be super cool if true. Need to read about Rezence. I might be completely wrong.
“The nRF51 Wireless Charging SDK is available today on a limited basis to lead customers.”
but “Engineering build of S120 and an updated nRF51 SDK is available today as a download for existing customers of nRF51822.”
Whom do I ask for the link? Not that I would know what to do with it after downloading.
————————-
On Fri, Oct 31, 2014 at 10:46 AM, Mik Lamming <mik@lamming.com> wrote
On Fri, Oct 31, 2014 at 10:46 AM, Mik Lamming <mik@lamming.com> wrote
Following up on I’m assuming that the range is at best centimeters because it is near-field which drops off dramatically after a few wavelengths… doesn’t it? The frequency is 6.8MHz, so the wavelength is ~5cms? (Wrong 44.1 meters)
Aha… I found this.
http://en.wikipedia.org/wiki/Rezence_(wireless_charging_standard) which contains this useful information sentence:
The interface standard supports power transfer up to 50 Watts,[1] at distances up to 5 centimeters.[2]
I also found this excellent video, the first 2-3 minutes of which gave me a strong intuitive sense of the characteristics. https://www.youtube.com/watch?v=r1UT4NuygmQ
————————–
On Fri, Oct 31, 2014 at 11:29 AM, David Carkeek <dcarkeek@gmail.com> wrote:
Too bad it doesn’t work across a room, but still quite interesting. I watched about 5 minutes but I’ll have to finish it later.I’m somewhat ashamed to say I don’t know much about RF fields, near-field, and the relationship of wavelength to power transfer. The wavelength of 6.8 MHz is 44 meters according to the calculator. I wonder why that frequency was chosen. It must mess pretty badly with nearby radios.A Tesla coil can work at tens of feet, maybe hundreds of feet.
—————————–
On Fri, Oct 31, 2014 at 13:59 AM, Mik Lamming <mik@lamming.com> wrote
It’s only yhe first 5mins that are worth the time. The rest got out of my depth anyway. It just gave me a good feel for the strengths and weaknesses of near-field.
Ah MHz, not GHz! Yes – I agree. Doh. Good job you check all my math.
c = 300,000 = 3 * 10^5 kms/s = 3*10^8 m/s
6.8 MHz = 6.8 * 10^6Wavelength = (3*10^8) / (6.8 *10^6) = 44.1mIt’s only the first 5mins that are worth the time. The rest got out of my depth anyway. It just gave me a good feel for the strengths and weaknesses of near-field.