altineller

I have made a simple implementation of an ANN that runs on the Tiva-C and 5529 using c++. It basically is a spiking neural network where the input is summed, and if above threshold, that neuron fires all the axons with 1 * W. There is also a mechanism of decay of the firing rate each time the neuron runs, and a mechanism to modify the neurons firing time, (the more the sum is, the quicker it fires, with in a range.) So the output from each neuron is always one, but the frequency differs.
So, it is a trivial spiking neural network but it works. I already connected 4 light sensors, 4 input neurons, 1 hidden layer of 4 neurons, 2 output neurons to motors, and obtained a robot that goes around the light like a fly.
@spirilis are there other implementations for embedded platforms for neural networks, that runs on TI products?
would anyone be interested in the ANN code, if i make it opensource will anyone help me to make it better? I would be very interested in modifying it so it runs on the c2000.
basically it would benefit from a fpu. all it does is sum and multiply floating point numbers.
~Best
 

Has anyone seen the : Mini-M4 for Tiva-C
https://download.mikroe.com/documents/starter-boards/mini/tiva/mini-m4-tiva-manual-v100.pdf
Would it be safe to assume that it could run energia?
 
Best,
C.
 

I second this question. As I recall the ds3234 is also active high on CS / CE.

Do you set the chip select (CS or SS) pin?

@@altineller
 
See this thread: http://forum.43oh.com/topic/7330-pwm-changes-depending-on-the-code-its-running/

@@altineller for changing the analogWrite() resolution on MSP430 see this post: http://forum.43oh.com/topic/9341-change-resolution-pwm-with-msp430fr6989/?p=70874

When thinking about what Energia project to bring to Makerfaire, it occurred to me, that the counter library can count slower things than just wave forms in the MHz. You could say, the penny dropped.

My Penny Counting Machine is built from a geared DC motor (unknown donor), a fork light barrier sensor from an old HP printer, a dairy cup with a bit of thick double-sided tape to make a ramp, a slide built from spare cardboard, and another dairy cup to receive the pennies. All held together by ample hot glue.
 
A G2 launchpad makes up the brains, my own SHARP Memory display BoosterPack shows the current count, and a bit of prototyping board holds some resistors and a transistor to control the motor and connect to the sensor.

 
See it in action here:

 
Attached the code for Energia. It uses the CounterLib and my SHARP Memory Display library.
PennyCounter.ino

yes and no. i decided to use the clock-direction mode with only one hallsensor, because the signal of both hall-sensors did not fit to what is needed for quadrature-mode (my sensors did not have the state both high, tell me if you need more information...).
i get the direction directly from my montor-controler and only need one hallsensor as "clock" because every flank (up and down) is counted, there are two counts per revolution. if you know this it should be no problem to use this mode if this is a good enough resolution...
 
sorry for this late answer
 
it should be possible to monitor two motors because the the EK-TM4C123 has two QEI-moduls. You should use the QEI-Pins to use QEI, so you have no big choice...

For those that don't follow the 43oh Blog:
 
@@Fmilburn published a great write-up about how to use EnergyTrace to measure and improve power consumption and battery life of an Energia sketch. The article includes a nice demonstration of the effectiveness of sleep() vs. delay().
http://43oh.com/2015/09/how-to-measure-an-energia-applications-power-usage-with-energytrace/
 
He also shows how an EnergyTrace compatible LaunchPad (e.g. FR5969) can be used to measure power consumption of an older LaunchPad (e.g. G2553). This probably works for standalone projects as well.

 

Updated version of the library attached. Main changes are:
Configuration option allows the Watch-Dog Timer to be used for the RTC instead of TimerA. This also requires replacements for the functions in wiring.c. A side effect caused by limitations of the 430 hardware is that delay, millis and micros only have a resolution of 1.9mS. Added helper functions to convert the hmsDMY time into UnixTime format, return day-of-week, etc. Added an alarm class. Improved documentation. RTCplus.zip

I did some more work on this library and started a new thread for it.
http://forum.43oh.com/topic/8870-hardware-counter-library-for-msp430

