Stellaris Cortex M4F (preorder for september, 4.99$)

aimatt · Post by **aimatt** » Wed Feb 13, 2013 6:53 pm

Agreed.

gompf-2 · Post by **gompf-2** » Wed Feb 13, 2013 8:19 pm

timecop wrote:oh comeon.
I use leadfree on everything and have zero issues. MicroUSB connectors are just shit, plain and simple. Especially SMD ones.
I've never had a problem with through-hole USB Mini-B coming off a board (without taking half the board with it).

Regarding to the mechanical construction I agree, too. The only force holding them in place is the glue between copper layer and substrate board.
But what I´ve observed sometimes since leadfree is that the housings solder joints of big parts were more or less cold because reflow temperature wasn´t reached. E.g. crappy 2,5" USB-HDD were the MicroUSB came of with the 4 signal/power pads but the copper for the housing was left on the PCB, just the solder broke.
Also we´ve some problems with the long term use of quite big PCBs (50cmx30cm) with precision analog circuites and many big connectors. The connectors need a quite big force to unplug/plug so a little bending of the boards is unavoidable even if you try to support the backside. The newer leadfree boards fail more often due to cracked joints, I was told because the new solder is less ductile/tolerant for mechanical stress.
For normal stuff it shoudn´t make a big difference, in my eyes this leadfree action was just not worth the effort as lead is easy to recycle from electronics if disposed properly.
Just my opinion, no need to argue. The naze I got is soldered perfrectly and still in good condition

aimatt wrote:Gompf, if I sent you a PM with my eagle file could I get some pointers from you?

Mayby during next week, I still have to finish some other things and want to try the import of vdjc code to ccs over the weekend. But in principle yes.

aBUGSworstnightmare · Post by **aBUGSworstnightmare** » Tue Feb 19, 2013 1:50 pm

Hi,

