Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - bhagman

Pages: [1] 2 3 ... 6
The bootloader for that board can be found here:

Let me know if you need help with it.
Core/Cross-platform Library Questions / Re: WHardwareTimer.h
« on: October 20, 2014, 03:01:13 PM »
Yes, the reason it seems unfinished is because the way the hardware timers were being built originally were very Atmel AVR-centric, which led to a lot of AVR-isms.  We've been working on developing the Wiring Framework to be target independent, and as such, the settings for the hardware timers in the AVR series differ from other controllers.

As I built out the WHardwareTimer library, I started realizing that it was not going to go away from the the AVR-isms, so I ended up half-finishing the setMode and other register management functions.

But, in a nutshell, setMode writes to the WGM (Waveform Generation Mode) bits of the AVR 8 bit series TCCR (Timer/Counter Control Register).

Have a look at the HardwareTimer::setMode() function to see exact details:

Code: [Select]
void HardwareTimer::setMode(uint8_t mode)
  // WGMn3 and WGMn2 are in positions 4 and 3, respectively, in TCCRnB
  // WGMn1 and WGNn0 are in positions 1 and 0, respectively, in TCCRnA

  // For devices with global TIMSK, 8 bit timers have:
  // WGMn0 in position 6 of TCCRn register
  // WGMn1 in position 3 of TCCRn register

#if defined (TIMSK)
  if (_timerNumber == 0 || _timerNumber == 2)
    // only a single control register on these devices (TCCRn)
    *_tccrna = (*_tccrna & 0b10110111)
                 | ((mode & 0b00000001) << 6)
                 | ((mode & 0b00000010) << 2);
    // everything else conforms (the two control registers for the WGM)
  *_tccrna = (*_tccrna & 0b11111100) | (mode & 0b00000011);
  *_tccrnb = (*_tccrnb & 0b11100111) | ((mode & 0b00001100) << 1);
#if defined (TIMSK)

The same applies to setOutputMode - which sets the COM (Compare Output Mode) bits of the TCCR register:

Code: [Select]
void HardwareTimer::setOutputMode(uint8_t channel, uint8_t outputMode)
  uint8_t COMbitMask = 0b11;
  uint8_t shiftCount;

  outputMode &= 0b11;  // only 4 modes

  if (channel < _channelCount)
    if ((_timerNumber == 0 || _timerNumber == 2) && _channelCount == 1)
      // 8 bit timers with only 1 OCR
      shiftCount = COMn0;
      // 16 bit timers
      if (channel == CHANNEL_A)
        shiftCount = COMnA0;
      else if (channel == CHANNEL_B)
        shiftCount = COMnB0;
      else if (channel == CHANNEL_C)
        shiftCount = COMnC0;

    COMbitMask <<= shiftCount;
    outputMode <<= shiftCount;

    *_tccrna = (*_tccrna & ~(COMbitMask)) | outputMode;

I'd like to develop the HardwareTimer class into a cross-platform Framework class, such that the functions we use are generic enough to apply to any target controller.  I know that there will still be specific functions that will need to be supported, and may be handled by platform specific functions (i.e. incompatible), but target independent is what I'd personally like to shoot for.

As always, any help in designing and defining the Framework would be greatly appreciated.
General Discussion / Re: Wiring++
« on: January 23, 2014, 02:24:08 PM »

Hey sstaub,

Yes - Wiring++ is still very much going to happen.  But, as always, we have extremely limited resources, and very few volunteers to work on the software.

An objective of the next version of Wiring is to have the Framework become extremely easy to port to new platforms.  Robert Wessels (Texas Instruments' Energia project), Rei Vilo (embedXcode) , Marti Bolivar (LeafLabs), and Hernando Barragan have put an enormous effort into changing the "Build Unit" into something that will make porting to new processors and boards extremely easy.

The D20 and other ARM processors should be relatively easy to add once we release the next version of the IDE as long as they have a port of the GNU C++ compiler (and tools).

As for new additions to Wiring, Ed Baafi (from Modkit) had suggested adding a threading and event model to the Framework (which you may have seen at the San Mateo Maker Faire).  It was a brilliant idea, but possibly a bit too advanced for general users to use.  So, we've begun a new approach to the threading idea and, hopefully, we'll be able to show it off soon.

Since this is an open source project with no funding (no, not even from Arduino), the development happens when it happens.  We don't have deadlines, and we are restricted by the resources we have, which consists of, at the time of writing, just the three of us (Alex, Hernando and me).

If you have the passion, time, and knowledge to work on the Wiring Project, we'd, more than anything, love to have you help us with the project.  Funding the project through donations would also help.

General Discussion / Re: Communication Problem
« on: August 18, 2013, 08:44:53 AM »
This sounds like the bootloader on the board that you're using is an old one.

You should try updating it to the latest one for the board you have.

Let me know if you need help doing that.
Code: [Select]
      case 0:
        EIMSK &= ~(1 << INT0);
        EICRA = (EICRA & ~(0b11 << ISC00)) | (mode << ISC00);
        EIMSK |= (1 << INT0);

This code is simply a contraction of the previous code.  I admit, it's not as clear, but it results in the exactly the same thing.  (you'll see the 0b11 - the operation is moving 2 bits at the same time, instead of single bits in the previous code.)

