Search results

I understand that and I'd like to help. But I don't have a Teensy 3.6 currently, nor the time right now to investigate the changes needed. It appears that some architectural differences are involved requiring different registers to be saved/restored in a context change.

The only thing I can figure is that the routine fiber_getsp() was provided originally and got lost along the way. Perhaps someone can check my git repo history to see if it was there at an earlier revision. But usually I develop offline before it makes it to github, so it may have been lost...

Thanks for the summary of portability. As for the rounding, I should have provided: stack_size = ( stack_size + sizeof (uint32_t) - 1 ) / sizeof (uint32_t) * sizeof (uint32_t); That way, if the specification is 1 to 3 bytes short of alignment, it would bump the size up by the necessary...

If I understand correctly, you are using this for the Teensy 3.6, which I haven't tested it on. Someone worked with me to develop and test a port for the TeensyLC, which you might try. There were some differences in the saving/restoring of context as I recall. Beyond that, there is not much else...

Like I said, I can't explain it. It used to link ok, but doesn't now. Obviously it was either generated by the compiler or buried somewhere else 3 years ago. Others in the past have used it also and so that remains a complete mystery.

I have to say, I am stumpped. The name fiber_getsp() certainly sounds like it should have come from my source code and nowhere else. Yet, I know I have used this in the past and it worked. I am doing an exhaustive find on my Mac, but only the references are coming up. Was this something the avr...

Ah, I see. Basically, having it that way is the safest because the linker script is the only place where the whole memory layout is known. However, you could assume or override what is in there by using something like (in fiberslc.h): template <unsigned max_fibers> uint32_t *...

What does this section of your current script look like? .stack : { . = ALIGN(4); ... } >RAM _estack = ORIGIN(RAM) + 64 * 1024; The symbol _minimum_stack_size is not needed by the fibers code, unless I missed it. What is needed is the _estack symbol, so that the library knows...

Heh, heh, I thought so. Printf() does a fair bit of work. On normal platforms, one doesn't worry too much about buffer sizes on the stack or the heap. But for embedded, it can be quite a different story. As for the crash from a thread returning in Zilch, I can't help. I know that my fibres...

I don't have the time at the moment to look more deeply at this, but I suspect printf()/foo() has exhausted your available stack space and overrun it. Thus corrupting another fiber's stack frame (or the even the heap). If things work with a simple bar() call (with low stack frame needs), then...

I'm late to the party here (sorry, but been busy). The fibres library should work just fine with malloc/free/printf et al. assuming stack and heap are properly set up. Because the context switch only happens when yield() is called, you'll never interrupt printf or malloc type functions. The...