Lol! That is pretty amazing. Suddenly my epic fails in PCB design seem small in comparison...
 
Sent from my Galaxy Note II with Tapatalk
 
 

Hi @@altineller
 
I tried to reproduce your problem on my TM4C123G LaunchPad.  I hooked up the following with a 6V battery (reads 5.9 on my meter).  Is this your circuit?
 
 

 
If so, I was able to get the expected readings using this sketch:
void setup() { Serial.begin(9600); Serial.println("Starting..."); } void loop() { float rawReading; rawReading = analogRead(28); Serial.print(" Raw Reading = "); Serial.print(rawReading); float Voltage; // NOTE: 3.3 is used for conversion since we are // using the default internal voltage reference Voltage = 3.3 * rawReading / 4095.0; Serial.print(" Voltage = "); Serial.println(Voltage); } I did not get different readings when I put my meter across as you reported.  Do you have your circuit grounded to the LaunchPad?  Also, did you convert in your sketch using 3.3V or 6V?  Using 6V would give roughly the number you reported.
 
Hope this helps.

Hello,
 
I managed to port the MPU9150Lib at https://github.com/richards-tech/MPU9150Lib to Energia.
 
I had to make few changes in defines in dmp code, and the provided CalLib, and now it compiles for MSP430G2553, MSP430F5xx, Stellaris Launchpad, and the Tiva-C series (TM4C123) launchpad. CalLib writes to either flash or eeprom depending on architecture.
 
It has failed for MSP430G2553, due to code size. It compiles for MSP430F5xx although I dont have a board yet to test. I have not tested the stellaris launchpad but I suspect it works, it does WORK on the Tiva-C series launchpad.
 
Here is the picture of the setup:
 

 
On one side I have an arduino nano v3 connected to a MPU9150 module (The cheap GY 9150) and on the other side I have a Tiva-C series launchpad with a sensorhub booster pack. (that contains a MPU9150 as well) and I have hooked up a usbee logic analyzer to i2c (sda, scl) of both mcus
 
For some reason, it is running slow on the TM4C123 then the arduino. It is supposed to work much faster on the Tiva-C launchpad, but on the contrary it does not. I measured mpu.read() times, and on Energia it wont go less then 50ms, where on arduino I have tested up to 200hz sensor read rates with no problem.
 
Here are two screenshots from the logic analyzer:
 

 

 
The top two signals are from arduino sda scl, the bottom is the sda(3) scl(3) of the Tiva-C
 
The MPU9150 is configured to update at 20Hz for both systems. however the i2c bus activity seems quite different. 
 
I am thinking there might be a problem with the i2c speed on Energia, or that it works different.
 
And finally here is my code:
 
MPU9150LibEnergia.rar
 
I will be posting all the code on github later - for now I made a zip file for all.
 
Best Regards,
Can

Hello altineller,
I've tested your code by hooking up a 9150 module (similar to the one you connected to the Nano) to Tiva C. I had to add Wire.setModule(1) to the setup function of the Energia9150.ino file and then it worked, but as you said quite slowly.
The slow speed is probably related to the problem addressed by this pull request for the energia wire library: https://github.com/energia/Energia/pull/343
In the energia-0101E0012/hardware/lm4f/libraries/Wire/Wire.cpp file the TwoWire::getRxData and TwoWire::sendTxData both have a delay of 1ms build in. This is probably the cause of the delay you are seeing in the SCL of the Tiva. Moreover, the TwoWire::begin method limits the I2C speed to 100kbps.
I've tested your code also with a modified Wire.cpp file, forcing the speed to 400kbps and removing the delay(1) statements from the getRxData and sendTxData methods. This improved speed a lot, but wasn't stable (communictation with the module stopped at random times). To get it stable I had to add 10micro second delays (delayMicroseconds(10)) to the getRxData and sendTxData methods instead of the delay(1). With this change I could increase the MPU_UPDATA_RATE to 200 and the MAG_UPDATE_RATE to 100, resulting in an average sample time of less then 6ms.

I don't know if there is an equivalent, then again I didn't know those existed in the first place.
I've been learning the direct port manipulation methods.
 
On the speed end of things, I tested a G2553 at 16MHz with my scope.
 
This sketch:
void setup() {   pinMode(P1_0,OUTPUT); } void loop() {   digitalWrite(P1_0,HIGH);   digitalWrite(P1_0,LOW); } Toggles the pin at ~119kHz, 8.39

@@Frans I have tested your fix and it works. Making this faster than the arduino. (with a nano i was able to go 120hz max)
 
I have not seen any problems or glitches at 200hz.
 
Here are two graphs I made, one at 80hz, other at 200hz averaging 6ms per read.
 
Look at those periodic spikes in the 200hz test. It is probably some fifo problem.
 
However it works now, and I will soon make this into a library and post it on github.
 
Best regards,
C.A.
 
 

Hello altineller,
I've tested your code by hooking up a 9150 module (similar to the one you connected to the Nano) to Tiva C. I had to add Wire.setModule(1) to the setup function of the Energia9150.ino file and then it worked, but as you said quite slowly.
The slow speed is probably related to the problem addressed by this pull request for the energia wire library: https://github.com/e...nergia/pull/343
In the energia-0101E0012/hardware/lm4f/libraries/Wire/Wire.cpp file the TwoWire::getRxData and TwoWire::sendTxData both have a delay of 1ms build in. This is probably the cause of the delay you are seeing in the SCL of the Tiva. Moreover, the TwoWire::begin method limits the I2C speed to 100kbps.
I've tested your code also with a modified Wire.cpp file, forcing the speed to 400kbps and removing the delay(1) statements from the getRxData and sendTxData methods. This improved speed a lot, but wasn't stable (communictation with the module stopped at random times). To get it stable I had to add 10micro second delays (delayMicroseconds(10)) to the getRxData and sendTxData methods instead of the delay(1). With this change I could increase the MPU_UPDATA_RATE to 200 and the MAG_UPDATE_RATE to 100, resulting in an average sample time of less then 6ms.

Just have a look at the datasheet of the LaunchPad Stellaris - Tiva C. When you remove the shunts, I²C is no longer redirected to pins 14 and 15.
 
I²C on pins 14 and 15 complies with the old BoosterPack standard, where MSP430 MCUs bring SPI and I²C to those pins. So main benefit is you use SPI on pins 14 and 15 without sacrificing an I²C port on pins 23 and 24. Please note this is only valid for the LaunchPad Stellaris LM4F120 - Tiva C TM4C123.
 
On today's standard for BoosterPacks, I²C is on pins 9 and 10.

There's a trick with I2C port 3 on the LaunchPads LM4F120 and TM4C123.
 

 
Just remove R9 and R10.

twi.h has a speed setting early in it.
It looks like you might be able to define "TWI_FREQ" in your code before you include Wire.h (which includes twi.h, which checks to see if TWI_FREQ is defined and if not, defines it) and set the speed that way.
twi.h kicks off with figuring out what sort of serial interface the MCU has, then hits the speed section:
#ifndef TWI_FREQ #define TWI_FREQ 100000L #endif My guess is that it's in Hz, 100kHz seems like a reasonable default speed.
Will it work faster? I have no idea.

Your format string in sprintf should use double quotes.
 
"%%.%dX"

2.2k is a reasonable value for 3.3V IIC. Both SDA and SCL require resistors because they are both open drain (pulled low only). The SCL line is open drain to allow a slave to do clock stretching - a rarely used feature.

YES. I managed to use the built-in MPU, and tested the measurements with a test jig. (a wooden box that is aligned north) so i can put the sensor on all sides.
 
DMP is FASTER.
 
DMP is much better then the DCM alg. in razor imu and similar.
 
That is why i ported this lib, since it works with DMP.

YES. I managed to use the built-in MPU, and tested the measurements with a test jig. (a wooden box that is aligned north) so i can put the sensor on all sides.
 
DMP is FASTER.
 
DMP is much better then the DCM alg. in razor imu and similar.
 
That is why i ported this lib, since it works with DMP.