pulled the sources from github, compiled them using Crossworks for ARM 2.3.0 (didn't alter anything so far!)

Code seems to run since I get data from the ACC. Update in the GUI is way too slow. ACC gives clean data; no data from GYRO/MAG (not a real prolem since I use a MPU-9150 --> no code to deal with it) and strange BARO data.

: C3ii INS Booster Pack with default source code

How to activate the I2C polling driver? Could'nt locate a #define on first view!

aBUGSworstnightmare

gompf-2 · Post by **gompf-2** » Tue Feb 19, 2013 4:17 pm

Hi,
nothing new about baseflight but I did some tests with Energia: newer file next post
It´s an ugly try of a cut down port of MW2.1 but at least it shows that aBUGSworstnightmare´s driver is basically working. PPM SUM RX works nearly out of the box, I altered the drivers for ITG3200 and ADXL345 and have graphs/quick response in Mw-WinGUI2.1 (I had to change to single register read and ugly operations due to variable deklaration conflicts), MultiWiiConf works not so nice. I still have some problems with the serial protocol, I think regarding to seralize16/32 and the use of serial.write. I used the Energia serial API, "8bit" tranfers work fine, e.g. calib acc and 8bit values read/write, 16/32bit values get corrupted. EE2/Mixtable also need to be completed. Motor output could work via analog.write as this uses the HW-Timers on Energia or the known 24bitPPM-driver routine.
Must be still some overflow/range issus in the IMU section...
http://www.file-upload.net/download-7232941/chk.jpg.html

Edit: Energia seems to have problems with micros() overflow as the PPM SUM RX routine stops after some time. I tracked it down to wiring.h in the lmf4 core folder, change micros() to use SysTick (like in baseflight) instead of WT4 and changed the startup to initialise the interrupt, fine now:
edit2: removed due to copyright

Code: Select all

 *   wiring.c
 *
 *   Arduino core files for MSP430
 *      Copyright (c) 2012 Robert Wessels. All right reserved.

Loop contains some serial.print for debugging, axis-pids pitch/roll seems ok, yaw not, also problems with passing rc-commands to imu (arming/disarming/rc-commands are fine)
Edit3:aBUGSworstnightmare, I2CReadData/burstmode works also fine, was a combination of stupidity (pointers...) and undefined variable conversion (e.g.(int16_t)((rawADC[1]<<8) | rawADC[0]));

gompf-2 · Post by **gompf-2** » Thu Feb 21, 2013 1:35 am

Ok, got it so far...
MultiWii_2_1_energia_mod_systick_serial.zip

Problem with the serial was clear after I found this comment in energia´s Hardwareserial.c for lm4f:

Code: Select all

// If the character to the UART is \n, then add a \r before it so that
    // \n is translated to \n\r in the output.

This of course messed up the frames.
Overflow/range issus in the IMU section was my fault as I commented out readEEPROM() completly so the IMU parameters were mostly 0. I thought checkFirstTime() does the trick but lookuptables need to be processed by readEEPROM().
What remains now is the block mode eeprom (4 bytes per access) of the lm4f. I did a first try by filling up the conf. struct with dummy bytes and use the lib function, but I´m to stupid atm to transfer a pointer to the start of conf as uint32_t to EEPROMRead() of the driverlib. The Energia lib is byte oriented and stores 1 byte payload per block of 4, this would reduce available eeprom to 512 bytes and I also don´t know how to address a single byte in a struct of elements of variable length :oops:

To have a look you have to
- comment some lines in energia´s Hardwareserial.c

Code: Select all

   
    /*if(c == '\n')
    {
        while (TX_BUFFER_FULL);
        txBuffer[txWriteIndex] = '\r';
   txWriteIndex = (txWriteIndex + 1) % SERIAL_BUFFER_SIZE;
        numTransmit ++;
    }*/

- copy the new wiring.c to the lm4f core folder (nothing left from Robert Wessels, now timecops systick code from baseflight)
- add

Code: Select all

extern void SysTick_Handler(void);

to Energia.h and startup_gcc.c
- alter vectortable in startup_gcc.c

Code: Select all

SysTick_Handler,                        // The SysTick handler

Edit: Some bugs left in the IMU section, eg in void getEstimatedAttitude()

Code: Select all

  static uint32_t previousT;  //was uint16_t
  uint32_t currentT = micros();
  float scale, deltaGyroAngle[3];

Compiler seems to bee more picky with implicite type conversions than arduino. E.g. the gyro calculation had to be changed to

Code: Select all

GYRO_ORIENTATION( ((int16_t)(rawADC[0]<<8) | rawADC[1])/(int16_t)4 , // range: +/- 8192; +/- 2000 deg/sec
                    ((int16_t)(rawADC[2]<<8) | rawADC[3])/(int16_t)4 ,
                    ((int16_t)(rawADC[4]<<8) | rawADC[5])/(int16_t)4 );

I´ll now try to get the eeprom working and then import timecops MW-code (e.g. rotateV() and _atan2() work and add ~10µs looptime) to get something like a config.h based version of baseflight as I don´t understand the dynamik config/cli stuff.

Edit2: workaround for block mode:

Code: Select all

//eeprom_read_block((void*)&conf, (void*)0, sizeof(conf));
  //**** ugly hack for energia EEPROM lib
  uint8_t bytecount = sizeof(conf);
  uint8_t EE2_buff[sizeof(conf)];
  
  for(i=0;i<bytecount;i++) {
    EE2_buff[i]=EEPROM.read(i*4);
  }
  memcpy (&conf, &EE2_buff, sizeof(conf) );
  //***
.
.
.
//eeprom_write_block((const void*)&conf, (void*)0, sizeof(conf));
  //**** ugly hack for energia EEPROM lib
  uint8_t bytecount = sizeof(conf);
  uint8_t EE2_buff[sizeof(conf)];
  memcpy (&EE2_buff, &conf, sizeof(conf) );
  for(uint8_t i=0;i<bytecount;i++) {
    EEPROM.write((i*4),EE2_buff[i]);
  }
  //***

MultiWii_2_1_energia_b01.zip

gompf-2 · Post by **gompf-2** » Sun Feb 24, 2013 4:49 pm

Last problem....
Energia´s analogWrite doesn´t work correctly if called with a delay<100ms. At first I thought I broke something due to changes in wiring.c/IRQs but it´s the same with a virgin package. Have to implement the 24bit-pwm code to energia now....

crashlander · Post by **crashlander** » Mon Feb 25, 2013 7:34 pm

@gompf-2: So if I understand correctly time measuring functions in Energia are broken and your/TC's correction fixes it?!
I have problems with simple delay() and/or millis() it only works with Micro's.
From your fix I do not understand what you mean by "- copy the new wiring.c to the lm4f" what is the new wiring.c (from GIT?)?

Best Regards
Andrej

Edit:I found wiring.c in the first zip.

gompf-2 · Post by **gompf-2** » Mon Feb 25, 2013 8:58 pm

Hi crashlander,
yes it´s a known overflow problem: https://github.com/energia/Energia/issues/154
As I also wanted to keep WT4 free I adapted Timecops way of timing by SysTick. The new wiring.h is in the "MultiWii_2_1_energia_mod_systick_serial.zip", you also have to patch startup_gcc.c and energia.h to make the SysTick_Handler known, I still have to ask the guys from Energia whats their mind about making patched core files available as there is a copyright in the header. I just did it the qnd-way so there are problems now when uploading "normal code" (because SysTick_Handler is not known bei genuine Energia so missing vector if not used, upload seems to not work any more but after a hardreset it´s there). With my MultiWii_2_1_energia code/code using SysTick_Handler it´s fine as everthing needed is there.
Today I had a MPU6050 in the box, so I´m now able to test with modern hardware, unfortunatly it´s 5 days to weekend for me and thats sunday only because I´ve training on saturday... (firefighters: rope down from roof, snowing here, will be great fun).
I also opened an issue for the analogWrite, problem is that with every value change Energy reloads periode/restarts time -> kind of one shot behavior when function is called to fast (delay<100), first try to implement the other stuff was not successfull. I just rechecked this with the CCS-PWM code, if you only change the match value it´s fine. The value present in the register at timer overflow/next cycle start is used, inbetween you can write what you want but baseline stays stable.
Regards,
gompf

vdjc · Post by **vdjc** » Tue Feb 26, 2013 8:42 am

aBUGSworstnightmare wrote:How to activate the I2C polling driver? Could'nt locate a #define on first view!

Sorry for the late reply (holidays!). It's in stellaris\board-stellaris.h @line 66 :
#define USE_I2C_POOLING
But it's defined by default...

aBUGSworstnightmare · Post by **aBUGSworstnightmare** » Tue Feb 26, 2013 7:09 pm

Hi vdjc,

no problem! O.K.! Got it!
I think I will write a new I2C driver with interrupts.

aBUGSworstnightmare

aBUGSworstnightmare · Post by **aBUGSworstnightmare** » Tue Feb 26, 2013 7:33 pm

gompf-2 wrote:I´ll now try to get the eeprom working and then import timecops MW-code (e.g. rotateV() and _atan2() work and add ~10µs looptime) to get something like a config.h based version of baseflight as I don´t understand the dynamik config/cli stuff.

Hi gompf-2,

when working with AVR MCUs I once wanted to have access to my EEPROM data by using symbolic names. I made a second project for setting up the EEPROM data and introducing the new data type for the structure in the EEPROM.

The 'main' project than also used this data type and I could access my EEPROM by using the symbolic name, without needing to care about the actual address of the data in the EEPROM.

I did this for an ATMEGA128 RC5-decoder. Here's the code snippet. I will try to port this to Stellaris later (using CCS and not Energia! I want to have full access to all registers and have full debug control --> I will not limit myself by using Energia).

aBUGSworstnightmare

Code: Select all

/*  Accessing EEPROM by variable names
    
    File name: eeprom_rc5.h
    
    Contains variable definitions
    
    Revision: 1.0
*/

#define EEPROMADR(x) (unsigned int) (&((typeEEPROMstruct *)0x0000)->x)

typedef struct
{
  unsigned char ucosccal_value;
  
  unsigned char uceesysaddress;
}typeEEPROMstruct;

The header with the data type definition

Code: Select all

/*  Accessing EEPROM by variable names
    
    Initialization Data for EEPROM
    
    File name: eeprominit_rc5.c
    
    Revision: 1.0
*/


#include <eeprom_rc5.h>
#pragma memory=constseg(EEPROM)

const typeEEPROMstruct __EEPROMinitializationData=
{
  0x00,                                   /* never_use_this_address OSCCAL-value */
    
  0xff,                                   // sysaddress
};

The code for the EEPROM-Project, only containing the initialization data.

Code: Select all

      _SECEEWRITE((EEPROMADR(uceesysaddress)), ucsysaddress);
                                            // store sysaddress in EEPROM      
 
    }
    
    _SEI();                                 // enable global interrupts
    _SECEEREAD(ucsysaddress, (EEPROMADR(uceesysaddress)));  
                                            // read sysaddress from EEPROM