Not the last time I looked. The AVR has the Harvard architecture (physically distinct data and instruction memory), so this hack is necessary. To access data or instructions on AVR require the use of different instructions. The ARM address space is uniform between data and instructions (von...

That over simplifies the issue really because things can get locked up instead. For example if your "existing library" doesn't return from a call until data is returned, then nothing else in your application will get serviced (until the return from the call occurs). So if you needed to detect a...

It's never been said here that RTOS is the "only way". Any system can be broken up into a state machine, but how horridly complex some of those state machines would be. A complex state machine is very horrible to debug. At some point, the algorithm should be precisely known. It doesn't matter...

As these MCU devices get larger and applications develop increasing scope, the need for an RTOS becomes more important for sane software development (software correctness today is perhaps the #1 problem to be solved). Another aspect of that is the need for platform drivers to save development...

Duff, the mbed environment and Arduino environments are pretty much oil and water. Additionally if you use the mbed-rtos offering, I've read in their forums that you should not be grabbing interrupts (the RTOS and the drivers want to manage that). In many cases the ARM drivers will give you a...

I've used FreeRTOS also, but to get the project setup is more work; compared to mbed at least. As far as preemption/coroutines goes, there are certainly dangers lurking there for complete noobs. OTOH, I think it sometimes best to get burned a few times and learn those lessons early on. Knowing...

I tried exporting my TeensySignalBlink project as a GCC based project. I unzipped it, set the PATH to my cross compiler and typed make (Gnu make on Mac OSX). The build ran and successfully produced a .hex and .elf result. Burned the .hex file and away she went. This was far too easy!

Ok, got it.

Teensy-3.1 mbed-rtos is looking pretty good so far. This is just a variation on the simple blink above, except this uses mbed-rtos signals from the main loop to drive events in the blink_thread. #include "mbed.h" #include "rtos.h" #include "USBSerial.h" DigitalOut myled(LED1); // Onboard LED...

My having got the Teensy-3.1 working with mbed, the next logical step was to try mbed-RTOS. Their website warns that they're revising this mbed-RTOS API, yet I am willing to use it for now. So below was my first of simple thread tests. It's just a main program that does nothing but loop (with...

I'm a bit confused by your reference to ./avr/cores/teensy3. Were you running Arduino libraries instead of mbed?

Off the top of my head, I would say that, you can add mbed_src to your project. Then drill down through the target level to file system_MK20D5.c. In there, you should be able to tweak clock settings etc. As for the rest, I dunno.

That's what I expected initially. Then I would get pointed after some googling to the url given earlier, but I would look at it and mutter "how does this help me?". It wasn't until later that I noticed the blue button. They do allow you to export your project and as part of that you can select...

I know that I am late to the party here, but thanks to everyone involved! I finally got a chance to try this. I've been slowly catching up on various projects, but the one thing that was high on my list was to get mbed working on my Teensy-3.1. So thanks to all of those who worked through the...

Teensy-3.1 Fibers library ported to Teensy-LC Working with Colin Duffy, the Teensy-3.1 fibers library (https://github.com/ve3wwg/teensy3_fibers) was ported to the Teensy-LC, which is available here: https://github.com/ve3wwg/teensylc_fibers This library is useful for those needing a...

No, I think you found typos! Yes, indeed 0 is the main thread. The value used in the restart method should be the index returned in the fibers.create() method. So yes, use ffoo in the example, not zero. I'll fix the example program on github in the mean time. Thanks for pointing that out. Warren

I'll second that. Documentation is *key* for a programming platform.

Glad to hear that! I am busy with some AVR work at the moment, but some day need to get back to my teensy-3.1 projects.

Note sure about the point that you are making, but this class does not need to, nor is designed to replace mutexes, queues or semaphores. It is simply a way to provide cooperative multitasking in a lightweight object.

When I first developed the library, I used a separate assembler language module, which I don't believe will be handled by the IDE. I've since converted it to a .cpp module, using inline asm where it was needed. That change made it possible to just #include it into a sketch.

The lightweight fiber library has moved to its own project at github, for easier use by Arduino IDE users: https://github.com/ve3wwg/teensy3_fibers Git url: git@github.com:ve3wwg/teensy3_fibers.git There is an example sketch included in the above repo, but I'll copy it here for your reading...

Update - May 4, 2014 The library has been enhanced to allow a fiber (coroutine) to return (exit) and remain stopped. In essence, it becomes trapped in a loop that just performs a yield() call. It's state also is changed to FiberReturned. In this state, it is now possible re-use that fiber, by...

I am quite willing to wait, thanks.

This of course, can bring up some reentrancy issues. Like one "thread" calling a usb serial function, which then calls yield(), causing (if a thread context change is done) another "thread", which might also invoke a usb serial call. Alternatively another usb serial call directly from within the...

I'd like to see Paul weigh in before I contribute. The idea is to have an agreed upon collaboration tool and site. I'm not sure we have the general consensus yet.

That won't be effective either-- it only proves that yield() was called, just to give control away to the next "thread", whether it was ready or not. To get a sense of "idle time" you need a "ready queue" that lists the "threads" that are ready to execute. The dispatching code can then spin...

I have no experience with that one, but it seems to have a pretty face. github.com also supports a wiki, but I'm not fond of that implementation (it seems broadly lacking and only suitable as a last resort). I have used dokuwiki (https://www.dokuwiki.org/dokuwiki), which when combined with a...

Hey Paul, you seem like a very busy guy here. My cable arrived from you today (thanks very much) and I've finally had time to play a bit with the Teensy-3.1. After the usual blinky test, I then immediately wanted to try out the usb serial library support, since this is a convenient way to get...

That seems to have done the trick (thanks). On a warm Saturday afternoon, I'll have to review what you changed, to see if I can understand these complex new c++11 changes.

Interesting.

I know you can successfully work around that with const refs, but I find it rather irksome to be forced to. There was no change (github said I was already working with the current version). I do believe this is a compiler bug, since it was my understanding that this should always work (none...

Hi Christoph: I've been putting the Signal class to work on a future project of mine, involving a MIDI dispatch to various Signal instances. What I am finding, is that I am getting compile errors (currently testing on OSX) from some of the signal calls: Signals/signals.h:89:10: note: candidate...

I suspect that the FreeRam() routine only reports the unfragmented heap's free memory remaining. In addition to this memory, is a "chain" of memory fragments that have been freed. If you were to request that exact same allocation, you'll likely get the same memory pointer back and your...

Every teensy detail helps!

This seems to be more like a "software bus", but not the kind that gstreamer uses. Some software busses (like gstreamer) queue up structures of data that are then passed along to other nodes (audio/video processing in that case). The approach used here starts with a call on the Signal object...

Noted and looking good. Thanks

You're right - for the master on/off I was thinking in terms of flagging currently connected Connections to a given signal. But I agree now that on/off at the Signal level is better. In this case, we wouldn't be affecting the state of individual connections as you've said. It would also have the...

Agreed, which is why I brought up the point (and glad that you see it that way). But the naming enable_all (say) might imply that it is now enabled. So perhaps the best solution is in the naming.

So now the question is, when you enable all, do you "restore the enable state" that was, or simply turn on regardless of former state. What I mean is, if you disabled one connection, then disabled all, and then re-enabled all, would that disabled connection be enabled as well? It could be done...