R2B4 #7 - Reading the SensorTile

1.     Aims

In the last blog I formulated a plan to get the SensorTile data from the SensorTile Cradle Expansion board and out on the 'Arduino' interface pins CN 9 pins 1 and 2.

2.     Data From SensorTile Cradle Expansion

I thought back in R2B4 #6 - SensorTile Outputs  that I was so close to getting this to work by just bridging the solder bridges SB11 and SB20 on the SensorTile Cradle Expansion board but luckily kulky64 has been providing massive amounts of help in the suggestions of that thread - so many thanks for all that assistance. Actually I learned a lot from those comments as it pointed me into areas of the schematics to see what those solderbridges did and to understand why I was being suggested to open or close them.

For a while at this point it seemed I would need to disconnect the ST-LINK v2 part of the Nucleo board by opening up SB13 and SB14. I wasn't too keen to do that as I thought I would likely loose the programming ability but again kulky64 provided valuable comment that this would not be the case. Currently I have:

• re-opened SB23/23
• bridged SB11/20 on the SensorTile Cradle Expansion
• bridged SB62/63 on the STM32F411RE-Nucleo board
• opened SB13/14 on the STM32F411RE-Nucleo board

Getting a little dispondant I then looked again at the SensorTile cradle and what it offered. The only input/output from that was via the USB. Therefore I could program the SensotTile and solder it to the SensorTile cradle and when powered up the data would be output on the USB as previously seen...maybe I could take that data via a USB cable to the STM32F411RE Nucleo board and read it back in (swapping between the programming and the reading function cables as required during development). I'd need a USB adapter to micro but that would be all. I parked this divergent thought for a while and went back to trying to get the board working as I intended.

I started a new thread on getting HAL incorporated to a STM32/CubeMX project HAL Libraries - Importing and Using which might be useful to other newcomers to this area.

It was also suggested by kulky64 that I make a simple UART example in STM32CubeMX to test out the pins of the board. I did this and setup both UART5 and the LP_UART and added in code to output a couple of known characters 'U' and the coma symbol. I was happy to see data on the CN9-pin 2 that looked like UART data. It was changing and ocasionally seemed to burst in duration....I had doubts it was actually my data.

Modifying my code didn't seem to affect the output and finally I commented out my lines where I transmitted the characters. The data was still visible on my oscilloscope - it seemed to me that perhaps it was debug traffic on the USB/UART pins and I hadn't quite disconnected them as I had thought. I was getting ready to spend another few hours reading the datasheets and making code changes (which incidentally isn't a bad thing as I'm getting better at understanding the whole STM32 'thing' and debug, CubeMX etc) which was when another post from kulky64 came through intoHAL Libraries - Importing and Using

I made the changes as suggested (coupling the CN9-1/Morpho CN-10-37 to Rx on the Nucleo board, and upon debugging my code I found the PuTTY screen filling with the 'U' character.

I then changed my code to output a little thank you message for all that help:

3.     The Way Ahead is Clear(er)

3.1     The STM32F411RE-Nucleo

I still need to program my STM32F411RE-Nucleo board.

The aim here is to start from scratch using the STM32CubeMX package and it is to be seen if I can actually get something up and running - I'm hopeful given all the STM32/TrueStudio skills I have started t build up. Although R2B4 is a long way off I am actually really pleased - for once I am finally starting to understand these boards.

3.2     Reading the UART

The Nucleo code will need to read the UART stream and extract the relevant data - snipping out the various ASCII characters and casting those strings back to integers.

3.3     System Code Design

I also need to then write the main functions for mobility of R2B4, namely (1) a function that can turn R2B4 to align with a magnetic compass value and (2) to drive R2B4 along by a set distance that will be based on steps to the motor. The basic navigation could be via three pairs of data (angle of travel and distance to travel). The angle of travel would naturally require to work out the quickest turn to get to that bearing based on the current bearing. Once the R2B4 has worked its magic at the destination (i.e. offloaded the sand) it can easily work out the reverse route and navigate that back to the sand heap.

4.     Things To Do

There is lots still to do (and not much time left now):

• R2B4 cannot actually move very well still - I need to adjust the gearing
• I need to control the A4988 drivers from the Nucleo board
• I need to read the UART into the Nucleo and act on those values
• I need to design the load/unload mechanism - utilising the TE Connectivity Load Cell
• I need to work out how to actually program R2B4 with a 'route'

5.     What For Blog #8

I am hoping I can at least read the SensorTile UART data into the Nucleo, and I will share that code in my next blog. Even without much additional logic I should be able to step through some simple manoeuvres and get R2B4 to navigate a course and I hope to show a video of that happening. I also should have the larger GT2 pulley arrive and so can add that to get R2B4 moving with greater traction.

Rod