Using the variable in the application. to complete the code, here are the macros from the example above.

Code: Select all


/* Set bit in I/O register - command is resulting in SBI assembly instruction */
#define SETBIT(ADDRESS,BIT) (ADDRESS |= (1<<BIT))

/* Clear bit in I/O regsiter - command is resulting in CBI assembly instruction */
#define CLEARBIT(ADDRESS,BIT)  (ADDRESS &= ~(1<<BIT))

/* Test bit in I/O register */
#define TESTBIT(ADDRESS,BIT)  (ADDRESS & (1<<BIT))
/* Secure EEPROM read macro */
/* Read data in EEPROM address uiAddress into variable cValue */
#define _SECEEREAD(cValue,uiAddress)\
{\
    char c = SREG;        /* Need local variable to hold status register */ \
    while(EECR & 0x02)    /* Check if EEPROM write in progress           */ \
        ;                 /* While it is -> do nothing                   */ \
    _CLI();               /* Disable interrupts                          */ \
    EEAR = (uiAddress);   /* Set up EEPROM address registers             */ \
    SETBIT(EECR,EERE);    /* Set EEPROM read bit                         */ \
    (cValue) = EEDR;     /* Read EEPROM data register into cValue       */ \
    SREG = c;             /* restore status register                     */ \
}

