TK.
-
Posts
15,247 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by TK.
-
-
- Only one ISR exists in the system, it's for the 1ms timer used by the OS, no other ISRs can be enabled or the OS will break
Is this not correct?
No, this isn't correct. In MIOS32, many other interrupts are running.
Also MIOS32_TIMER based app callbacks are called from interrupts with a much shorter interval if required.Why aren't incoming UART bytes buffered in any way? Why aren't they saved to RAM using DMA? Yes, there would be a small latency (<1ms) but this means bytes would never be lost (unless there was a buffer overrun).
I've use cases in my own applications where I have to handle incoming bytes immediately.
E.g. MIDI clock in slave mode requires that processes are (immediately) clocked with each incoming 0xf8, and/or that delays are measured between the 0xf8 events to avoid unwanted jitter.But in MIDIbox Quad Genesis, there's a mode in the OPN2 where sampled audio is played back on the sound chip, and the CPU has to write each sample one-by-one with no buffering. So there has to be an interrupt at 44.1kHz which cannot get delayed by more than 10us or so. Also, this interrupt will have to be able to play samples on four OPN2s at once--I think I can get the timing code right, but this has to be absolutely highest priority.
have a look into the MBCV V2 application where I'm running high prio synth processing with a MIOS32_TIMER
I read over the STM32F4 DMA application note, it's pretty confusing, but it does look like DMA channels can be set up to handle receiving UART bytes.
I don't think that you need this - it would especially conflict with my own applications, so it would be a dedicated modification at your side, which isn't required if your ISR meets the requirements that I mentioned above.
So, I ask you again: does your ISR consume more than 500 uS?
(I don't think so...!)Is there any other peripheral that needs extremely fast service? How about USB MIDI? I know very little about USB packets, but I'm assuming they go in some sort of buffer. The SPI interface to the SD card isn't time-critical, right?
IIC needs high priority as well, USB doesn't (it's a handshake protocol), SPI is only a question of required bandwidth (but SD Card transfers are handled via DMA already...), no risk for data loss.
Best Regards, Thorsten.
-
It isn't that easy, because you've to differ between ROM (=flash) and RAM, and especially for LPC17 between the lower and upper RAM bank.
Before overcomplicating things: check the RAM pointers, ignore other sizes.
Best Regards, Thorsten.
-
No, I don't know exactly how much stack memory is required. Once we touched the limit, users will typically complain about hard faults, which tells me that the last feature consumed too much RAM...
If you want to be at the secure side, take the current __ram_end as the one which shouldn't be exceeded
There is no optimization flag which would allow to reduce the RAM consumption, the only way is to remove existing features, or to use one of the newer cores (such as MBHP_CORE_STM32F4)
Best Regards, Thorsten.
-
LPC17 has two RAM banks, one goes from 0x10000000..0x10007fff, and the second from 0x2007c000..0x20083fff
But special care is required for the first bank, because the stack for background task (&IRQs) will be located from __ram_end..0x10007fff. It depends on the application itself how much stack memory is required for the background task, and since the worst case stack usage is difficult to determine, this is typically a source for unintended hard faults.
Best Regards, Thorsten.
-
For single color LEDs, 220 Ohm should be fine regardless if green or red LEDs are used.
More information (also about the LED polarity) can be found in the Wiki under: http://www.midibox.org/dokuwiki/doku.php?id=wilba_mb_seq_construction_guideBest Regards, Thorsten.
-
there is a little error message, which the terminal outputs as soon as I start the midibox:
ok, I've to shorten the label name in the next release
And btw: Is there a chance so control the LEDs with the internal MIDI clock so it can act like an visual metronome? :-)
MIDI clock event handling is still on the TODO list - so, yes, could be possible sooner or later.
//edit: just discovered another "bug". When I set the rainbow on and run after that RGBLedClearAll not always all LEDs will go off. Sometimes (random) a few of them are still on in different colors (no rainbow effect). I'd need to use the command twice in this case to shut off all LEDs. :)
the rainbow effect is handled in the background task. It's possible that it will be disabled from a higher prio task while new LED values are written, this results into the effect that you see. However, In the next release, LEDs should be cleared correctly.
The rainbow effect should still go on when you change between those two NGC files. But you an see that the speed differs. Is this meant to be like this?
yes, it's plausible: timings are not ensured when functions (like the rainbow effect) are called from the background task. The AINSER module will cause some additional CPU load and this will slow down the rainbow effect.
Not critical from my point of view (assuming that we are talking about a testing feature)Best Regards, Thorsten.
-
Unfortunately I can't help here, it requires a windows expert to check for options to overcome this issue.
For MacOS it's sufficient to give each core a dedicated USB device name (see also: http://www.ucapps.de/mios32_bootstrap_newbies.html )
But as far as I know, this name isn't take by the Windows driver.
Best Regards, Thorsten.
-
Ca I expect to run 5631 at full res 10bit and having the same precision than a 5630 downgraded at 10bit.
yes
If you only need 10bit, 5631 is a good choice.Best Regards, Thorsten.
-
Got the case as well - really nice and especially robust one, I like it! :)
-
Actually you are right. If we ignore the initial question about the usage of MIOS32 w/o FreeRTOS the answer is simple:
interrupt priorities are centrally defined in mios32_irq.h, and I also commented the reason for certain priority decisions there: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Finclude%2Fmios32%2Fmios32_irq.h
Since Saureans application relies on UART based MIDI, it has to be ensured that the UART handler has such a high priority, that incoming bytes can't get lost.
If time critical ISRs never consume more than ca. 500 uS in worst case, even if they are requested back-to-back, they could just run with superhigh priority (priority value < MIOS32_IRQ_PRIO_HIGHEST, e.g. 3) to fulfill the requirements w/o any changes in MIOS32 or the programming model.Best Regards, Thorsten.
-
The BLM port is nothing else than a combined MIDI IN/OUT.
The QUAD IIC Board has already the required resistor and optocoupler components, so all you need to do is to connect one MI/MO pair + Vs + Vd from MIDI IO to the port to the Quad IIC Board
Best Regards, Thorsten.
-
See this architectural overview which shows, how MIOS32 apps are structured: http://www.ucapps.de/mios32/mios32_flowchart.png
The brown blocks are FreeRTOS related.
The good news: none of them is located in trunk/mios32, but under programming_models/traditional
Which means in other words: all you need to do is to create your own programming model w/o FreeRTOS, the "traditional" version can be taken as a reference.
Alternatively, if you don't consider to share this model in different applications, you could locate main() and the a timer based task handling directly in your app.c file.Best Regards, Thorsten.
-
do you think that the LEDs will be even brighter with a more powerful power supply? They were already very bright ;-)
Just compare the brightness if only a small number of LEDs are enabled with fully brightness vs. all LEDs enabled at the same time.
My strip has 120 LEDs but I will cut it to fit an 88 keyboard. So it will be around 90 LEDs. Will then only 64 LEDs work?
you could recompile the firmware with
#define WS2812_NUM_LEDS 90
in the src/mios32_config.h file to allow the control of up to 90 RGB LEDs
Best Regards, Thorsten.
-
As long as you don't enable all LEDs with full brightness, the power consumption is much lower, so that you could supply the strip via J4B
The meta description says "LED 1-64", because in the driver only 64 LEDs are enabled (each LED consumes 48 bytes, therefore I'm careful).
However, if somebody wants to drive more than 64 LEDs, I could increase the number.Here a new version which supports EVENT_RGBLED:
-> http://www.ucapps.de/mios32/midibox_ng_v1_033_pre18.zipo added EVENT_RGBLED See cfg/test/rgbled_1.ngc for usage examples o .NGR file: added "set_hsv" command which allows to control the hue parameters of a RGBLEDNote that the meta commands that I introduced yesterday writes into the RGB LED RAM directly, while a EVENT_RGBLED will store the value in the patch and will overwrite this value on any update. That's also the reason why we need a "set_hsv" command which allows to change the HSV value of a RGBLED event which remains in the patch.
Here some usage examples:
http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Frgbled_1.ngcBest Regards, Thorsten.
-
Code is ready for testing! :-)
-> http://www.ucapps.de/mios32/midibox_ng_v1_033_pre17.zip
Currently only meta commands are provided, more control (such as EVENT_RGBLED) will be available later:
o support for WS2812 LED strips (currently only for the MBHP_CORE_STM32F4 module). The data input has to be connected to J4B.SC, ground to J4B.VS and +5V to an external PSU (required, since each RGB LED can consume up to 20 mA!) Following meta event commands are available: - RgbLedClearAll (clears all LEDs) - RgbLedSetRgb:<led>:<r>:<g>:<b> (led=1..64, r/g/b=0..255) - RgbLedSetHsv:<led>:<h>:<s>:<v> (led=1..64, h=0..359, s=0..100, v=0..100) - RgbLedRainbow:<speed>:<brightness> (speed=1..255, brightness=0..100) Most simple way to test a LED strip: enter following command in MIOS Terminal ngr exec_meta RgbLedRainbow:9:100 (don't forget to wear sunglasses, or start with brightness 20!!! ;-)Technical details: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fws2812%2Fws2812.c
And for the blink: following GIF shows "ngr exec_meta RgbLedRainbow:9:20"
Best Regards, Thorsten.
-
Yes, good news!
140 nS should be feasible if bitbanging is handled by a DMA channel with highest priority.
I ordered the LED stripe that I linked above and will test this weekend.If it works like expected, MBNG will get a new EVENT type which will allow to access the LEDs with 8bit resolution.
Best Regards, Thorsten.
-
cool! :)
Best Regards, Thorsten.
-
Btw.: please update the repository - yesterday I noticed that in MBNG the KEYBOARD_Periodic_1mS() function was running in the wrong task (background instead of APP_Tick())
This could cause random velocity values if LCD messages are print as well.Best Regards, Thorsten.
-
Can I ask the specs/datasheet of the LEDs you are using i.e. luminous intensity in mcd?
see http://www.ebay.de/itm/171931571912
R: 500-800mcd, G: 3000-5000mcd, B:2000-3000mcd
you using current limiting resistors?
220 Ohm for R+G, 100 Ohm for B
What about RGB LEDs with embedded controller? WS2812B based RGB LEDs or LED strips are quite cheap on ebay.
Hm! How could I overlook this! Actually I intended to try out this chip some months ago, but I totally forgot about this possibility! :)
The SPI usage would be too expensive for this purpose, especially since most MBHP_CORE_* modules only have 3 integrated SPIs which are already assigned to other peripherals.
But a 800bps rate (output only) can be easily achieved via bitbanging, e.g. if a DMA transfers the prepared pin access patterns triggered by a timer.
I will try this soon, because it will be a much better solution for RGB LEDs!E.g. this seems to be a nice one: http://www.ebay.de/itm/1m-60-RGB-LED-Strip-schwarz-mit-WS2812B-5050-SMD-LEDs-WS2811-Controller-WS2812-/371332277097?hash=item567520e369
Best Regards, Thorsten.
-
Unfortunately you won't be able to detect a defect in the 74HC14 with an ohmmeter.
The 74HC14 is an inverter chip, if input 6A is at logic-0 level (around 0V), 6Y should be logic-1 (around 5V) and vice versa. If this isn't the case, lift 6Y (pin 12) - means, put this pin out of the socket - and measure again. If you still don't notice the inverting function, then the chip is defective and needs to be replaced.
Of course, overvoltage or wrong polarity could destroy this chip very quickly.
The MBHP_BURNER project is maybe not the best one for beginners. Actually today (10 years later) I would recommend to buy a cheap PICkit2 (clone) at Ebay instead. See also http://www.ucapps.de/mios_bootstrap_experts.html
So - if you are not able to get MBHP_BURNER running, consider to buy a PICkit2 at Ebay, it will be less troublesome.
Best Regards, Thorsten.
-
Please try this version:
http://www.ucapps.de/mios32/midibox_ng_v1_033_pre16.zipThe new command can be called with:
exec_meta SaveDelayedSnapshot:15
this will store the snapshot after at least 15 seconds (if there is no ongoing request)
Currently it doesn't check if any value has been changed - this will become a difficult task at my side, but let's see if this command is already sufficient.
Btw.: with "set debug on" in the MIOS terminal you will get a notification message whenever the snapshot save operation takes place.
Best Regards, Thorsten.
-
An event only takes place on a value change, but the problem is that with DumpSnapshot you provoke that all values will be sent out (again).
Btw.: is it clear to you, that DumpSnapshot doesn't store values, but sends the values of all control elements?
SaveSnapshot would be the right command for this purpose, but the problem is, that it store immediately with the effect that if the section is called rapidly multiple times per second (for whatever reason), the store operation will stall MBNG too much.I think the only proper solution for your use case would be a new NGR command which requests a snapshot save, and only if any value has been changed - it shouldn't take place more often than once per second, right?
Best Regards, Thorsten.
-
All that legato/sustain/note stretch features have been removed from the firmware (which is originated from MBSEQ V3) and no memory has been reserved to store such a parameter, therefore I don't see a way to consider your request.
So, if you find a different solution (e.g. firmware change in 9090) it would be better.
However, if you've luck following MB808 firmware change could already help:
in src/seq_layer.inc, search for SEQ_LAYER_GetEvntL, it's currently:
SEQ_LAYER_GetEvntL movlw 0x10 ; fixed length movwf SEQ_EVNTL, BANKEDIf you change it to:
SEQ_LAYER_GetEvntL movlw 23 ; fixed length movwf SEQ_EVNTL, BANKEDthe note length should be almost 1/16th
Higher values could result into legato, but I haven't tested this...
Btw.: which firmware version are you using?
V1.4 got some new features, e.g. a HH control switch for 909: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_808%2FCHANGELOG.txtBut I noticed that I haven't officially released it yet; the mios_download page still shows v1.3
Best Regards, Thorsten.
-
The sammichFM is maybe a bad example, because the user interface doesn't allow to select the pages directly (like for example a MIDIBox SID (not sammichSID).
However, it makes sense to collect opinions from future users.
It should be possible to implement different CS approaches for the same hardware, just the frontpanel silkscreen will be different.
Best Regards, Thorsten.
QuickSel Loops
in MIDIbox SEQ
Posted
They define the track length.
The track length is also the loop end
Best Regards, Thorsten.