bluehash

What are you doing right now..?

108 posts in this topic

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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

 

post-73-0-61033100-1395541513_thumb.jpgpost-73-0-02076900-1395541523_thumb.jpgpost-73-0-06196600-1395541537_thumb.jpg

bluehash likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@@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 likes this

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

spirilis likes this

Share this post


Link to post
Share on other sites

I started using CMSIS when playing around with the STM32 discovery boards and it seemed OK. I wondered about using it for Stellaris programming, but the install flaked out and I never got any further. Has anyone got it working on Stellaris/Tiva?

http://forum.stellarisiti.com/topic/325-stellarisware-or-cmsis/

 

Weirdly enough, I'm just starting to resurrect the BalanceBot project that I mentioned in that thread!

Share this post


Link to post
Share on other sites

Oooh CMSIS...  I think everything that needs to be said has been said.   :smile:

 

As for what I'm doing right now, I'm doing software.  Specifically, getting an OpenTag communication messaging API bridged to a iOS client.  iOS via "external accessory protocol" is a giant pain.  I'm looking forward to the Android version.

Share this post


Link to post
Share on other sites

Preamp / Multimedia-center featuring:

 

Raspberry Pi running OSMC, will add a MSP430 for power control.

 

My preamp modified for I2C control - I2C implemented in a MSP430G2553.

 

My RC5 remote, based on a MSP430G2312.

 

Tiva C as main controller: 320x240 LCD panel, old stepper motor as volume control & navigator (via QEI)

 

Keystone DAB (on a Monkeyboard) - awaiting delivery, I assume this will be the most tricky part to program for.

 

Prototyping:

 

post-45966-0-95468500-1437809360_thumb.jpg

 

Previous design in background, new design in front :

 

post-45966-0-68400400-1437809444_thumb.jpg

PTB, RobG, pine and 1 other like this

Share this post


Link to post
Share on other sites

Since this thread is back to life:

 

Right now, I am going to bed. Spent the night making a microscope camera from an old webcam. Optics from the defunct NTSC cam that came with the 'scope. Needed to set p so the optics form an image and mount the sensor of the cam in the image plane, while making it adjustable enough to align. Junk box to the rescue. Worked overnight because a) I started late afternoon, 2) it is useful to be able to turn on the dark, and iii) a lot of fit and fiddle with the lathe and waiting for epoxy to set up.

 

Cam has such a small sensor that full frame is about 4mm low zoom, and about 400micron full zoom, versus 20+mm down to 2+mm via the eyepieces. This gives about 8micron per pixel to less than one. The resolving limit for the scope is about 2.5microns, so, as I knew going in, this is far from a perfect solution. I really want a larger sensor and better match for the optics, but can't beat the price. About $3 for a PVC pipe part and three nylon screws I didn't have in the junk box. The rest was on hand.

 

Thing I can't figure out, and may have to do some actual thinking and reading about things I haven't dealt with in close to 30 years, is why the focus is rock solid in the eyepieces when zooming, but changes in the cam port. Shouldn't happen as the zoom stage is infinfite focus in and out and the cam port optical paths are supposed to be length matched. Unfortunately not my field, so, for the moment, I made my best compromise and will deal with it. The change is substantial: the focus in the eyepieces is with the objective roughly 100mm from the target, and the shift in the cam port is about 24mm over the zoom range. Should be maybe 1 or 2mm max.

 

Pics if I remember when I wake up.

Share this post


Link to post
Share on other sites

Well, finally woke back up, got real work done (one of the ways I make a living), and for those that are interested, have pics of the $3ish junkpile microscope cam. I did finally get the focus in in sync with the eyepieces. Just a real tight focal plane. If anyone wants pics and complete description, let me know. Otherwise, attached is a pic of the final product. And, yes, that is a handlebar clamp. The second time I pulled the camera off and had to try to re-align and find the focal plane, that went on to make it easy to find location. I was going to make up a shim to go between the registration faces in teh tube, but this is good enough, so I didn't bother.

post-30450-0-41220800-1438036804_thumb.png

bluehash likes this

Share this post


Link to post
Share on other sites

Your DIY microscope? I don't understand.

DIY camera for the 'scope. The 'Scope itself is a Nikon stereo zoom I picked up for a gloatable low price, that has an oddball camera port. Two ports, one left and one right, but the optics for them are non-standard, so no way I can afford commercial cam optics. Best price I have found used is still over $1000, without a camera. This is trial run for a better quality and resolution setup.

bluehash likes this

Share this post


Link to post
Share on other sites

While waiting for the Monkeyboard I have been busy porting the Keystone driver and writing a graphics library:

post-45966-0-99744400-1438363637_thumb.jpg

 

I have chosen to write my own graphics library that, shock horror, uses the heap for storing the widget descriptors.

It is fully event driven and currently has support for Canvas, Frame, Button, List and Listelement widgets and stands on top of RobGs LCD driver.

 

It integrates nicely with remote control and the stepper navigator, and I suspect it should work with a touch driver as well.

 

So far so good - I hope my code will work together with the Monkeyboard when it arrives...

 

Terje

 

 

 

RobG and bluehash like this

Share this post


Link to post
Share on other sites

Monkeyboard arrived, driver and grahics library working - but still some hiccups in main code to be ironed out...

 

Current version in action:

 

 

I may publish the graphics library and Monkeyboard driver if any are interested.

bluehash and RobG like this

Share this post


Link to post
Share on other sites

@@bluehash The horizontal bar is simply an indicator for volume level so no scrolling involved. The channel list is scrollable though, ether via the navigator button or via remote control.

 

I am using CCS since I need a decent debugger and also because I am familiar with the Eclipse IDE. I have a full CCS licence, the project compiles to over 70K of code - as I understand this is not possible when using the free licence?

 

What about a post that starts off with a description of event driven programming and how I have implemented it in my UI library? Maybe that can be helpful for those who are new to that concept.

 

My main() starts of with initializing some libraries before entering the event loop - after that I am at the mercy of the UI library and how I handle the events it delivers back:

PREAMPShowCanvas();

while (1) {
    UILibProcessEvents();
}

I have deliberately made the UI library simple, it is fairly lightweigth (about 900 lines of code) and it needs some kind of user input to drive it.

Currently this is provided either by my remote control or the navigator button (a motor from an old disk drive), to be useful for others it I think must be updated to respond to a touch screen as well. I have separated the remote and navigator code from the UI library itself so that should be fairly straigthforward.

 

The radio library is partly covered by a NDA (the protocol part), its source cannot be released - however a precompiled library & header files can be made available.

 

Terje

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now