/* Secure EEPROM write macro */
/* Write data in cValue into EEPROM address uiAddress */
#define _SECEEWRITE(uiAddress,cValue)\
{\
   char c = SREG;         /* Need local variable to hold status register */ \
   while(EECR & 0x02)     /* Check if EEPROM write in progress           */ \
        ;                 /* While it is -> do nothing                   */ \
   _CLI();                /* Disable interrupts                          */ \
   EEAR = (uiAddress);    /* Set up EEPROM address registers             */ \
   EEDR = (cValue);       /* Set up EEPROM data register                 */ \
   SETBIT(EECR,EEMWE);    /* Set master EEPROM write bit                 */ \
   SETBIT(EECR,EEWE);     /* Set EEPROM write bit                        */ \
   SREG = c;              /* restore status register                     */ \
}

aimatt · Post by **aimatt** » Fri Mar 08, 2013 8:12 pm

I don't want to burn much more money on prototypes. What do you guys think if I were to just solder on a GY-86 or 87 10DOF onto the PCBS instead of putting the sensors on directly myself? What kind of other goodies would be nice? Top mounted reset button? SR-04 sonar with cable? Buzzer? Mounting holes?

aBUGSworstnightmare · Post by **aBUGSworstnightmare** » Mon Mar 11, 2013 8:52 am

Hi aimatt,

use a GY-86 because of the MS5611 Baro; is way better than the BMP180.
Don't miss the mounting holes!

aBUGSworstnightmare

aimatt · Post by **aimatt** » Wed Mar 13, 2013 7:13 pm

How does this look?

5cm^2

aBUGSworstnightmare · Thu Mar 14, 2013 12:29 pm

Hi aimatt,

looks like you intend to mount the Launchpad on-top of your IMU booster pack, right? So:

- How will you access the Motor/Servo I/O? Right angled 3-row pinheader mounted on the bottom side of the booster? Keep an eye on the stacking hight!
- LEDs (PF1-PF3) will covered by the Launchpad (when the launchpads sits on-top)--> you can keep using the RGB LED on the launchpad
- maybe you should optimize your routing a little bit; ecpecially the I2C bus were your GY-86 connects to.

