[fpc-pascal] ARM-embedded & Interrupt numbers
Hi,
I'm trying to restart my arm-embedded project.
A few years ago I had a working compiler, with some utility-files.
I made a new cross-compiler (fpc svn 31290). But I don't find where the
interrupt-numbers of an STM32F103xx processor are defined.
So I made an inc-file and added that to e.g.
rtl/embedded/arm/stm32f10x_md.pp, because that's the processor I'm
working with.
The inc-file does contain ifdef's for the different STM32F10x processors
though, so all stm32F10x files could contain that inc-file.
Is this the way to do it ? Or is there better way ? Or does this exist
already ?
Comments please.
If that's a proper way to do this, how could this be included in a next
version of fpc ? Do I make a bug-report including the new file, with
diffs for the modified files ?
How do I make a proper diff ?
Thanks,
Koenraad.
Code snippet of the interrupt-numbers :
const
NonMaskableInt_IRQn= -14; // 2 Non Maskable // interrupt
HardFault_IRQn = -13; // 4 Cortex-M3 Memory Management
// interrupt
MemoryManagement_IRQn = -12; // 4 Cortex-M3 Memory Management
// interrupt
BusFault_IRQn = -11; // 5 Cortex-M3 Bus Fault //
interrupt
UsageFault_IRQn= -10; // 6 Cortex-M3 Usage Fault //
interrupt
SVCall_IRQn= -5; // 11 Cortex-M3 SV Call //
interrupt
DebugMonitor_IRQn = -4; // 12 Cortex-M3 Debug Monitor //
interrupt
PendSV_IRQn= -2; // 14 Cortex-M3 Pend SV //
interrupt
SysTick_IRQn= -1; // 15 Cortex-M3 System Tick //
interrupt
WWDG_IRQn = 0; // Window WatchDog // interrupt
PVD_IRQn= 1;// PVD through EXTI Line
detection // interrupt
TAMPER_IRQn= 2; // Tamper // interrupt
RTC_IRQn= 3;// RTC global // interrupt
FLASH_IRQn = 4;// FLASH global // interrupt
RCC_IRQn= 5;// RCC global // interrupt
EXTI0_IRQn = 6;// EXTI Line0 // interrupt
EXTI1_IRQn = 7;// EXTI Line1 // interrupt
EXTI2_IRQn = 8;// EXTI Line2 // interrupt
EXTI3_IRQn = 9;// EXTI Line3 // interrupt
EXTI4_IRQn = 10; // EXTI Line4 // interrupt
DMA1_Channel1_IRQn = 11; // DMA1 Channel 1 global //
interrupt
DMA1_Channel2_IRQn = 12; // DMA1 Channel 2 global //
interrupt
DMA1_Channel3_IRQn = 13; // DMA1 Channel 3 global //
interrupt
DMA1_Channel4_IRQn = 14; // DMA1 Channel 4 global //
interrupt
DMA1_Channel5_IRQn = 15; // DMA1 Channel 5 global //
interrupt
DMA1_Channel6_IRQn = 16; // DMA1 Channel 6 global //
interrupt
DMA1_Channel7_IRQn = 17; // DMA1 Channel 7 global // interrupt
{$ifdef stm32f10x_ld}
ADC1_2_IRQn= 18; // ADC1 et ADC2 global //
interrupt
USB_HP_CAN1_TX_IRQn= 19; // USB High Priority or CAN1 TX
Interrupts
USB_LP_CAN1_RX0_IRQn= 20; // USB Low Priority or CAN1 RX0
Interrupts
CAN1_RX1_IRQn = 21; // CAN1 RX1 // interrupt
CAN1_SCE_IRQn = 22; // CAN1 SCE // interrupt
EXTI9_5_IRQn= 23; // External Line[9:5] Interrupts
TIM1_BRK_IRQn = 24; // TIM1 Break // interrupt
TIM1_UP_IRQn= 25; // TIM1 Update // interrupt
TIM1_TRG_COM_IRQn = 26; // TIM1 Trigger and Commutation //
interrupt
TIM1_CC_IRQn= 27; // TIM1 Capture Compare //
interrupt
TIM2_IRQn = 28; // TIM2 global // interrupt
TIM3_IRQn = 29; // TIM3 global // interrupt
I2C1_EV_IRQn= 31; // I2C1 Event // interrupt
I2C1_ER_IRQn= 32; // I2C1 Error // interrupt
SPI1_IRQn = 35; // SPI1 global // interrupt
USART1_IRQn= 37; // USART1 global // interrupt
USART2_IRQn= 38; // USART2 global // interrupt
EXTI15_10_IRQn = 40; // External Line[15:10] Interrupts
RTCAlarm_IRQn = 41; // RTC Alarm through EXTI Line //
interrupt
USBWakeUp_IRQn = 42; // USB WakeUp from suspend through
EXTI Line // interrupt
{$endif}
{$ifdef STM32F10X_LD_VL}
ADC1_2_IRQn= 18; // ADC1 et ADC2 global //
interrupt
EXTI9_5_IRQn= 23; // External Line[9:5] Interrupts
TIM1_BRK_IRQn = 24; // TIM1 Break // interrupt
TIM1_UP_IRQn= 25; // TIM1 Update // interrupt
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ARM-embedded & Interrupt numbers
Hi Koenraad, On Fr, 2015-08-14 at 09:08 +0200, Koenraad Lelong wrote: > Is this the way to do it ? Or is there better way ? Or does this exist > already ? > > Comments please. > > If that's a proper way to do this, how could this be included in a next > version of fpc ? Do I make a bug-report including the new file, with > diffs for the modified files ? > How do I make a proper diff ? I can't answer your question(s), only want to bring this to your attention: http://j-software.dk/stm32f103.php Maybe you can save some work or find answers in that code. HTH, Marc -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ARM-embedded & Interrupt numbers
Jeppe would be the best person to answer your question anyway as he is the master of (nearly) all files in the embedded directory. I just checked, when I created my own units for other devices I included those const's, it seems that they never were in Jeppe's files could it be that you saw them in lpc11xx.pp ? To be honest I was 100% sure that I have seen those declarations in Jeppe's files, but a quick check in svn showed that those consts actually never were there... (or I am blind) For using Interrupts in your code you do necessarily need them as it is good enough to write procedures with the correct name: procedure SysTick_interrupt; [public, alias: 'SysTick_interrupt']; begin inc(Systick_Timestamp); end; but for configuring interrupts in nvic the constants actually could help. Michael Am 14.08.15 um 13:33 schrieb Marc Santhoff: Hi Koenraad, On Fr, 2015-08-14 at 09:08 +0200, Koenraad Lelong wrote: Is this the way to do it ? Or is there better way ? Or does this exist already ? Comments please. If that's a proper way to do this, how could this be included in a next version of fpc ? Do I make a bug-report including the new file, with diffs for the modified files ? How do I make a proper diff ? I can't answer your question(s), only want to bring this to your attention: http://j-software.dk/stm32f103.php Maybe you can save some work or find answers in that code. HTH, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ARM-embedded & Interrupt numbers
On 08/14/2015 09:08 AM, Koenraad Lelong wrote: Is this the way to do it ? Or is there better way ? Or does this exist already ? Comments please. If that's a proper way to do this, how could this be included in a next version of fpc ? Do I make a bug-report including the new file, with diffs for the modified files ? How do I make a proper diff ? Thanks, Koenraad. Hi Koenraad, For simplicity I think it would be best to just add them to each unit without too many macros. There's not a clear line for what to include in the RTL units at the moment, but with CMSIS growing more relevant I think it makes sense to have that table of IRQn numbers in there for all Cortex-M devices. You can either just use SVN to create a patch (there's info here: http://wiki.freepascal.org/Creating_A_Patch), or just send the files to me and I'll fix it up. Best Regards, Jeppe ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] quality of FPC random
Hi All, I need to generate random numbers to be used as IV of block ciphers. My question is: is FPC built-in PRNG good enough as comparing to /dev/urandom? On the other hand, /dev/urandom in my impression is fairly slow, how is the speed of Random() comparing to that? Thanks! Xiangrong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] quality of FPC random
Xiangrong Fang wrote on Fri, 14 Aug 2015: I need to generate random numbers to be used as IV of block ciphers. My question is: is FPC built-in PRNG good enough as comparing to /dev/urandom? No PRNG is suited for that purpose, because every PRNG is by definition predictable and you need unpredictable numbers for IVs. On the other hand, /dev/urandom in my impression is fairly slow, how is the speed of Random() comparing to that? They are not comparable, they serve completely different purposes. Additionally, the speed of /dev/urandom depends on a lot of factors (it gets its input from various kinds of activity on the system, so the more activity there is, the faster it becomes). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] quality of FPC random
On 08/14/2015 03:47 PM, Jonas Maebe wrote: My question is: is FPC built-in PRNG good enough as comparing to /dev/urandom? No PRNG is suited for that purpose, because every PRNG is by definition predictable and you need unpredictable numbers for IVs. How should /dev/urandom not be predictable (as any software random generator is) ? Decent Wifi hubs use hardware of some kind. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] quality of FPC random
2015-08-14 21:47 GMT+08:00 Jonas Maebe : > > Xiangrong Fang wrote on Fri, 14 Aug 2015: > > I need to generate random numbers to be used as IV of block ciphers. My >> question is: is FPC built-in PRNG good enough as comparing to >> /dev/urandom? >> > > No PRNG is suited for that purpose, because every PRNG is by definition > predictable and you need unpredictable numbers for IVs. Well, practically, how can I get totally unpredictable numbers? On stackoverflow, someone suggested using hash value of data as IV, but that's still flawed somehow. Without introduce hardware source like a dongle or other devices (which is not acceptable for my purpose), I suppose good quality PRNGs are the only thing that I can use? Also, why FPC random number are not comparable to /dev/urandom? Despite the difference in their quality and speed (if any), what's the difference between them? especially, what are the typical use cases of these 2 PRNGs when they are designed? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] quality of FPC random
Michael Schnell wrote: On 08/14/2015 03:47 PM, Jonas Maebe wrote: My question is: is FPC built-in PRNG good enough as comparing to /dev/urandom? No PRNG is suited for that purpose, because every PRNG is by definition predictable and you need unpredictable numbers for IVs. How should /dev/urandom not be predictable (as any software random generator is) ? It seeds itself with "entropy" from the intervals between LAN packets, intervals between typed characters and so on. Decent Wifi hubs use hardware of some kind. Noise diode, entropy as discussed above, etc. Or they've got broken security, which probably describes the majority. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] quality of FPC random
Xiangrong Fang wrote on Fri, 14 Aug 2015: 2015-08-14 21:47 GMT+08:00 Jonas Maebe : No PRNG is suited for that purpose, because every PRNG is by definition predictable and you need unpredictable numbers for IVs. Well, practically, how can I get totally unpredictable numbers? By using /dev/urandom Without introduce hardware source like a dongle or other devices (which is not acceptable for my purpose), I suppose good quality PRNGs are the only thing that I can use? No, you cannot use PRNGs for this purpose at all. Also, why FPC random number are not comparable to /dev/urandom? Despite the difference in their quality and speed (if any), what's the difference between them? especially, what are the typical use cases of these 2 PRNGs when they are designed? /dev/urandom is not a PRNG. It returns "real" random numbers and its use case is for security-sensitive purposes (how reliable it is at generating true random data, is a completely separate issue). The use case for a PRNG like FPC's is in games, simulations and the like. Again: all PRNG's are of the absolutely worst possible quality when the goal is security, because no matter how good they are at bit swizzling and regardless of how large their state is, they are 100% predictable. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