Now, here is a possible solution for you to try in the core for the attiny's.  Let's just map sense control bits for INT1 to the same as INT0.  Look in the WInterrupts.h file and make these changes:

Code: [Select]
#if defined(INT1)
 #if !defined(ISC10)
  #define ISC10 ISC00
  #define ISC11 ISC01

Try that out, and let us know how it goes.
This will require some effort.  If possible, you should contact the company that made the board to help you with building the new bootloader to work with the Wiring Framework.

To reprogram that board, you'll need to use the internal RC oscillator (running @ 8MHz) as I think that it has a 14.7456MHz external crystal.

Here are the makefile settings for the .mk file in the booladers/build folder for Wiring.  E.g.

Code: [Select]
## ATmega128A-8MHz
atmel-128a-8MHz: HARDWARE = ATmega128A_8MHz
atmel-128a-8MHz: MCU = atmega128a
atmel-128a-8MHz: BOOTLOADER_ADDRESS = 1F800
atmel-128a-8MHz: F_CPU = 8000000
atmel-128a-8MHz: HW_DEFS_H = defs-wiring-v1-mega.h
atmel-128a-8MHz: all
   mv $(PROJECT).hex $(PROJECT)_$(HARDWARE).hex

Here are the fuses you will need to program onto the ATmega128A:

Code: [Select]
Low: 0xA4
High: 0xD4
Extended: 0xFF

The fuses will set the '128 to use the internal RC oscillator @ 8MHz.

If you create the file with the above information, and put it into the Wiring bootloaders/build folder, you can run make atmel-128a-8MHz in that folder to create the new bootloader.

You will have to have a version of avr-gcc installed somewhere (I think the board that made the company walked you through how to do that).

Let us know how it goes!
STM32 ARM Cortex / Re: Wiring for all STM32 Discovery boards
« on: March 19, 2013, 08:23:57 AM »
The Wiring Framework is not intended to support all functions for all microcontrollers.  It is intended to ease the comprehension entry-barrier for working with microcontrollers.

With that said, it will be possible (if/when STM32 support is ready) to have complex libraries and additional code support for things like DMA and RTOS functionality.

If you would like to volunteer to help out with the development of the Wiring Framework on the STM32 series, please do!
Wiring Hardware Questions / Re: house wire
« on: January 14, 2013, 10:48:02 PM »
Hey there... I think you're looking for house electrical wiring advice. is all about the Wiring Project and its programming Framework.

You'll be best off looking for advice here:

Good luck!
Programming Questions / Re: Usage of HardwareSerial class
« on: August 29, 2012, 09:32:09 AM »
Can you post the errors you're getting?
Luckily, we don't have too many of the play shields / adapters out there. I'm going to redesign the Wiring S to have a new shield standard, so the PlayShield will also be redesigned.

If you are one of the fortunate few that have a Play Shield, please use Olivier's work-around or, as another idea, just place a piece of electrical tape on top of the USB connector.

Ultimately, the Framework will have a single definition for the Framework version.

So, for example, Wiring Framework version 1.1 will have the preprocessor constant WIRING=110.

All IDEs supporting the Wiring Framework will have this definition.

We still are defining all of this for the Framework.
Programming Questions / Re: Setting the fuses correctly
« on: June 22, 2012, 11:54:22 AM »
Hey Vio,

You can find the fuse values in the boards.txt file.

Where did you get RTClib from?

I can't understand what's missing if I can't see what's going on in the library.
Wiring Implementations / Re: Why not join forces with Arduino
« on: March 30, 2012, 10:34:23 AM »
The funny thing is that I talked to Mark Sproul and Rick Anderson just slightly before and after the combined Microchip press release of ChipKIT.

I told them what we were doing with Wiring, and unfortunately, they are like most of the others at the Arduino camp; stuck with their heads in the sand.  They seemed pretty disinterested in working with us, which was quite sad, since they have put a lot of effort into an already flawed system they have put together (their architecture support would make the average engineer pull their hair out).
Interesting.  I never looked at the Nano.  I guess that's my fault.  I just assumed it was a repackaging of the first boards into a "DIP" package.

Please add the issue!  We'll get 'er fixed.
Pages: [1] 2 3 ... 6