What are you doing right now..?

[bluehash 1,581]

@@zeke Is that an MSP430 footprint?

[yosh 121]

Playing around with Diptrace ... Really nice!!! So much easier to learn and use compared to Eagle and KiCad. Next step: porting my 'reference' design (my 35x35 mm PCB layout) from fritzing to Diptrace.

[cubeberg 540]

finally broke out my 5529LP and CC3000 boosterpack - working on a software build monitor for my new job.  Got it to successfully connect to the wifi!

[spirilis 1,265]

Just got a very basic IRC client working on the TM4C129 LaunchPad, just logs in, joins a channel & says hello.

Tried to work out the functional framework so it can be extended... eventually as a fully-featured bot.  IRC-controlled home anyone?

[bluehash 1,581]

Just got a very basic IRC client working on the TM4C129 LaunchPad, just logs in, joins a channel & says hello.

Tried to work out the functional framework so it can be extended... eventually as a fully-featured bot.  IRC-controlled home anyone?

aiyeee. Nice! I'll wait for the writeup.

[greeeg 460]

Just placed a digikey order for ledRing parts. Also writing/testing code to run on the ring controller board.

[Fred 453]

Just restarting a Stellaris LP project that I'd put on the back burner, so decided to use Tiva LP instead. Just remembering how many silly little hidden things you need to sort before even getting blinky going! (Ensuring the part is defined, etc.) MSP430 seems so much easier.

 

Also ordered some 0603 parts (for RobG's nanoPad). I've only just got used to working with 0805!

[RobG 1,892]

Well, I was going to finish my 40W RGBW spotlight this weekend, but the LEDs I got are a total cr...

So instead, I am writing some software for my Kinetis Freestyle I board.

 

[pabigot 355]

Got a common build infrastructure for Tiva TM4C123, TM4C129, and EFM32TG/EFM32GG working, based on gcc-arm and the CMSIS startup and linker scripts.  Not convinced it was worth the effort, yet.

[mbeals 74]

Firmware for the radio sensor packs is just about done.  I spent the weekend wrapping up the state machine and settling how I want to handle the handshaking with the base station to start/stop the data stream.  It's working great but something seems to be blocking incoming traffic on the radio while it is transmitting data out.  I think there might not be enough of a gap between transmissions for the radio to rx the command packets but I haven't been able to confirm.   The control board already aggregates data from the sensors and then transmits it all at once, so I'm hoping upping the radio baud rate will leave enough dead time to allow a few bytes to sneak in.  If all else fails, I will just add a command to select how long to transmit data, and use the heartbeat timer I already have in place to kill it.

[zeke 693]

@@zeke Is that an MSP430 footprint?

There is no MSP430 on this board.

 

The green object is the RF200 radio module. It has an ATMEGA128RFA1 inside it running SNAPpy - a subset of Python.

[bluehash 1,581]

Got a common build infrastructure for Tiva TM4C123, TM4C129, and EFM32TG/EFM32GG working, based on gcc-arm and the CMSIS startup and linker scripts.  Not convinced it was worth the effort, yet.

@@pabigot I'm trying to grasp CMSIS. I normally use drivers directly from manufacturer - STM32Lib/TivaWare. I noticed that STM32 uses CMSIS DSP libraries.

Do you have to use CMSIS such that it goes under manufacturer libraries or is it completely standalone?

[pabigot 355]

I'm trying to grasp CMSIS. I normally use drivers directly from manufacturer - STM32Lib/TivaWare. I noticed that STM32 uses CMSIS DSP libraries.

Do you have to use CMSIS such that it goes under manufacturer libraries or is it completely standalone?

 

I admit I'm trying to grasp CMSIS myself, in part because vendors are not supporting it in its full glory so I can't find working examples.

 

My top-level understanding is CMSIS is a standard API specifying how names are spelled and what the corresponding function/macro/variable means.  The implementation is expected to provided by the silicon vendor, generally using templates supplied by ARM.  There are several layers and blocks in the architecture.

 

Vendors appear to delegate to CMSIS_DSP (a source library), but EFM32 adds only CMSIS-CORE, and TI doesn't even do that.  I have yet to find anybody who provides CMSIS-Driver (defined as API only) which would be what replaces driverlib (TI) and emlib (EFM32) to give access to the device peripherals.

 

In short, if done as I believe it's supposed to be done, the code is portable because it uses a generic API, but the implementation of the API is to be supplied by the vendor.  In practice, it seems each vendor thinks their home-grown APIs are better, or think it's in their best interest to have a distinct API (perhaps to make it harder for people to switch to other vendors).

[bluehash 1,581]

In short, if done as I believe it's supposed to be done, the code is portable because it uses a generic API, but the implementation of the API is to be supplied by the vendor.  In practice, it seems each vendor thinks their home-grown APIs are better, or think it's in their best interest to have a distinct API (perhaps to make it harder for people to switch to other vendors).

Thanks!.. and I think this is the main reason. Have good drivers, then why switch. Also, better tailored to their silicon.

[pabigot 355]

Thanks!.. and I think this is the main reason. Have good drivers, then why switch. Also, better tailored to their silicon.

 

Or have bad drivers (or poorly designed/named ones), make your customers angry, and hope that they've got too much invested in the proprietary approach that they won't  take the time to switch.  (Because if they do, they won't be coming back.)

 

I do not believe that a quality API that enhances common core functionality is best created by greenfield development.   It's a continuing frustration to me that people insist on creating new solutions rather than adopting existing ones (or adapting themselves to accept existing ones).  Of course, when I do exactly that I believe I have good reasons why what exists won't work.  Sometimes it turns out I was right, but more often that I was wrong but had to make the journey so I could understand why.  If I didn't care so much about understanding and working at the edge of what the tools support, the right default solution would be suck it up and always use whatever the vendor provided.

 

There are software engineering principles that CMSIS took into account in their design and of which TI appears completely ignorant.  TI also made gratuitous changes (for which there is no conceivable argument for their being better).  I'll be using driverlib underneath for TM4C, but I'd be happier if it were CMSIS-compliant because that would have been enough to make what may become a new open source system unnecessary.