aBUGSworstnightmare

aBUGSworstnightmare · Thu Mar 14, 2013 12:39 pm

Hi,

found this on the www: http://www.youtube.com/watch?v=__QhktY1LqY

The driver sourcecode (https://github.com/kroesche/stellaris_drivers) is for use with the Stellaris Launchpad. Able to control 12 servos (ESC).

I think it needs to be modified a little to suit our MultiWii needs but it's a perfect starting point.

aBUGSworstnightmare

aimatt · Post by **aimatt** » Thu Mar 14, 2013 3:11 pm

As of right now, it's mounted on top. Mounting it on the bottom would be good to actually get access to the mounting holes, but does introduce those other problems you mentioned. I guess if I make it bottom mounted, we could use right angle headers and offset the boosterpack headers so the LEDs stick out of the bottom.

I will definitely clean up routing, it's just a quick autoroute to have a look.

As of right now, I'm still thinking of keeping the booster on top, because I feel putting it on the bottom will be hacky.

Maybe I can source some kind of mounting adapter to go around the launchpad that I can include with the board.

aimatt · Post by **aimatt** » Thu Mar 21, 2013 4:20 pm

aBUGSworstnightmare wrote:Hi,

found this on the www: http://www.youtube.com/watch?v=__QhktY1LqY

The driver sourcecode (https://github.com/kroesche/stellaris_drivers) is for use with the Stellaris Launchpad. Able to control 12 servos (ESC).

I think it needs to be modified a little to suit our MultiWii needs but it's a perfect starting point.

aBUGSworstnightmare

That does look pretty nice. Now I'm think I should copy his idea and have the booster pack stick out the sides to expose the pins and have the LEDs stick out the bottom. Sound good?

gompf-2 · Post by **gompf-2** » Fri Mar 22, 2013 2:01 pm

The driver problem itself is mainly already solved, we had the timer+extender version from vdjc/me and energias variable version (timer,timer+extender,wtimer) + many other examples. I2C drivers are also available, we just need "the glue"...
I can only provide some prove of concept with Energia:
MW21_Energia-core-lm4f_mod.zip
For Energia I used latest core files from git (official multi serial/micros() mods) and just modified analogWrite.c to get rid of the glitches with fast calls(https://github.com/energia/Energia/issues/203) and HardwareSerial.cpp to not autoadd \r if \n is in the datastream.
I now have to convert this to MW2.2 and check multi serial/gps and other sensors as my MP6050 etc arrived. And of course refine the ugly qnd-code (e.g. full resolution instead div8 during PWM, I2C-error detection/handling) before the first flight test.

aimatt · Post by **aimatt** » Fri Mar 22, 2013 10:04 pm

I updated the images above for the new design where the board is on the bottom and the launchpad stacks on top. How does it look? Questions, suggestions? Shall I send over the PCB order?

aBUGSworstnightmare · Post by **aBUGSworstnightmare** » Mon Mar 25, 2013 7:36 am

Hi,

looking good so far (as I can tell from the pics). Be shure to add some more vias to connect your ground planes on TOP and BOTTOM. Changing your routing strategy a little bit would increase the ground layers too.

aBUGSworstnightmare

aimatt · Post by **aimatt** » Mon Mar 25, 2013 6:06 pm

Thanks much. I will take your advice and then send out the gerbers to the fab.

aimatt · Post by **aimatt** » Mon Mar 25, 2013 9:55 pm

Manually routed with some GND vias

gompf-2 · Post by **gompf-2** » Sat Apr 06, 2013 9:53 am

@ aBUGSworstnightmare:
Hi,
did you check MPU6050/9050 readout with your drivers? I used your routines with ITG3200/ADXL345 and everything went fine. When I try to readout MPU6050 via 6-Byte burst read Accel is fine, Gyro doesn´t work, but works with alternative I2C-drivers. I tripple checked registers etc. and used the same functions, maybe it´s an Energia issue.
Now I´m missing debug option in Energia ;-)

@aimatt:
I´m missing +5V or +3,3V power connection to the gy-86!?

aimatt · Post by **aimatt** » Thu Apr 11, 2013 5:02 pm

gompf-2 wrote:I´m missing +5V or +3,3V power connection to the gy-86!?

sonafabitch. hahaha. I guess I'll have a patch wire for the first batch.

aBUGSworstnightmare · Fri Apr 12, 2013 11:46 am

Hi,

don't know if anybody noticed so far: Stellaris died and Tiva is born!

TI changed the name for the M4F products from Stellaris something to Tiva something (http://www.ti.com/lsds/ti/microcontroll ... rview.page).

The good news for us (multiwii enthusiasts): There will be a new Launchpad - the Tiva C Series EK-TM4C123G LaunchPad.
It features a Tiva™ TM4C123GH6PM Microcontroller which is identical to LM4F230H5QR --> hardware PWM

and no more worries about dealing with the Timer PWMs.

Don't know when it will be availabe! Stay tunes!

Rgds
aBUGSworstnightmare

aimatt · Post by **aimatt** » Wed Apr 17, 2013 6:17 pm

That's great news. That was the big grumble when it was released.

aBUGSworstnightmare · Fri Apr 19, 2013 10:01 am

Hi there,
looks like the guys at TI also liked my idea (or at least had a similiar one) of the C3ii INS (viewtopic.php?f=22&t=2376&start=40#p27997) Booster Pack: http://www.ti.com/tool/boostxl-senshub

TI now offers a Sensor Hub Booster Pack BOOSTXL-SENSHUB which features the same senors (Invensense MPU-9150 and Bosch Sensortec BMP180) and - in addition - adds some more. They also added the EM-connector which allows to connect a GPS or WiFi to the board.

The BOOSTXL-SENSHUB (http://www.ti.com/tool/boostxl-senshub) sells for $49.99 ans is (at the time of writing) available at the TI eStore. Get one until stock lasts!

: BOOSTXL-SENSHUB

aBUGSworstnightmare

P.S. Too bad that I couldn't participate in the last TI Booster Pack design challange!

timecop · Post by **timecop** » Fri Apr 19, 2013 10:21 am

Hardware is really easy to do, as most in this thread probably noticed.

aBUGSworstnightmare · Fri Apr 19, 2013 11:30 am

Hi Timecop,

yes, you're right! HW is easy!

But, since they include a Sensor Libray with the board (which deals i.e. with MPU-6050, MPU-9150, BMP180, AK8963, AK8975, ..), a Vector Math Module and a Nine-Axis Sensor Fusion with the MPU-9150 and Complimentary-Filtered DCM (Direct Cosine Matrix) it's worth a try.

Maybe you can port some of the code to Baseflight too

.
aBUGSworstnightmare

veqtor · Post by **veqtor** » Fri Apr 26, 2013 12:45 pm

aBUGSworstnightmare wrote:Hi there,
looks like the guys at TI also liked my idea (or at least had a similiar one) of the C3ii INS (viewtopic.php?f=22&t=2376&start=40#p27997) Booster Pack: http://www.ti.com/tool/boostxl-senshub

TI now offers a Sensor Hub Booster Pack BOOSTXL-SENSHUB which features the same senors (Invensense MPU-9150 and Bosch Sensortec BMP180) and - in addition - adds some more. They also added the EM-connector which allows to connect a GPS or WiFi to the board.

The BOOSTXL-SENSHUB (http://www.ti.com/tool/boostxl-senshub) sells for $49.99 ans is (at the time of writing) available at the TI eStore. Get one until stock lasts!

boostxl-senshub_boostxl-senshub.jpg

aBUGSworstnightmare

P.S. Too bad that I couldn't participate in the last TI Booster Pack design challange!

Would be interesting to know what pins are used up by the sensorhub... Would be nice to use the aimatt board w. the sensorhub...

aBUGSworstnightmare · Post by **aBUGSworstnightmare** » Fri Apr 26, 2013 9:05 pm

Visit the BOOST-SENSHUB website; the hardware Users Manual is online now.
Should be no problem to use it with the 'aimat' board (which will only act as a carrier board then).

Mine is on it's way! Will be interresting to compare against my C3ii.
aBUGSworstnightmare

gompf-2 · Post by **gompf-2** » Tue Apr 30, 2013 8:52 pm

Hi,

timecop wrote:Hardware is really easy to do, as most in this thread probably noticed.

LOL, YES, hit ;-)

As my platform is EOL and it´s summer again I´ll prefer to buy another naze for the price of the BOOST-SENSHUB (with vintage baro). I have an Energia/MW2.1 something "working" but woudn´t trust it to launch it near my own house/children (yes, missing programming knowledge on my side and debugging option in Energia).

The Stellaris for 4.99€ was kind of a blockbuster in my eyes, a ~15bucks MCU board is just another one in the shelf, even with "HW PWM" which was a solveable problem even for me. We don´t need a pwm module able of multi vector commutation at this state, the timer module of Stellaris was imho enough.

Price of the MPU9150 is 25€ if I order a single one as privat person, including PP, the BMP180 is peanuts, I didn´t check the rest because imho not useful for us ... I can´t see an advantage over existing solutions any more, even less when I take the price of a TIVA board needed to drive this into account.

Regards,
Gompf

aimatt · Post by **aimatt** » Fri May 10, 2013 5:29 am

I made one of my boards (with the obvious jumper wire to get 3v3 to the IMU. I ran the Stellaris Baseflight on there and I'm getting readings, so that's good. Anyone wanna buy one? I'll order the corrected PCBs in the coming weeks.

https://www.dropbox.com/s/o0ywe2s44zqh7 ... .04.55.jpg
https://www.dropbox.com/s/236j5djf3m892 ... .05.35.jpg
https://www.dropbox.com/s/uvt61mfjo78we ... .06.11.jpg
https://www.dropbox.com/s/e6yvkr3b6pnf0 ... .07.27.jpg
https://www.dropbox.com/s/g2i5qp9c1rb6s ... .13.44.jpg
https://www.dropbox.com/s/5vc7unph5elq6 ... .16.58.jpg

gregio · Post by **gregio** » Tue May 21, 2013 11:38 pm

how much is pcb cost?

aimatt · Post by **aimatt** » Wed May 22, 2013 7:03 pm

gregio wrote:how much is pcb cost?

It costs me like 50 USD for 10

tovrin · Post by **tovrin** » Thu Jun 20, 2013 4:46 pm

aimatt, i am late on this post, did you ever order the boards, how can i buy one from you?

raulmd · Post by **raulmd** » Mon Sep 09, 2013 2:46 pm

Hi all.
This thread looks dead but i hope it is just beause of summer hollidays.
I have pursached my Stellaris M4F little more expensive than 4.99$ but is worth. I have experience with 8 and 32 bits Microchip PIC microcontrolles and wanted to give a try to ARM together with the fact i have plans to build a Quadcopter.

Said that. Now the important.

After reading the thread i cant find the state of the code for Stellaris.

Just the link to vdjc baseflight but ir looks like is fot STM32 not for our board.
https://github.com/vdjc/baseflight

Yes, i am lost now, but i hope i can understan it better in the future.

timecop · Post by **timecop** » Mon Sep 09, 2013 3:56 pm

It seems there's stellaris-related stuff under the stellaris/ dir?
https://github.com/vdjc/baseflight/tree ... /stellaris
I tried to make the drivers abstracted from the rest of the code, so technically if I did it right, all thats needed is replacing drv_* with stellaris specific versions and the rest should work. But things are not always 100% like that, so there's some system specific stuff here and there.

Oh, and you're not wrong - this thread is about as dead as M4F - TI killed that product line couple months ago, and its called "TiVa" or something now.

raulmd · Post by **raulmd** » Tue Sep 10, 2013 1:16 am

Thanks for the answer.
So I bought a deprecated piece of electronics :oops:

yeeeha!
I will try to contact with TI to cancel my order.
And move to Naze32 which seems to be he most active.
Thanks again.

actron · Post by **actron** » Mon May 26, 2014 12:43 pm

Hi,
i'm looking for the code https://github.com/vdjc/baseflight/tree/upstream/stellaris but it Looks like that it is any longer on github. Does someone have this code as a zip file.
Because I want it use/test on the new tiva c launchpad.

Thanks