Teacup delay(us) and delay_ms(ms) vs Arduino delay(ms) & delayMicroseconds(us)?

I was fiddling with Teacup for a Teensy 3.0 (ARM cortex-m4, mk20dx128) and noticed that for Teacup, delay(n) means a delay of n microseconds rather than milliseconds: [github.com]

Since that's opposite of the usage in the Arduino world, might it be nice to make it delay_us() or delay_us_wdt() to highlight the differences?

Looking into where delay() is used in Teacup, it seems like the calls in sd.c might be 1000x too fast.

You're right, there's a lot of duplicate and confusing stuff. I've just put a few commits onto the Gen7 branch to clean this up. Now we have only delay_us() and delay_ms().

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks.

This delay stuff depends on AVR-specific util/delay_basic assembly code, which doesn't seem to be reimplemented on PRJC's port of an arduino-like build environment for its ARM chip.

How would you see alternate architecture code developing?

One could put #ifdef __AVR__ branches around specific lines in existing files

Or maybe try to build alternate delay_ARM.c or cortex_m4/delay.c files

Or maybe it's best to try to abstract them away with defines like:

#if defined (__AVR__)
#define TICKER_COUNTER TCNT1
#define TICKER_COMPARE_VALUE OCR1A   
#define TICKER_ENABLE()  TIMSK1 &= ~MASK(OCIE1A)
#define TICKER_DISABLE()  TIMSK1 |= MASK(OCIE1A)

#define TIMER_COUNTER TCNT1
#define TIMER_COMPARE_VALUE OCR1B   
#define TICKER_ENABLE()  TIMSK1 &= ~MASK(OCIE1
#define TICKER_DISABLE()  TIMSK1 |= MASK(OCIE1

#elseif defined (__ARMEL__)  

#define TICKER_COUNTER PIT_CVAL0
#define TICKER_COMPARE_VALUE PIT_LDVAL0
#define TICKER_ENABLE()  PIT_TCTRL0 = TIE|TEN; NVIC_ENABLE_IRQ(IRQ_PIT_CH0)
#define TICKER_DISABLE() NVIC_DISABLE_IRQ(IRQ_PIT_CH0)

#define TIMER_COUNTER FTM1_CNT
#define TIMER_COMPARE_VALUE FTM1_C1V   
#define TIMER_ENABLE()  FTM1_C1SC |= CHIE; FTM1_SC |=TOF; CHIE NVIC_ENABLE_IRQ(IRQ_FTM1)
#define TIMER_DISABLE() NVIC_DISABLE_IRQ(IRQ_FTM1)

#endif

The usb_serial code for the Teensy 3 is completely different.

delay_xx() is meant to handle short delays. It's interruptible, so multiple ones can run at the same time, prohibiting using an timer interrupt.

I guess putting in some ARM assembly code would be the best choice. Isn't exactly rocket science, after all, you just need a defined number of CPU cycles consumed.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I'm sorry, I was unclear.

I meant about modifying the entire codebase to handle different architectures. ARM vs AVR will mess with the analog, arduino, clock, crc, dda_queue, delay, gcode_process, heater, memory_barrier, mendel, serial.h, sersend.h, timer, usb_serial, and watchdog.c files.
I've got it compiling and uploading to a Teensy 3.0 with , but I don't have the communication working,

That bit of code above was my trying to generalize the registers and interrupts for timer.c

The general principle usually adopted is to define a low-level API, then code all the generic code to use that API, and provide code for each architecture which implements the API. Then in theory, porting to a new architecture just involves writing a new low-level implementation.

In practice things tend to be more messy. Having a generic API inevitably means some compromise on size and performance. If different architectures have different features, what should be done if a platform does not have an equivalent feature. Implementing a subset may mean more powerful features only available on certain chips are not used. These problems can be addressed at the the cost of complexity, and often space.

So whatever is done, KISS is a good guide, otherwise you end up with a comprehensive but huge system like Linux device driver architecture. Of the small/free RTOSs, most don't try to address the driver issue. ChibiOS does, it compiles to quite lean and efficient code, but is still relatively complex and is not quite device independent in parts.

The Arduino libraries provide a reasonable level of abstraction, although their actual implementation is rather inefficient. I really try to avoid any references to specific device registers, or #ifdefs in the common code. Messy stuff, if needed, I try to confine to device specific code. For example, the analog API needs analog_init() and analog_read(channel), the generic code doesn't need to know anything more (ideally).

I ported Teacup to LPC1114 and STM32F051, and managed a reasonable level of abstraction using ChibiOS, I am undecided whether ChibiOS is a good way forward. For the DUE port I am working, on I am writing wrappers on top of the Atmel device framework, since there is no ChibiOS port for SAM3X.

Repo for my Teacup ports [github.com]

Quote

I meant about modifying the entire codebase to handle different architectures.

Yes, absolutely. A start of this process was the recent rename of the Makefile to Makefile-AVR and a split into this and Makefile-common.

I can follow what @bobc says, so I'm looking to get away without this ChibiOS. The hardware abstraction layer might be what is in arduino_xxx.h and pinio.h now. All handled by macros, so one might get away without any HAL overhead.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY